fragen stichworte

Zulässige Gründe, dass SMTP „MAIL FROM:“ nicht mit dem „From:“ -Header in DATA übereinstimmt

Gibt es einen legitimen Grund dafür, dass das SMTP-Feld "MAIL FROM:" nicht mit dem Feld "Von:" im DATA-Abschnitt einer Nachricht übereinstimmt, außer Mailing-Listen?

Von https://stackoverflow.com/questions/1750194/smtp-why-does-email-needs-envelope-und-was -does-the-envelope-mean:

„Um jedoch die Metapher der Schneckenpost fortzusetzen, enthalten die meisten professionellen Briefe die Adressen des Absenders und des Empfängers, die auf dem Brief selbst aufgedruckt sind. Diese Adressen sind für den Postboten nicht notwendig, sondern dienen dem Empfänger. Daher ist es sinnvoll, dass E-Mails auf dieselbe Weise funktionieren. “

Das Problem bei dieser Logik liegt hier: "Höflichkeit beim Empfänger". Das Einfügen der Absenderadresse in eine E-Mail über SMTP ist keine Höflichkeit. es ist erforderlich, wenn der Empfänger eine Antwort senden kann.

Von: Wie kann der From-Header auf MAIL FROM in Postfix beschränkt werden?:

“Aber wenn Sie wirklich From: und MAIL FROM sicherstellen wollen, müssen Sie header_checks anwenden, damit Return-Path: From von:”

entspricht

Welche Auswirkungen hat das? Mailinglisten wären natürlich ein Problem. Gibt es andere rechtmäßige Verwendungen von unterschiedlichen Header-Informationen "MAIL FROM:" und "From:"?

antworten

Es gibt viele Gründe, warum die Adressen von Header und Envelope From möglicherweise nicht übereinstimmen. Die meisten betreffen automatisierte Prozesse zum Versenden von E-Mails, bei denen Zustellungsprobleme an eine Adresse gemeldet werden müssen, die nicht dafür repräsentativ ist, wer die E-Mail gesendet hat oder an wen sie im Namen gesendet wurde oder auf die geantwortet werden sollte. Ein gutes Beispiel sind Mailinglisten, auf die Sie hingewiesen haben.

Der Hauptgrund, warum eine von einem E-Mail-Client eines Benutzers gesendete Nachricht von Adressen abweichen kann, ist die Weiterleitung von E-Mails. Der E-Mail-Inhalt sollte dann dem Original einigermaßen treu sein. Im Falle von Zustellungsfehlern sollten diese dem Benutzer gemeldet werden, der die E-Mail weitergeleitet hat, nicht dem ursprünglichen Absender.

Neben dem SMTP-Header gibt es eine Reihe von MIME-Headern, mit denen verschiedene Programme versuchen, zwischen dem ursprünglichen Absender und dem Zwischensender zu unterscheiden, und/oder der bevorzugten Adresse, an die Fehler gemeldet werden sollen.Eg Antworten, Absender, Ursprünglich-From, Errors-To usw. usw., jeweils mit unterschiedlichen Semantiken. Einige davon unterstützen Standards, während viele andere dies nicht tun, sie können aber trotzdem verwendet werden. Das Verhalten verschiedener Mailprogramme in der Praxis ist sehr unterschiedlich.

Ob eine Art der Adressierung von E-Mails ratsam ist, unterscheidet sich von der Frage, ob sie "legitim" ist. Wenn Sie die Legitimität in Betracht ziehen, etwa in Bezug auf Richtlinien zum Umgang mit potenziellem Spam, dann können Sie auf diese Weise nicht einfach zwischen verschiedenen Arten unterscheiden.

Denken Sie über die DKIM-Signatur von E-Mails und die SPF-Authentifizierung von Mail-Servern für E-Mail-Domänen nach. Wenn Sie viel E-Mail senden, kann es wichtig sein, Ihre E-Mail auf diese Weise zu authentifizieren. Dies kann Auswirkungen auf die Adressierung von E-Mail-Absendern haben, da Sie nur E-Mails authentifizieren können, die sich auf Domänen beziehen, für die Sie über Berechtigungen verfügen .

-

Erweitert auf Anfrage:

Ein MIME-Reply-To-Header weist einen MUA (Mail User Agent, normalerweise E-Mail-Client einer Person) an, Antworten an eine andere Adresse anstatt an die MIME-From-Adresse zu senden. Dies wird von einem MTA (Mail Transport Agent) nicht für Fehler verwendet.

Normalerweise verwendet ein MTA die Adresse "MAIL From" des SMTP-Umschlags, um Fehler zu senden. Die IT kann mit einem MIME-Header "Errors-To", einer MTA-Anweisung, überschrieben werden. Es wird nicht von allen MTAs berücksichtigt, daher ist dies ein schlechterer Mechanismus für das Festlegen der SMTP-Umschlagadresse. Es gibt jedoch viele Umstände, unter denen MIME-Header in einer Nachricht festgelegt werden können, nicht jedoch die SMTP-Umschlagadresse. Beispielsweise kann sich Software, die in einer gemeinsam genutzten Hosting-Umgebung ausgeführt wird, in dieser Situation befinden.

"Absender" ist als Anweisung an Softwareagenten viel unklarer, gibt jedoch an, an wen oder was die E-Mail gesendet wurde, die sich von der Absenderadresse unterscheidet, die eher aussieht, an wen die E-Mail gesendet wurde. Wenn Sie z. B. ein Online-E-Mail-Formular für Ihren Politiker ausfüllen, ist es sehr angebracht, dass die E-Mail Ihre E-Mails im Header "Von" verwendet, jedoch eine Absenderadresse für die Organisation enthält, die das Formular eingerichtet hat.

"Originally-From" wird von einigen MUA-Software beim Weiterleiten von E-Mails verwendet, wobei die Adresse des Weiterleiters für den "From" -Header verwendet wird. Andere MUAs lassen die Absenderadresse allein und verwenden einen 'Resent-From'-Header. Ob MUAs diese verschiedenen Header-E-Mails erhalten, interpretiert die Header sinnvoll oder zeigt sie sogar an. An wen kann die Antwort bei Beantwortung einer an Sie weitergeleiteten E-Mail standardmäßig gesendet werden? Vielleicht am besten, um den 'Reply-To'-Header festzulegen?

Das Verhalten von MUAs ist variabel, schlecht definiert und scheint sich im Laufe der Zeit zu verbessern. Im Gegensatz dazu ist die Semantik der Hüllkurve wesentlich definierter. In der Regel gab es eine starke Position, dass sich MTAs nie mit den MIME-Headern befassen sollten. Da MTAs jedoch zunehmend für den Inhalt von E-Mails verantwortlich gemacht werden (siehe SPF und die aufkommenden DMARC-Standards), besteht der Druck, dass die Position dieser Position verschlechtert wird. Langjährige Mechanismen wie "Errors-To" stehen auch im Konflikt mit der Vorstellung, dass MTAs nicht auf den Inhalt der Kopfzeilen achten. Dies ist ein Grund dafür, warum diese Mechanismen immer inkonsistent angewendet wurden. Die Philosophie der Softwareautoren variiert.

Es könnte hilfreich sein, sich über http://tools.ietf.org/html/rfc4021#section-2 zu informieren. Denken Sie jedoch daran, dass die tatsächlichen Praktiken der Vielzahl von Mail-Software dort unterschiedlich sind auf eine Weise, die nicht notwendigerweise gesegnet ist.

Es ist gut, wenn Sie versuchen, eine klare Philosophie zu entwickeln, wie E-Mails Ihrer Meinung nach verwendet werden sollen. Erwarten Sie jedoch nicht, dass alle anderen Dinge so tun, wie Sie es für richtig halten.

Automatisierte Verarbeitung ist ein wichtiger Grund. Sie möchten in der Lage sein, alle Bounces/Autoreplys/Fehler zu senden, die getrennt verarbeitet werden sollen, sonst verschwinden diese Nachrichten oder werden ignoriert, oder irgendein schlechter SAP muss sie durchforsten. Ja, das Hinzufügen eines X-Headers für die Verarbeitung ist möglich, aber die meiste Zeit springt/etc. enthält nicht die ursprüngliche E-Mail oder nur einen verfälschten Teil davon und Sie werden nicht in der Lage sein, die Quelle zu erhalten.

Sagen Sie beispielsweise, dass sich jemand auf Ihrer Website anmeldet, und senden Sie ihm eine E-Mail, in der er sich für die Registrierung bedankt. Ihr MAILFROM und Ihr From könnten folgendermaßen aussehen:

MAIL FROM: <user-signup-123123123@bounces.example.com>
From: Website X <noreply@example.com>
user-signup-123123123@bounces.example.com

und ein automatisierter Prozess kann die Benutzer-ID (den 123123123-Teil) und den Teil des Systems, der den Bounce (den -signup-Teil) erstellt hat, leicht aus der Kopfzeile ziehen und diesen Benutzer einfach als deaktiviert löschen.

Die E-Mail von: In der SMTP-Konversation soll der Ort sein, an dem Bounces abgehen Der From: -Header im Nachrichtentext wird zur Anzeige beim Empfänger und als Antwortadresse verwendet, wenn der Reply-To-Header nicht festgelegt ist.

E-Mails, die keinen Absprung erzeugen sollen, sollten den leeren Absender in den Umschlag setzen, z Beispiel: Eine Empfangsbestätigung hat normalerweise: mail from:<> mit dem Namen des Benutzers in der von: header.

Eine andere Situation ist, wenn ein Mailserver BATV verwendet, um gefälschte Bounces abzulehnen. Die Mail von: wird in der Form prvs=tag-value=mailbox@example.com sein.

Wenn ich meine Kopfzeilen oder die Frage nicht richtig lese, werden E-Mails von meinem BlackBerry vom BlackBerry-Server gesendet, und im Grunde genommen stimmt keines der Felder überein. Ein kleiner Prozentsatz von Benutzern, merke ich. Ich habe das kürzlich bei der Auswertung meines Mail-Servers untersucht. Im Folgenden finden Sie eine anonymisierte E-Mail, die von meinem BlackBerry an mein Google Mail-Konto gesendet wurde:

Delivered-To: recipientusername@gmail.com
Received: by 10.50.11.138 with SMTP id q10csp217364igb;
        Wed, 14 Aug 2013 00:18:53 -0700 (PDT)
X-Received: by 10.42.83.84 with SMTP id g20mr4290552icl.10.1376464731205;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Return-Path: <SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com>
Received: from smtp08.bis6.us.blackberry.com (smtp08.bis6.us.blackberry.com. [74.82.85.8])
        by mx.google.com with ESMTP id lq6si7427361icb.102.2013.08.14.00.18.51
        for <recipientusername@gmail.com>;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Received-SPF: pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) client-ip=74.82.85.8;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) smtp.mail=SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com
Received: from b15.c8.bise6.blackberry ([192.168.0.115])
    by srs.bis6.us.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7InfH019786
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:49 GMT
Received: from 172.29.201.172 (cmp2.c8.bise6.blackberry [172.29.201.172])
    by b15.c8.bise6.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7IlCt013236
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:47 GMT
X-rim-org-msg-ref-id: 587275596
Message-ID: <587275596-1376464726-cardhu_decombobulator_blackberry.rim.net-631052459-@b17.c8.bise6.blackberry>
Reply-To: senderusername@example.com
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
Subject: Test
To: "Recipient Name" <recipientusername@gmail.com>
From: senderusername@example.com
Date: Wed, 14 Aug 2013 07:18:45 +0000
Content-Type: text/plain
MIME-Version: 1.0

Test
Sent via BlackBerry by AT&T