Ich mach mal einen neuen Thread auf, da das jetzt nix mehr mit dem M$ Exchange zu tun hat.
Hier habe ich eine schöne Erklärung gefunden, wie die Adress Verifikation ablaufen sollte:
http://www.fsf.org/about/systems/sender-verification
Unter "Misconfiguration #1" kann man lesen: wenn jemand keine Antwort erhalten möchte (z.B. auf einen Newsletter-Versand), dann muss er nach RFC den Null-Absender verwenden. Er darf keine Adresse verwenden die bei ihm nicht existiert.
Jochen
On 25.07.2017 21:18, Joachim Fahrner wrote:
Ich mach mal einen neuen Thread auf, da das jetzt nix mehr mit dem M$ Exchange zu tun hat.
Hier habe ich eine schöne Erklärung gefunden, wie die Adress Verifikation ablaufen sollte:
http://www.fsf.org/about/systems/sender-verification
Unter "Misconfiguration #1" kann man lesen: wenn jemand keine Antwort erhalten möchte (z.B. auf einen Newsletter-Versand), dann muss er nach RFC den Null-Absender verwenden. Er darf keine Adresse verwenden die bei ihm nicht existiert.
Jochen
der NULL-Absender hat einen Pferdefuß, ein Mailserver muss diese Mails, welche keine Fehler von durch ihn generierten Mails darstellen nicht annehmen;
ein gut konfigurierter Newsletter-Server verwendet als Absender im Mail-Envelope seine eigene Domain, f. welche er nach SPF auch befugt ist, Mails abzusenden; devnull@domain.tld ist ja möglich, und devnull wird einfach in den Shredder /dev/null bevördert ...
genau das mache ich auch bei meiner 2ten Domain, welche nur zum Mailserver meiner 1ten Domain (beim Webhoster) weiterleitet ...
Joachim Fahrner - 25.07.17, 21:18:
Hier habe ich eine schöne Erklärung gefunden, wie die Adress Verifikation ablaufen sollte:
http://www.fsf.org/about/systems/sender-verification
Unter "Misconfiguration #1" kann man lesen: wenn jemand keine Antwort erhalten möchte (z.B. auf einen Newsletter-Versand), dann muss er nach RFC den Null-Absender verwenden. Er darf keine Adresse verwenden die bei ihm nicht existiert.
Whoa!
Ich denke da fallen *sämtliche* legitimen Newsletter, die ich bekomme, raus.
Weil da heißt es oft "noreply@domain".
Ja, da fallen sogar Mails von meinen Banken raus, die keine gültige Adresse angeben, damit ich über einen verschlüsselten Weg antworte. (Und ja, keine der Banken schafft es, einen Weg anzubieten, Mails verschlüsselt an die Bank zu verschicken. Behörden ja auch nicht. Das ist Steinzeit da.)
An sich finde ich das ja schön… aber das hätte bei mir viele falsche Positive. Und zwar durchaus wichtige Mails.
Wenn ich da an meine Versuche zurück denke, Newsletter-Versender davon überzeugen, nicht so Dienste wie Mailchimp zu verwenden, die Links in Tracking-Links verwandeln… habe ich da eher wenig Hoffnung bei auch nur einem dieser Sender eine Verhaltensänderung zu erreichen.
Ciao,
Am 2017-07-25 21:59, schrieb Martin Steigerwald:
Whoa!
Ich denke da fallen *sämtliche* legitimen Newsletter, die ich bekomme, raus.
Weil da heißt es oft "noreply@domain".
Das sagt noch nix. Ich hab mal einige bei mir getestet (mit einem Script), und diese noreply-Adressen existieren alle. Die liest halt dort nur keiner, landen wahrscheinlich direkt im Papierkorb.
Joachim Fahrner - 25.07.17, 22:08:
Am 2017-07-25 21:59, schrieb Martin Steigerwald:
Whoa!
Ich denke da fallen *sämtliche* legitimen Newsletter, die ich bekomme, raus.
Weil da heißt es oft "noreply@domain".
Das sagt noch nix. Ich hab mal einige bei mir getestet (mit einem Script), und diese noreply-Adressen existieren alle. Die liest halt dort nur keiner, landen wahrscheinlich direkt im Papierkorb.
Ahso… Hmmm.
On 25.07.2017 22:08, Joachim Fahrner wrote:
Am 2017-07-25 21:59, schrieb Martin Steigerwald:
Whoa!
Ich denke da fallen *sämtliche* legitimen Newsletter, die ich bekomme, raus.
Weil da heißt es oft "noreply@domain".
Das sagt noch nix. Ich hab mal einige bei mir getestet (mit einem Script), und diese noreply-Adressen existieren alle. Die liest halt dort nur keiner, landen wahrscheinlich direkt im Papierkorb.
das ist auch die übliche Vorgehensweise, Mails welche automatisiert gesendet werden, aber niemand aktiv Mails, welche an diese Mail-Adresse geschickt werden, lesen will/soll/kann; aber als NULL-Sender sollen diese nicht versendet werden ... noreply@... ist dabei das meist verbreitetste, was hier verwendet wird;
Am 2017-07-26 14:51, schrieb Walter H.:
das ist auch die übliche Vorgehensweise, Mails welche automatisiert gesendet werden, aber niemand aktiv Mails, welche an diese Mail-Adresse geschickt werden, lesen will/soll/kann; aber als NULL-Sender sollen diese nicht versendet werden ... noreply@... ist dabei das meist verbreitetste, was hier verwendet wird;
Die Regel ist eigentlich ganz einfach: Der Return-Path muss entweder eine gültige Adresse sein, oder leer. Beides ist erlaubt. Will jemand keine Antworten zurück haben, dann muss der Return-Pfad leer sein. Eine Phantasie-Adresse (die dann bouncen würde) ist nicht erlaubt.
Siehe RFC 2821 Kapitel 4.5.5
On 26.07.2017 15:49, Joachim Fahrner wrote:
Am 2017-07-26 14:51, schrieb Walter H.:
das ist auch die übliche Vorgehensweise, Mails welche automatisiert gesendet werden, aber niemand aktiv Mails, welche an diese Mail-Adresse geschickt werden, lesen will/soll/kann; aber als NULL-Sender sollen diese nicht versendet werden ... noreply@... ist dabei das meist verbreitetste, was hier verwendet wird;
Die Regel ist eigentlich ganz einfach: Der Return-Path muss entweder eine gültige Adresse sein, oder leer.
das ist ein Feld im Mail Header, welches zum Zeitpunkt der Sender Verification an Hand des MAIL FROM vom Mail-Envelope noch gar nicht bekannt ist ...
Beides ist erlaubt.
klar, die höfliche Art ist, wenn die Mailadresse im Envelope (MAIL FROM) im Mailheader (Return-Path) und im Mailheader (From) ident sind¹; aber Mailing lists haben, auf Grund der SPF das Problem, daß sie z.B. meine Mail nicht weiterschicken dürfen, weil im SPF eindeutig festgelegt ist, daß dies nur die Mailserver von meinem Mailhoster dürfen, gilt hier die sinnvolle Ausnahme, daß der Return-Path im Mail-Header und das MAIL FROM vom Mail-Envelope auf eine güiltige Mail-Adresse der Mailing-Liste gesetzt werden ...
warum es hier Pfusch ist, den Return-Path unverändert zu lassen: ganz einfach: eine Fehlernachricht, welche z.B. weil Dein Postfach voll ist, oder weil Du z.B. einen Abwesenheitsassistenten mit "ich bin auf Urlaub" aktiv hast, bei den Mitgliedern der Mailingliste defintiiv Fehl am Platz sind ...
ich denke hier haben einige Maillinglisten deren Server falsch konfiguriert ...
¹ eine Besonderheit gilt hier, Mails in Vertretung abzusetzen, dazu gibt es im Mail-Header ein weiteres Feld², und zusätzlich das Reply-To; von daher würde ich ein Reply-To welches sich nicht mit dem weiterfen Feld deckt, oder das weitere gar nicht vorhanden ist, als SPAM klassifizieren, gibt sonst keinen sinnvollen Use-Case, welcher ein Reply-To rechtfertigt ...
² dieses nennt sich: Sender:, man findet auch etwas von On-Behalf-Of: was aber proprietär ist
z.B. From: root@local To: walter@local Sender: office@company.com Reply-to: office@company.com Subject: Test
was in Mail-clients die damit umgehen können - z.B. MS-Outlook - etwa so angezeigt wird:
Von: office@company.com im Auftrag von root@local An: walter@local Betreff: Test
Will jemand keine Antworten zurück haben, dann muss der Return-Pfad leer sein. Eine Phantasie-Adresse (die dann bouncen würde) ist nicht erlaubt.
auch klar; und wenn der Return-Path leer ist, und sie nicht das Resultat (z.B. ein Fehler, weil Postfach voll, ...) eines vom Mailserver weggehenden Mails ist, kann die Mail verworfen werden ...
wie ich im anderen Post geschrieben habe, ein NULL-Sender ist, wenn es um keine Fehler geht, Unfug;
Am 2017-07-26 18:21, schrieb Walter H.:
klar, die höfliche Art ist, wenn die Mailadresse im Envelope (MAIL FROM) im Mailheader (Return-Path) und im Mailheader (From) ident sind¹;
Das ist beides das gleiche.
wie ich im anderen Post geschrieben habe, ein NULL-Sender ist, wenn es um keine Fehler geht, Unfug;
Nein, kein Unfug. Oder steht das in irgendeiner RFC? E-Mail ist wie ganz normale Schneckenpost. Wenn ich möchte, dass ein unzustellbarer Brief an mich zurück geht, dann schreibe ich meinen Absender auf den Umschlag. Wenn ich das nicht will, dann schreibe ich eben keinen drauf, kann mich dann aber auch nicht beschweren, wenn der Postbote den bei Unzustellbarkeit in den Müll wirft. Was ich aber nie machen darf: irgendeinen frei erfundenen Absender auf den Umschlag schreiben. Was soll das bringen? Dann geht der Brief hin und her, und landet am Ende doch im Müll.
On 26.07.2017 19:32, Joachim Fahrner wrote:
Am 2017-07-26 18:21, schrieb Walter H.:
klar, die höfliche Art ist, wenn die Mailadresse im Envelope (MAIL FROM) im Mailheader (Return-Path) und im Mailheader (From) ident sind¹;
Das ist beides das gleiche.
es sollte so sein, ist aber nicht zwingend ...
wie ich im anderen Post geschrieben habe, ein NULL-Sender ist, wenn es um keine Fehler geht, Unfug;
Nein, kein Unfug. Oder steht das in irgendeiner RFC? E-Mail ist wie ganz normale Schneckenpost.
richtig und Schneckenpost ohne Absender am Kuvert bin ich genausowenig verpflichtet anzunehmen, als ein Mailserver solche Mails mit NULL-Sender annehmen muss, wenn es nicht von ihm verursacht wurde ...
das wär ja traurig, weil damit könntest Dir SPF und Co in die Haare schmieren, weil SPAM immer den NULL-Sender verwenden würde, weil ja angenommen werden müsste ...
Wenn ich möchte, dass ein unzustellbarer Brief an mich zurück geht, dann schreibe ich meinen Absender auf den Umschlag
Du gehst hier davon aus, daß die Zieladresse falsch sein kann, wir reden von korrekter Empfängermailadresse ...
. Wenn ich das nicht will, dann schreibe ich eben keinen drauf, kann mich dann aber auch nicht beschweren, wenn der Postbote den bei Unzustellbarkeit in den Müll wirft. Was ich aber nie machen darf:
klar darfst Du das, Mails ohne Absender oder mit NULL-Sender musst Du nicht annehmen, spätestens, wenn Du einen Smarthost mit Authentifizierung hast, ist es sogar unmöglich ..., weil wie soll die Authentifikation von statten gehen, wenn Du den NULL-Sender verwendest ...
irgendeinen frei erfundenen Absender auf den Umschlag schreiben. Was soll das bringen?
wir reden vom NULL-Sender und das ist eben KEIN Absender auf dem Umschlag ...
Am 26. Juli 2017 19:32:02 MESZ schrieb Joachim Fahrner:
Nein, kein Unfug. Oder steht das in irgendeiner RFC? E-Mail ist wie ganz normale Schneckenpost. Wenn ich möchte, dass ein unzustellbarer Brief an mich zurück geht, dann schreibe ich meinen Absender auf den Umschlag. Wenn ich das nicht will, dann schreibe ich eben keinen drauf
RFC 5321, 4.5.5, zumindest SHOULD.
Leere Umschlag-Absender bekommen eine Spezial-Behandlung und das geht schief, wenn jeder das benutzt, wie er Lust hat.
Gruß Jost
Zitat von Jost Krieger Jost.Krieger+postfix@rub.de:
Am 26. Juli 2017 19:32:02 MESZ schrieb Joachim Fahrner:
Nein, kein Unfug. Oder steht das in irgendeiner RFC? E-Mail ist wie ganz normale Schneckenpost. Wenn ich möchte, dass ein unzustellbarer Brief an mich zurück geht, dann schreibe ich meinen Absender auf den Umschlag. Wenn ich das nicht will, dann schreibe ich eben keinen drauf
RFC 5321, 4.5.5, zumindest SHOULD.
Leere Umschlag-Absender bekommen eine Spezial-Behandlung und das geht schief, wenn jeder das benutzt, wie er Lust hat.
Gruß Jost
Der leere Absender ist für automatisch generierte Rückmeldungen vorgesehen. Dazu zählen Bounces, DSN, Out-of-Office und ähnlicher Kram. Der leere Absender sollte nicht für automatisch generierten Inhalt (Newsletter) verwendet werden und E-Mails bei denen mich überhaupt nicht interessiert ob es zugestellt wird oder eine Rückmeldung kommt sollte man vielleicht gar nicht verschicken. Bei Newslettern sollte man als Envelope Sender eine spezielle Adresse für Bounce Handling etc. verwendet und im Header Mail-from eine Adresse für manuelle Rückmeldungen (Antworten). Wenn irgend etwas unzustellbares als Envelope Sender verwendet wird, steht es jedem frei den Mist zu verwerfen und genau das wird mit address verification im Zweifelsfall getan.
Man kann es natürlich auch anderst machen, sollte sich aber nicht wundern wenn das keiner haben will.
Gruß
Andreas
participants (5)
-
Joachim Fahrner -
Jost Krieger -
lst_hoe02＠kwsoft.de -
Martin Steigerwald -
Walter H.