Uzasadnione powody SMTP „MAIL FROM:” nie będzie pasować do nagłówka „From:” w danych


18

Czy istnieje uzasadniony powód, dla którego pole SMTP „MAIL FROM:” nie jest zgodne z polem „From:” w sekcji DATA wiadomości, poza listami adresowymi?

Od /programming/1750194/smtp-why-does-email-needs-envelope-and-what-does-the-envelope-mean :

„Ale, aby kontynuować metaforę ślimakowej poczty, większość listów zawodowych będzie zawierać adresy nadawcy i odbiorcy wydrukowane na samym liście. Adresy te nie są konieczne dla listonosza, ale są uprzejme dla odbiorcy. Dlatego rozsądne jest, aby poczta e-mail działała w ten sam sposób ”.

Problem z tą linią logiki leży tutaj: „dzięki uprzejmości odbiorcy”. Umieszczenie adresu „Od:” w wiadomości e-mail za pośrednictwem SMTP nie jest grzecznością; jest to wymagane, aby odbiorca mógł wysłać odpowiedź.

Od: Jak ograniczyć nagłówek From do dopasowania MAIL FROM w Postfiksie? :

„Ale jeśli naprawdę chcesz zapewnić From: i MAIL FROM, musisz zastosować nagłówki, aby Return-Path: pasuje do:”

Jakie są tego konsekwencje? Listy mailingowe byłyby oczywiście problemem. Czy istnieją inne uzasadnione sposoby wykorzystania różnych informacji nagłówkowych „MAIL FROM:” i „From:”?

Odpowiedzi:


22

Istnieje wiele powodów, dla których adresy Nagłówek i Koperta Od mogą się nie zgadzać. Większość dotyczy zautomatyzowanych procesów wysyłania poczty, w których problemy z dostawą należy zgłaszać na adres, który nie jest reprezentatywny dla tego, kto wysłał pocztę lub kto został wysłany w imieniu lub na kogo należy odpowiedzieć. Listy adresowe, jak wskazałeś, są dobrym przykładem.

Głównym powodem, dla którego wiadomość wysłana z klienta poczty użytkownika może różnić się od adresów, jest przesyłana poczta. Treść wiadomości powinna być w miarę wierna oryginałowi, ale w przypadku błędów dostawy należy je zgłosić użytkownikowi, który przesłał wiadomość e-mail, a nie pierwotnemu nadawcy.

Oprócz nagłówka SMTP istnieje wiele różnych nagłówków MIME, których różne programy używają do rozróżnienia między nadawcą pierwotnym i nadawcą pośrednim i / lub preferowanym adresem do zgłaszania błędów. Np. Odpowiedz na, nadawca, pierwotnie od , Errors-To itp., Każdy z inną semantyką. Niektóre z nich mają obsługę standardów, a wiele innych nie, ale i tak mogą być używane. Sposób, w jaki różne programy pocztowe zachowują się w praktyce, jest bardzo różny.

To, czy wskazany jest sposób adresowania poczty, różni się od tego, czy jest „uzasadniona”, jak pytasz. Jeśli zastanawiasz się nad zasadnością w kontekście czegoś takiego jak zasady postępowania z potencjalnym spamem, nie, nie sądzę, że będziesz w stanie dokonać prostego rozróżnienia w ten sposób.

Pomyśl jednak o podpisywaniu wiadomości e-mail przez DKIM i uwierzytelnianiu SPF serwerów pocztowych dla domen e-mail. Jeśli wysyłasz dużo poczty, ważna może być możliwość jej uwierzytelnienia w ten sposób, co może mieć wpływ na adresowanie poczty z nagłówków, ponieważ możesz uwierzytelniać tylko wiadomości związane z domenami, do których masz uprawnienia .

-

Rozszerzony na życzenie:

Nagłówek MIME „Reply-To” kieruje MUA (Mail User Agent, zazwyczaj klienta poczty osoby) do wysyłania odpowiedzi na inny adres, zamiast adresu MIME „Od”. Nie jest to używane przez MTA (Mail Transport Agent) do takich rzeczy jak błędy.

Zwykle MTA używa adresu SMTP Envelope „MAIL From” do wysyłania błędów. IT można zastąpić nagłówkiem MIME „Errors-To”, który jest instrukcją MTA. Nie wszystkie MTA będą go szanować, więc jest to gorszy mechanizm ustawiania adresu koperty SMTP, ale istnieje wiele okoliczności, w których może być możliwe ustawienie nagłówków MIME w wiadomości, ale nie adres SMTP koperty z. Na przykład oprogramowanie działające w udostępnianym środowisku hostingowym może znaleźć się w takiej sytuacji.

„Nadawca” jest o wiele bardziej niejednoznaczny jako instrukcja dla agentów oprogramowania, ale wskazuje, kto lub co wysłał wiadomość e-mail, jeśli różni się ona od adresu Od, który bardziej przypomina adresata poczty w imieniu. Np. Kiedy wypełniasz internetowy formularz „twój polityk”, byłoby bardzo właściwe, aby otrzymany e-mail używał twojej poczty w nagłówku „Od”, ale miał adres nadawcy powiązany z organizacją, która utworzyła formularz.

„Originally-From” jest używane przez niektóre oprogramowanie MUA podczas przesyłania poczty, przy czym adres spedytora jest używany jako nagłówek „From”. Inne MUA zostawią adres Od w spokoju i użyją nagłówka „Resent-From”. To, czy MUA odbierające te różne nagłówki wiadomości e-mail interpretują je, czy nawet wyświetlają, jest dość zmienne. Odpowiadając na wiadomość, która została do Ciebie przesłana, do kogo domyślnie powinna trafiać odpowiedź? Może najlepiej ustawić nagłówek „Odpowiedz na”?

Zachowanie MUA jest zmienne, a także słabo zdefiniowane, chociaż wydaje się, że z czasem poprawia się. Natomiast semantyka Obwiedni jest znacznie bardziej zdefiniowana. Zazwyczaj istnieje silna pozycja, że ​​MTA nigdy nie powinny zajmować się nagłówkami MIME, ale ponieważ MTA są coraz bardziej odpowiedzialne za treść poczty (np. Patrz SPF i nowe standardy DMARC), istnieje presja na obniżenie jasności tej pozycji. Długotrwałe mechanizmy, takie jak Błędy-To, również kolidowały z pojęciem MTA, które nie patrzą na treść nagłówka, co jest częścią tego, dlaczego mechanizmy te zawsze były niespójnie stosowane. Filozofie autorów oprogramowania są różne.

Przydatne może być przejrzenie strony http://tools.ietf.org/html/rfc4021#section-2 , ale pamiętaj, że rzeczywiste praktyki wielu programów pocztowych różnią się w sposób niekoniecznie błogosławiony.

Dobrze jest wymyślić jasną filozofię tego, w jaki sposób Twoim zdaniem powinna być używana poczta, ale nie oczekuj, że wszyscy inni zrobią rzeczy, które według Ciebie powinny.


Nadal mam czas na przyznanie tej nagrody i jestem zainteresowany dodatkowymi scenariuszami, które wymagałyby użycia nagłówków: `Odpowiedź, Nadawca, Oryginalnie Od, Błędy do '
goodguys_activate

Dziękuję za uzupełnienia. Mam nadzieję, że dobrze zrozumiem, jakie są oczekiwane zachowania MTA, a jakie są. Może Cię również zainteresować to pytanie: Właśnie napisałem na Sec.StackExchange w sprawie białej listy e-maili (podobnie jak BATV) security.stackexchange.com/q/41008/396
goodguys_activate

1
+1, dlaczego tylko 4 głosy?
Pacerier

11

Zautomatyzowane przetwarzanie jest ważnym powodem. Chcesz mieć możliwość wysyłania osobnych odesłań / odpowiedzi automatycznych / błędów do osobnego przetworzenia, w przeciwnym razie wiadomości te znikną lub zostaną zignorowane lub jakiś słaby sok musi je przekopać. Tak, dodanie nagłówka X w celu przetworzenia jest możliwe, ale wiele razy odbija się / etc. nie będzie zawierać oryginalnego e-maila ani tylko jego zniekształconej części i nie będzie można uzyskać źródła.

Załóżmy na przykład, że ktoś rejestruje się w Twojej witrynie, a Ty wysyłasz mu wiadomość e-mail z podziękowaniem za rejestrację. Twój MAILFROM i From może wyglądać następująco:

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

W ten sposób użytkownik widzi „przyjaznego z” w kliencie poczty. Ale jeśli użytkownik nie istnieje, jego MTA wyśle ​​odesłaną wiadomość do:

user-signup-123123123@bounces.example.com

a zautomatyzowany proces może łatwo wyciągnąć identyfikator użytkownika (część 123123123) i część systemu, która utworzyła odbicie (część -signup-) z nagłówka i łatwo usunąć / oznaczyć tego użytkownika jako wyłączonego.


8

Poczta od: w rozmowie smtp jest zaprojektowana jako miejsce, do którego odejdą odbicia Nagłówek Od: w treści wiadomości służy do wyświetlania odbiorcy i jako adres odpowiedzi, jeśli nagłówek Odpowiedz na: nie jest ustawiony.

E-maile, które nie powinny generować odesłania, powinny ustawić pustego nadawcę w kopercie, na przykład pokwitowanie zwrotne zwykle zawiera: mail from:<>nazwę użytkownika w nagłówku from:.

Inną sytuacją jest sytuacja, w której serwer pocztowy używa BATV do odrzucania fałszywych odrzuceń. Wiadomość od: będzie miała postać prvs=tag-value=mailbox@example.com.


Chyba pamiętam nagłówek X dla zwrotów i raportów NDR. Czy wiesz, kiedy i jak to jest wykorzystywane?
goodguys_activate

Nagłówki X zostały pierwotnie dodane jako środek MUA i / lub MTA w celu umieszczenia niestandardowych metadanych i nie są określone w żadnym standardzie, chociaż niektóre stają się standardami defacto. Być może myślisz o typie MIME wieloczęściowego / raportu zdefiniowanym w rfc 6522, który został zdefiniowany, aby pomóc oprogramowaniu w klasyfikowaniu wiadomości, które są automatycznie odsyłane. Będą one nadal wysyłane z pustą kopertą pocztową od:
Richard Salts

1

O ile nie czytam poprawnie nagłówków lub pytania, e-maile z mojego BlackBerry są wysyłane z serwera BlackBerry i zasadniczo żadne pole nie pasuje. Zdaję sobie sprawę z małego odsetka użytkowników. Ostatnio patrzyłem na to, oceniając mój serwer pocztowy. Poniżej znajduje się anonimowy e-mail wysłany z mojego BlackBerry na moje konto Gmail:

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

Jest tego doskonały powód - przepisywanie SPF . Jeśli BlackBerry tego nie zrobi, dostaniesz o wiele więcej błędów SPF wysyłanych z twojego urządzenia.
MikeyB,

To prawda, ale dlatego, że BlackBerry nie używa mojego serwera do wysyłania.
Paul,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.