Strato Linux-Server Mail-Settings

[cpw]

Hallo,

ich habe ein Problem mit eMail-Weiterleitungen auf einem Strato-Rootserver (SuSe 10.2 mit SA24) - ich kriege es aufgrund eines Bugs im ServerAdmin24 nicht hin, eine eMail-Adresse weiterzuleiten, ohne dass die Mails dabei aus dem POP3-Account gelöscht werden.

Ich habe insgesamt zwei Bugs im ServerAdmin24 bezüglich Weiterleitungen gefunden:

Erstens wird bei der Eingabe einer Weiterleitungs-Adresse ein Unterstrich als unzulässiges Sonderzeichen abgelehnt - hier ist ein regulärer Ausdruck bei der Adress-Überprüfung im SA24 falsch (Funktion illegal_email(), /lib/sa24_advanced_functions.inc.php, Zeile 607). Dieses Problem ist mindestens seit Februar 2008 bekannt (ich habe irgendwo Foren-Einträge mit diesem Datum über dieses Thema gefunden), aber immer noch nicht gefixt...

Diese Problem lässt sich entweder durch Anpassung des regulären Ausdrucks in den PHP-Sources oder durch manuelle Änderung der Weiterleitungsadresse in der sa24-Datenbank (MySQL, Tabelle "email_forwarder") ändern. Ich frage mich, wieso der Kunde sowas selbst machen muss, wenn der Bug seit mindestens neun Monaten bekannt ist...


Der zweite Bug betrifft das Belassen einer lokalen Kopie im POP3-Account bei einer Weiterleitung - dies ist mein eigentliches Problem, für das ich keine Lösung finde:

In der SA24-Oberfläche gibt es bei der Einrichtung einer Weiterleitung die per Checkbox auswählbare Funktion "Lokale Kopie im POP-Account behalten". Ob man dies anhakt oder nicht ist allerdings vollkommen egal - in beiden Fällen werden die Mails "nur" weitergeleitet, d.h. weitergeleitet und aus dem Posteingang gelöscht.

In der sa24-Datenbank befindet sich diese Information scheinbar in der Tabelle "emailaccounts", Spalte "delete" der entsprechenden eMail-Adresse. Der entsprechende Wert (0 oder 1) ändert sich auch je nach Auswahl der Option in der SA24-Weboberfläche, nur der Mailserver an sich bekommt das scheinbar nicht mit.

Auch hier habe ich mir die PHP-Sources des SA24 angeschaut, den Fehler halbwegs eingrenzen können, allerdings bleibe ich bei der Funktion sa24_mail_system_update_forwarder() ( /lib/mail_system_qmail.inc.php, Zeile 124) bzw. der darin verwendeten Funktion sa24d_command() ( /lib/sa24_daemon_functions.inc.php, Zeile 410) hängen - ich verstehe nicht, wie genau und "wohin" das Kommando "vpopmail_update_forwarder" gecrypted und per fputs() geschickt wird. Das Problem kann nur darin bestehen, dass das "Delete-Flag" irgendwo nicht korrekt an das Mailsystem übergeben wird, lösen kann ich das allerdings erstmal nicht.



Lange Rede, kurzer Sinn (und der Grund, warum ich im "Email"- und nicht im "SA24"-Unterforum gepostet habe ):

Nachdem ich momentan keine Chance sehe, den SA24 zu fixen, wollte ich die entsprechenden Weiterleitungs-Settings nun manuell anpassen - irgendwo auf dem Server muss es ja änderbare Konfigurationsdateien für den ganzen Mail-Krams geben.

Mein Problem: Ich finde nichts dergleichen.

Der Strato-Support hat diesbezüglich offenbar absolut keine Ahnung - sinngemäße Antwort: "Da müssen Sie auf das nächste ServerAdmin24-Update warten." - toll, danke...
Eine direkte Kontaktaufnahme mit den SA24-Entwicklern ist laut Strato-Hotline nicht möglich.


Welches Mailsystem wird überhaupt verwendet, bzw. wie finde ich das heraus? Ich vermute qmail, da sich die einzigen Mailsystem-PHP-Funktionen im SA24, die etwas anderes als "true" zurückgeben, in der Datei mail_system_qmail.inc.php befinden.

Nach langem googeln habe ich immer wieder etwas von /var/qmail gelesen - diesen Pfad gibt es auf dem Server nicht. Ebenso scheinbar keine andere *qmail*-Datei, die mir irgendwie weiterhelfen würde.

Ein

find / -type f | xargs grep *weiterleitungsadresse@example.com*

(selbstverständlich mit echter Weiterleitungsadresse) liefert ebenso keine Ergebnisse. Hierbei müsste ich ja theoretisch eine Config-Datei finden, in der die Weiterleitung eingetragen ist.


Kann mir da jemand helfen und mir sagen, wo sich solche Settings auf einem Strato-Linuxserver befinden? Danke schonmal.


Gruß,
Christian

 

[LinuxAdmin]

rpm -qa |less

zeigt Dir alle installierten Pakete an, da könntest Du mal nach den üblichen Verdächtigen (postfix, exim,...) suchen.
Noch ein Hinweis: mit "lsof" könntest Du nachschauen, welches Programm sich an Port 25 gebunden hat. Dabei wird der volle Pfad ausgegeben; wenn Du diesen als Parameter an "rpm -qf" übergibst, weist Du aus welchem Paket das Programm stammt.

Dein find-Befehl funktioniert deshalb nicht, da keine solchen Weiterleitungen eingerichtet sind -- die befinden sich alle in der Datenbank. Bei vielen MTAs werden die Weiterleitungen in /etc/aliases eingetragen (diese Datei muss aber meistens mit einem speziellen Programm übersetzt werden, bevor die Änderungen wirksam werden). Wenn Du rausgefunden hast, welcher MTA bei Dir läuft, kann man Dir sicherlich weiterlaufen.

 

[cpw]

Noch ein Hinweis: mit "lsof" könntest Du nachschauen, welches Programm sich an Port 25 gebunden hat.

Ich kann zwar den Informationen nicht direkt einen Port entnehmen, allerdings taucht dort mehrfach "exim" mit dem User "mail" auf:

exim       2924       mail  cwd       DIR        3,3     4096    5685393 /var/spool/exim
exim       2924       mail  rtd       DIR        3,3     4096          2 /
exim       2924       mail  txt       REG        3,3   915004    2590118 /usr/sbin/exim
exim       2924       mail  mem       REG        0,0                   0 [heap] (stat: No such file or directory)
exim       2924       mail  mem       REG        3,3    42546    5947513 /lib/libnss_files-2.5.so
exim       2924       mail  mem       REG        3,3   217016    5653719 /var/run/nscd/group
exim       2924       mail  DEL       REG        3,3             5653720 /var/run/nscd/dbgv7PpU
exim       2924       mail  mem       REG        3,3   217016    5653718 /var/run/nscd/passwd
exim       2924       mail  mem       REG        3,3    72020    5947493 /lib/libz.so.1.2.3
exim       2924       mail  mem       REG        3,3    93284    2593861 /usr/lib/libsasl2.so.2.0.22
exim       2924       mail  mem       REG        3,3   121246    5947502 /lib/libpthread-2.5.so
exim       2924       mail  mem       REG        3,3  1491141    5947521 /lib/libc-2.5.so
exim       2924       mail  mem       REG        3,3  1270272    2589693 /usr/lib/libcrypto.so.0.9.8
exim       2924       mail  mem       REG        3,3   252116    2590863 /usr/lib/libssl.so.0.9.8
exim       2924       mail  mem       REG        3,3  1314140    2593644 /usr/lib/libmysqlclient.so.15.0.0
exim       2924       mail  mem       REG        3,3    51700    2593314 /usr/lib/liblber-2.3.so.0.2.15
exim       2924       mail  mem       REG        3,3   228072    2593854 /usr/lib/libldap-2.3.so.0.2.15
exim       2924       mail  mem       REG        3,3  1032600    2593944 /usr/lib/libdb-4.4.so
exim       2924       mail  mem       REG        3,3    14226    5947518 /lib/libdl-2.5.so
exim       2924       mail  mem       REG        3,3   190963    5947527 /lib/libm-2.5.so
exim       2924       mail  mem       REG        3,3    47607    5947524 /lib/libcrypt-2.5.so
exim       2924       mail  mem       REG        3,3    94097    5947401 /lib/libnsl-2.5.so
exim       2924       mail  mem       REG        3,3    74840    5947565 /lib/libresolv-2.5.so
exim       2924       mail  mem       REG        3,3   121432    2593648 /usr/lib/libpcre.so.0.0.1
exim       2924       mail  mem       REG        3,3   129767    5949839 /lib/ld-2.5.so
exim       2924       mail    0u      CHR        1,3                2701 /dev/null
exim       2924       mail    1u      CHR        1,3                2701 /dev/null
exim       2924       mail    2u      CHR        1,3                2701 /dev/null
exim       2924       mail    3u     IPv4       7673                 TCP *:smtp (LISTEN)
exim       2924       mail    4u     IPv4       7674                 TCP localhost:10025 (LISTEN)

Also denke ich, der verwendete MTA ist exim?

Gehe ich recht in der Annahme, dass die Konfiguration irgendwo in einer DB gespeichert wird? Evtl. in der SA24 MySQL-DB? Das würde auch erklären, wieso zumindest die Änderung der Forward-Adresse direkt in der Tabelle sofort (also ohne weiteres ausführen eines SA24-PHP-Skripts) übernommen wird und funktioniert. Dann wäre meine nächste Vermutung, dass die Spalte "delete" der Tabelle "emailaccounts" nicht bzw. fehlerhaft ausgelesen wird.



Gruß,
Christian

 

[cpw]

OK, noch einen Schritt weiter:

Im Verzeichnis /etc/exim gibt es eine exim.conf sowie eine mysql.conf mit den entsprechenden Zugangsdaten.

# This configuration is based on exim default configuration file to
# operate with the ServerAdmin24 Email config.

Es wird also für die Konfiguration tatsächlich auf die SA24 MySQL-DB zugegriffen. Fragt sich nur, wieso die Spalte "delete" ignoriert wird...


//EDIT:

Ich habe die exim.conf (umbenannt in exim.txt, damit der Upload sie akzeptiert) mal angehangen.

Ich steige da nicht wirklich durch - erkennt evtl. jemand einen Fehler der dazu führen könnte, dass weitergeleitete eMails gelöscht werden, auch wenn die Spalte "delete" in der Tabelle "emailaccounts" auf 0 gesetzt ist?



Gruß,
Christian