Address verification

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Address verification

Joachim Fahrner
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Address verification

Walter H.
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;    
[hidden email] 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 ...


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Address verification

Martin Steigerwald
In reply to this post by Joachim Fahrner
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,
--
Martin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Address verification

Joachim Fahrner
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Address verification

Martin Steigerwald
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.

--
Martin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Address verification

Walter H.
In reply to this post by Joachim Fahrner
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;


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Address verification

Joachim Fahrner
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Address verification

Walter H.
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: <[hidden email]>
Reply-to: <[hidden email]>
Subject: Test

was in Mail-clients die damit umgehen können - z.B. MS-Outlook - etwa so
angezeigt wird:

Von:  [hidden email] 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;


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Address verification

Joachim Fahrner
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Address verification

Walter H.
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 ...




smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Address verification

Jost Krieger
In reply to this post by Joachim Fahrner


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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Address verification

lst_hoe02

Zitat von Jost Krieger <[hidden email]>:

> 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



smime.p7s (7K) Download Attachment
Loading...