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 at ... 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 at local>
To: <walter at local>
Sender: <office at company.com>
Reply-to: <office at company.com>
Subject: Test

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

Von:  office at company.com im Auftrag von root at local    An: walter at 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;

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 3491 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : <http://de.postfix.org/pipermail/postfix-users/attachments/20170726/dfde5063/attachment.bin>