Mail-Handling von Endkundenvertraegen / Suexec-Usern

    Hi,


    LiveConfig legt für jeden Endkundenvertrag ein Systemkonto an. Wird Suexec eingesetzt oder Cronjobs genutzt, so werden haeufig von dieser UserId ausgehend Mails verschickt oder Versuche unternommen an dieses Systemkonto Mails zuzustellen. Die Kombination Postfix/Dovecot wirft an dieser Stelle einen Fehler (kann ich bei Bedarf naeher ausfuehren) und die Mail verschwindet im Nirvana. Das Anlegen eines Aliases schafft Abhilfe.


    Es waere schoen, wenn LiveConfig diesen Fall sauberer haendeln wuerde.


    Gruss ksmx

    Danke, guter Hinweis. Wir werden künftig beim Anlegen/Bearbeiten von Hostingverträgen gleichzeitig einen alias-Eintrag mit pflegen (ist nur eine Kleinigkeit in der Implementierung, also vermutlich schon im nächsten Update enthalten).


    Viele Grüße


    -Klaus Keppler

    Zitat von kk

    Wir werden künftig beim Anlegen/Bearbeiten von Hostingverträgen gleichzeitig einen alias-Eintrag mit pflegen (ist nur eine Kleinigkeit in der Implementierung, also vermutlich schon im nächsten Update enthalten).


    Hallo,


    in welche Version wurde diese Funktion eingebaut?

    Aktuell existiert dieses Feature noch nicht. Ich bin mir aktuell ueber die Best Practice in der Verarbeitung von System-Mails in Zusamemnspiel mit LiveConfig unschluessig. Der Hintergrund:


    LiveConfig setzt in der main.cf als mydestination ausschliesslich den localhost. Der Mailname meines Systems findet an dieser Stelle keine Beachtung. Aliases (/etc/aliases) werden somit ignoriert. Eigentlich bin ich nicht bereit den Mailname auch in LiveConfig anzulegen und die System-Aliase (postmaster, clamav, logcheck, etc.) dort zu pflegen.


    Bisher habe ich den Mailname manuell in den mydestinations eintragen und war regelmaessig ueberrascht, wenn er wieder verschwunden war. :(


    Gruss ksmx

    Würde das Thema gerne noch einmal zum Leben erwecken. Wäre schön wenn die Aliase automatisch erstellt/geändert/gelöscht werden können. Notfalls hat man eben dem MTA ein separates Verzeichnis mitzuteilen (http://www.postfix.org/postconf.5.html#mail_spool_directory), was nun nicht die schönste Lösung wäre. :)


    Code
    Final-Recipient: rfc822; webXXX@hostname
Action: failed
Status: 5.2.0
Diagnostic-Code: X-Postfix; cannot update mailbox /var/mail/webXXX for user
    webXXX. cannot open file: Is a directory
    Zitat von arnoldB

    Würde das Thema gerne noch einmal zum Leben erwecken. Wäre schön wenn die Aliase automatisch erstellt/geändert/gelöscht werden können. Notfalls hat man eben dem MTA ein separates Verzeichnis mitzuteilen (http://www.postfix.org/postconf.5.html#mail_spool_directory), was nun nicht die schönste Lösung wäre. :)


    Code
    Final-Recipient: rfc822; webXXX@hostname
Action: failed
Status: 5.2.0
Diagnostic-Code: X-Postfix; cannot update mailbox /var/mail/webXXX for user
    webXXX. cannot open file: Is a directory


    Ist es denn überhaupt gewünscht, das WebParts "unkontrolliert" Mails verschicken? Ist es nicht sinnvoller, die ominösen webNNN komplett am Mailen zu hindern und das Mailen nur mit einem Mailkonto zu ermöglichen? Das würde auch das Mailen mit geklauten Zugangsdaten unterbinden (weil webXXX nicht mailen darf...)

    Wenn du Webhosting-Kunden die PHP mail()-Funktion nicht deaktivierst, werden die UNIX-Accounts dieser Kunden (webNNN) genutzt um die Mails via Postfix-sendmail bzw. pickup an den MTA zur Weiterverarbeitung übergeben.
    Die entsprechende Belege dafür findest du in den Mail-Headern und dem Logfile deiner Wahl. :)


    Der IP-Adressreputation zuliebe wäre es mir natürlich am liebsten diese Accounts am MTA zu sperren, aber Kunden erwarten nun leider PHP mail().

    Zitat von arnoldB


    Der IP-Reputation zuliebe wäre mir natürlich am liebsten diese Accounts am MTA zu sperren, aber Kunden erwarten nun leider PHP mail().


    Jep. Ich hab letzte Woche etwas von einer Negativ-Liste für Postfix gelesen. Das wollte ich am WE mal austesten.
    Die meisten CMS-Krücken können heute schon mit SMTPAuth-Daten umgehen, ich denk, ich werde es mal ausprobieren ;)

    Nachtrag: Wäre natürlich vorteilhaft wenn der Kunde den Mail-Alias auch deaktivieren kann, sonst hätte ich mächtig Probleme. :)
    Den LUA-Part könnte ich auch selber machen. Nicht aber die Arbeit in der LC-GUI.


    Eine Motivation für die Aliase ist auch die Kunden auf Probleme in den eigenen Webapplikationen hinzuweisen. Wenn die Webapplikationen E-Mails verschicken, der MTA die E-Mail aber 5XX rejected, wird eine Bounce-Mail generiert. Diese Mail landet aktuell im Nirvana und nochmal im Postmaster-Postfach als Fehlermeldung. Ich hab hier mehrere Fälle wo es wirklich sinnvoll ist den Kunden auf seine kaputte Webapplikation hinzuweisen..

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden