Wird der Return-Path bei Mails aus Hosting-Paketen falsch gesetzt?

    Hallo!


    Wordpress setzt in ausgehenden Mails keinen SENDER, sondern nur FROM.

    Die Mails gehen über PHP mail() und Phpmailer an den Mailserver.

    Phpmailer nimmt die From-Einstellung für den From: Header und die Sender-Einstellung für den MAIL FROM: Header. Im Falle von Wordpress gibt es MAIL FROM also nicht.

    Die Mail geht weiter zum Postfix, wo aus MAIL FROM der Header Return-Path: wird.


    Das ist alles so weit richtig, aber: Wordpress setzt ja am Anfang keinen SENDER, und am Ende kommt der Unix-Username als Return-Path raus. So kommt eine Mail von Wordpress an:



    Gibt es irgend ein Argument für diesen Return-Path? Ich habe viele andere Mailserver verglichen, die setzen alle FROM als Return-Path oder den Domainnamen der Webseite.


    Ein Problem mit dieser Konfiguration entsteht in Spam-Filtern. SPF geht nach dem Return-Path, und da ergibt so eine Domain keinen Sinn. Hier ein Beispiel von Google Mail.

    Code
    spf=neutral (google.com: 188.68.61.102 is neither permitted nor denied by best guess record for domain of hosting106351@hosting106351.a2f21.netcup.net) smtp.mailfrom=hosting106351@hosting106351.a2f21.netcup.net;


    Ich könnte es verstehen, wenn Return-Path auf einen festgelegten Wert gesetzt wird, z.B. info@domainname. Aber wo lässt sich dieser Wert festlegen?


    Mir ist bekannt, dass es im Customercontrolpanel eine Option für PHP mail() gibt und Wordpress über den Hook phpmailer_init den Wert setzen kann. Aber das sind Workarounds für einen fragwürdig konfigurierten Mailserver.


    Viele Grüße

    Thomas

    Quote from Netaction

    Ich könnte es verstehen, wenn Return-Path auf einen festgelegten Wert gesetzt wird, z.B. info@domainname. Aber wo lässt sich dieser Wert festlegen?

    z.B. indem die Mail, die Du übergibst, den Wert bereits gesetzt hat?

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Quote from mainziman

    die Mail, die Du übergibst, den Wert bereits gesetzt hat?

    Es gibt tatsächlich ein Wordpress-Plugin mit 10 Zeilen, das genau das macht und den Return-Path setzt. (Quellcode)


    Ist das hier ein Bug in Wordpress, und alle Netcup-Kunden müssen das Plugin installieren, oder ist der Fehler doch bei Netcup? Ich habe eben mit All-Incl und Domainfactory verglichen, die setzen schlauere Header.


    Aus Sicht von SPF steht fest, dass einer der beiden kaputt ist und falsche Daten liefert.

    Ich habe eine erstaunliche Information vom Support bekommen: PHP mail() soll gar nicht verwendet werden, sondern SMTP an einen richtigen Mailserver. Die Webserver sind für Mail nicht besonders geeignet. Gut zu wissen!


    Also zur Ausgangsfrage: Der Fehler liegt bei Wordpress, das PHP mail() für eine gute Idee hält. Wir können aber ganz einfach in der wp_config.php über den Hook phpmailer_init SMTP konfigurieren.


    Thomas

    Was für eine doofe Antwort vom Support. Erstens kann PHP so konfiguriert werden, dass es SMTP-Server nutzt, zweitens ist es Netcups Aufgabe, die Webserver so zu konfigurieren, dass ein Mailversand darüber problemlos möglich ist. Entweder, indem sie die Mails selbst raus schicken, oder indem sie dort einen Smarthost konfigurieren, der die Mails über das eigene Cluster leitet. Dabei ist es allerdings tatsächlich richtig und wichtig, dass im Return-Path eine Netcup-Adresse steht, und der sendende Server im SPF der dort verwendeten Domain zugelassen wird. Wenn dort nämlich eine Adresse von GMail oder GMX steht, würden die Mails niemals ankommen, da der Netcup-Server zum Versand von Mails unter deren Adressen nicht berechtigt ist.


    Auf meinem eigenen Server ersetze ich den Return-Path deshalb immer mit einer von mir festgelegten Bounce-Adresse, völlig unabhängig davon, was ein Script bei der Einlieferung angegeben hat. Und das:

    Quote from Netaction

    spf=neutral (google.com: 188.68.61.102 is neither permitted nor denied by best guess record for domain of hosting106351@hosting106351.a2f21.netcup.net) smtp.mailfrom=hosting106351@hosting106351.a2f21.netcup.net;

    … ist kein Fehler, sondern besagt nur, dass überhaupt kein SPF-Record vorliegt, was normalerweise dazu führen sollte, dass die Mail auch neutral behandelt und nicht als Spam erkannt wird.

    Quote from Bachsau

    Entweder, indem sie die Mails selbst raus schicken, oder indem sie dort einen Smarthost konfigurieren, der die Mails über das eigene Cluster leitet.

    derartiges ist im shared hosting nicht unproblematisch ..., und sollte vermieden werden;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Gegenfrage: was ist wahrscheinlicher. dass jemand der sich auskennt, per PHP einen SMTP zu nutzen weiß und damit einen vernünftig funktionierenden Mail Versand hat od. dass auf Grund Deines Vorschlages, und der Angriffsvektoren der Skriptkonvolute der Webserver so richtig zur SPAM-Schleuder werden kann?

    (denke daran, dass der Webserver - vulgo der Smarthost - im Namen aller auf dem Webserver gehosteten Domains senden dürfte ...)

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Das ist kein Argument. Natürlich muss man das vernünftig monitoren, und wenn man es über einen bestimmten Smarthost leitet, der diese Aufgabe übernimmt, und gleichzeitig Verbindungen zum Port 25 sperrt, erhöht das wahrscheinlich sogar die Sicherheit. Um Spam zu versenden, braucht man keine funktionierende Mail-Funktion in PHP, und auch kein systemweites Sendmail. Direkte Verbindungen zu irgendwelchen Mailservern kannst du mit nahezu jeder Scriptsprache öffnen.