kein Mailversand

[mikeDDF]

Hallo,

Neuinstallation aktuellste Version, php und MySQL entsprechen den Vorgaben.

Das Programm funktioniert in allen Bereichen einwandfrei, lediglich weigert es sich,
irgendwelche Emails zu versenden.

a) In der Benutzerverwaltung per Klick auf Emailsymbol:
->Email konnte an <....> nicht versendet werden.

b) Emailmodul, Versand an Rolle
Die von Ihnen ausgewählte Rolle enthält keine Mitglieder mit gültigen E-Mail-Adressen, an die eine
E-Mail versendet werden kann!

Es sind 2 Mitglieder enthalten mit gültier Emailadresse und auch korrekter Rollenzuordnung.

Errorlog:
PHP-Errorlog befinden sich keine zuordenbaren Einträge

lokales Errorlog via htaccess:
keine Eintragungen in Datei

Konfiguration Modul:
default-Einstellungen

Die relevanten Parameter alle bereits geändert:
ISO/UTF
Absender als Adressat (ja/nein)
Absenderadresse (gefü+llt und leer)
HTML ja/nein

Fehler in allen Kombinationen identisch.

Kein Update, aktuellste Version ist Erstinstallation.

Einige hier im Forum gefundene Tipps habe ich umgesetzt, in der email.php sind die hier im Foruim
vorgeschlagenen Änderungen bereits enthalten.

Gibt es serverseitig etwas, was eventuell anzupassen wäre ?

Vielen Dank für ein paar Hinweise.

Mike

[Jochen]

Hallo Mike,
die Tipps die Du im Forum schon gefunden hast sollten sich alle auf Vorgängerversionen beziehen und in der aktuellen alle mit arbeiten.
Da es Mail immer mal wieder Probleme gibt zwei Fragen vorweg: Bei welchem Provider läuft der Server? Wie steht es um Deine PHP-Kenntnisse?
Gruß Jochen

[mikeDDF]

Hallo Jochen,

die Version ist auf einem Linux Rootserver (Apache). Mit Admidio teste ich derzeit noch, also kann man in diesem System noch alles verändern (allerdings habe ich zum Test schon "echte" Personendaten eingegeben).
Es laufen unter anderen Domains auf gleichem Server noch drei andere PHP-Anwendungen (CMS etc.), die alle Email verwenden (allerdings via SMPT-AUth und nicht mail()), sowie der gesamte Emailverkehr für mehrere Domains.
FUnktionsstörungen gibt es dort keine. Mit PHP/SQL/HTML/CSS kenne ich mich ganz gut aus.

Am Server:
Pfade zu sendmail sind korrekt, sendmail-Prozess ist lt. ps auch aktiv, Auswertungen der Logfiles (mail.err, mail.warn, mail, system, php_error und die apache-logs) brachte keine im Zusammenhang mit dem Problem stehenden Meldungen zu Tage. Wobei das mich schon etwas stutzig gemacht hat, denn ein Mailsendeversuch (auch wenn er dann durch irgendwelche Gründe wie Relaylock etc. nicht durchgeführt wird) sollte zumindest in den Maillogs erkennbar sein.

Noch eine besondere Situation zur Testumgebung Admidio:
die Domain mein-admidio.de läuft für A und MX-Record gem. NS-Config auf einem anderen Server.
Admidio ist unter einer Subdomain sub.mein-admidio.de per A-Record auf den Testserver geleitet.

Ich hatte hier zur Fehlerdiagnose bereits eine Umstellung vorgenommen:
MX und A der Hauptdomain ebenfalls komplett auf den Testserver, Emaildienst für die Domain mein-admidio.de am Server eingerichtet. Hat soweit alles funktioniert, nur eben Admidio nicht.
(ist jetzt wieder auf urspr. Konfiguration umgestellt).

[Jochen]

Hi,
ok, der Mann weiß was er tut
Hast Du schon mal probiert einfach mal in sendmail() in einem Einzeiler unabhängig von Admidio aufzurufen? Ich persönlich hab leider gerade so gar keine Idee woran es liegen könnte.
Der Versand über SMTP steht auch auf meinem Wunschzettel.
Gruß Jochen

[mikeDDF]

scheinbar bin ich mir nicht im Klaren, was ich tue ....

Gut.
Sendmail habe ich versucht, funktioniert.
Sowohl auf Consolen-Ebene (mail -s ...) als auch als untergeordneter User. Die Emails kamen alle an (und wurden in den Logfiles gelogged).

Dann habe ich folgenden Code in die members.php (m.E. die Datei, die die höchsten Rechte im Admidio-System benötigt) reingeschrieben:

nach der if-Abfrage
// Bedingungen fuer das SQL-Statement je nach Modus setzen

$x_empfaenger = "rml@lira.de";
$x_betreff = "Email senden";
$x_from = "From: Webmaster <webmaster@die-linke-laizismus.de>";
$x_text = "Dies ist nur ein Test";

mail($x_empfaenger, $x_betreff, $x_text, $x_from);

Somit muss die Funktion aufgerufen werden, wenn die Seite geladen wird. Eine Ausgabe der definierten Variablen war erfolgreich, eine Email ist nicht angekommen. In den Logfiles wurde nichts vermerkt.

Dann habe ich eine eigene php-Datei (nur mit dem Mail-Code) geschrieben, habe sie in Admidio eingebunden (habe sie auch members.php genannt).

Dort habe ich einmal die Mail wie oben beschrieben gesendet, darunter habe ich ein Formular gebastelt und den Inhalt dann per Email an die o.g. Variablen geschickt.

Erste Email kam nicht an.
Zweite Email kam zwar auch nicht an, aber innerhalb der Form definierte Umgebungsvariablen konnten auf der Startseite von Admidio abgefragt werden (sind also ordnungsgem. gesetzt worden).

Dieses Formular produzierte beim Sendevorgang einen Fehler in einem Logfile, allerdings nicht in einem Systemlog, sondern im Log von einer installierten Überwachungssoftware:
2400: unauth request to arpad by ......pfade.../members.php, datum-uhrzeit

Daraufhin bin ich auf die Idee gekommen, dass Admidio eventuell nicht unter seiner Owner- oder Group-ID in Linux sendet, auch nicht unter der des Apache-Webservers, sondern unter irgendeiner anderen.

In den Sorcen der mail-phps von Admidio konnte ich solches zwar nicht erkennen, aber einen fremden Sorcecode lesen mit einigen Includes ist nicht einfach.

Ich wüsste jetzt aber auch nicht, wie ich dies noch näher herausbekommen sollte.

Die Files von Admidio haben alle als Ownership den FTP-Namen der Subdomain, als Group sind sie wie alle Domains in der entsprechenden vD-Gruppe. Rechte passen auch.

Dann kam mir die glorreiche Idee, alle Admidio-Files auf Ownership root zu setzen und Rechte 777.

Danach habe ich Admidio gestartet, meine gebastelte members.php aufgerufen und siehe da, es wurde im System die gesendete Email gefunden. Sie ist zwar nicht rausgegangen, aber immerhin wurde sie an root zurück-gebounced.
Fehlercode: unauthorized relay

Im Systemlog wurde dieser Relay-Zugriff (mail.warn) registriert.

So, nun fehlt mir nur noch eine Idee, wie ich diese Erkenntnisse zusammenbringen könnte.

Scheinbar versucht Admidio unter einer nicht ihm zugeordneten User- oder Group-ID auf sendmail zuzugreifen. Ob man das Problem via PHP oder auf Linux-Ebene lösen kann/sollte, da bin ich derzeit überfragt.

Fazit:
nachdem ich die original-Admidio-Files wieder eingespielt habe (mit korrekten Group-Owner-Rechten)
ging es wieder nicht (wie bisher).
Nehme ich die Originaldateien mit Ownership root und arbeite ohne meine members.php, dann kann ich die Email aus dem System heraus versenden (ohne Fehlermeldung von Admidio), sie kommen zwar nicht beim Empfänger an, aber werden an root gebounced.

Und hier endet mein Latein ....
Es scheint auf jeden Fall was mit den Rechten zu tun zu haben. Interessant wäre, unter welcher ID Admidio den Mailversand einleitet.

Lange Erklärung, aber habe auch viel getestet
Noch irgendeine Idee ?

Gruß
Mike

[mikeDDF]

Das Problem ist gelöst

Ursache:
Admidio sendet Emails per default unter der Benutzergruppe und des Ownerships vom Apache-Server.
Diese muss (und sollte aus sicherheitsrelevanten Erwägungen) nicht mit Ownership und Benutzergruppe der Admidio-Installation übereinstimmen.

Je nach Konfiguration des Linux-Servers (php, Apache, Sicherheitsfeatures) kann es dabei dazu kommen, dass im Session-Environment des Servers ein nichtauthorisierter Zugriff erkannt wird und die Anfrage (sendmail) blockiert wird. Entsprechend der Systemkonfiguration können die dabei erzeugten Warnmeldungen ins Leere laufen (>/dev/null) und sind somit in den Serverlogfiles nicht sichtbar.

Abhilfe kann man auf verschiedenen Wegen schaffen.

a) Admidio unter Benutzergruppe und Ownership des Apache-Server installieren und betreiben
b) explizite Ausnahme für Admidio konfigurieren (Admidio die Benutzung der Apache Ownership/Usergroup erlauben)
c) Admidio-Group in die Apache-Group integrieren

Mailversand könnte in stringend konfigurierten Webservern auch an der PHP-Konfiguration scheitern.
Sofern Savemode=on gesetzt ist, müssen in der PHP-Konfiguration folgende Parameter ebenfalls angepasst werden: save_mode_gid, save_mode_include_dir, save_mode_exec_dir und open_basedir. (nicht zwingend alle gleichzeitig, welche im Einzelfall relevant sind, richtet sich nach der Gesamtkonfiguration des Systems).

Generell:
betrifft Linux-Systeme mit Apache-Webserver.
Für andere OS (Windows...) mag dies ggf. ebenfalls zutreffend sein.

Hoffe, ich erspare anderen Usern mit ähnlichen Problemen dadurch zig Stunden der Fehlersuche.

[Jochen]

Hallo Mike,
na dann hoffe ich mal das ich durch meine eigentlich nutzlosen Beiträge wenigstens die Suchmotivation oben gehalten habe. Im ernst, da wäre ich nie drauf gekommen. Aber danke für die ausführliche Erklärung, die nutzt ja nicht nur andern Usern sondern auch uns Entwicklern.
Gruß Jochen

[mikeDDF]

Nein, Dein Input war doch gut. Bin ja letztendlich auch nur durch "try&error" draufgekommen, denn explizit daran hätte ich auch nicht gedacht.

Ich habe es mit einer neuen Installation noch einmal verifiziert, in bestimmten Konstellationen kann der Fehler tatsächlich reproduziert werden.