Prawidłowe użycie nagłówka SMTP „Sender”?

20

Nasza aplikacja internetowa wysyła wiadomości e-mail do osób, gdy ktoś publikuje nowe treści. Zarówno nadawca, jak i odbiorca zdecydowali się na otrzymywanie wiadomości e-mail z naszej aplikacji. Podczas przygotowywania takiej wiadomości ustawiamy następujące nagłówki SMTP:

OD: [email protected]
DO: [email protected]
SENDER: [email protected]

Postanowiliśmy użyć adresu e-mail autora w nagłówku FROM, aby zapewnić odbiorcy jak najlepsze wrażenia; gdy widzą wiadomość w swoim kliencie pocztowym, autor jest czysty. Aby uniknąć fałszowania, dodaliśmy nagłówek SENDER (z własnym adresem e-mail naszej firmy), aby wyjaśnić, że wysłaliśmy wiadomość w imieniu autora. Po odczytaniu RFC 822 i 2822 wydaje się, że jest to zamierzone użycie nagłówka nadawcy.

Większość serwerów odbierających pocztę wydaje się dobrze sobie z tym radzić; wiadomość e-mail jest dostarczana normalnie (przy założeniu, że skrzynka odbiorcza istnieje, nie przekracza limitu itp.). Jednak podczas wysyłania wiadomości z adresu w domenie do adresu w tej samej domenie niektóre domeny odbierające odrzucają wiadomości z odpowiedzią taką jak:

571 niepoprawny adres IP - psmtp (w odpowiedzi na polecenie RCPT TO)

Myślę, że oznacza to, że serwer odbierający widział tylko, że adres nagłówka FROM znajdował się we własnej domenie i że wiadomość pochodzi z serwera, którego nie uważała za autoryzowanego do wysyłania wiadomości dla tej domeny. Innymi słowy, serwer odbierający zignorował nagłówek SENDER.

Mamy obejście: aplikacja internetowa przechowuje listę takich domen, które wydają się ignorować nagłówek SENDER, a gdy nagłówki FROM i TO znajdują się w takiej domenie, ustawia zamiast tego nagłówek FROM na nasz własny adres e-mail. Ale ta lista wymaga konserwacji.

Czy istnieje lepszy sposób na osiągnięcie pożądanego doświadczenia? Chcemy być „dobrym obywatelem” sieci, a wszystkie zaangażowane strony - nadawcy i odbiorcy - chcą uczestniczyć i otrzymywać te wiadomości. Jedną z możliwości jest zawsze używanie naszego firmowego adresu e-mail w nagłówku FROM i dołączanie nazwiska / adresu autora do tematu, ale wydaje się to trochę niezdarne.

Eric Rath
źródło
Dlaczego nie użyć From: authorzamiast From: [email protected]?
Pacerier

Odpowiedzi:

16

Patrzysz na złe rzeczy. To są nagłówki wiadomości . Powinieneś patrzeć na kopertę SMTP . (Sposób określania koperty zależy od tego, jak dokładnie aplikacja przesyła pocztę do systemu pocztowego. W wielu systemach koperta jest określana za pomocą argumentów wiersza polecenia do programu narzędziowego do przesyłania poczty.) W zależności od tego, kiedy dokładnie jest w transakcji protokołu postanawia wydać odpowiedź 571, serwer przekaźnika SMTP może nawet nie widzieć nagłówków wiadomości.

Tekst odpowiedzi mówi, że administrator tego konkretnego serwera przekaźnika SMTP, z którym rozmawiasz, ograniczył to, co możesz umieścić w kopercie SMTP. Wygląda na to, że narzeka na część koperty adresata. Ale może to opóźniać sprawdzanie poprawności nadawcy koperty do czasu określenia pierwszego odbiorcy, więc może narzekać na nadawcę.

Należy zauważyć, że nadawca jest koperta gdzie komunikaty o stanie dostawy są wysyłane, a Ty nie chcesz mieć te skierowane do przypadkowych ludzi na całym świecie. (Pomijając fakt, że wiele osób się nie podoba, to nie ma sensu dla komunikatów o stanie dostawy dla poczty zostać zwrócone do nikogo oprócz ciebie.) Określa siebie jako nadawcę koperty.

Nawiasem MXmówiąc, nie jest wymagane zapisywanie zasobów. Serwer przekaźników SMTP może być zlokalizowany przez rekordy zasobów Ai AAAAprzy braku MXrekordów zasobów. Patrz RFC 5321 § 5.1.

JdeBP
źródło
Sprawdziłem RFC przed wdrożeniem sprawdzania rekordów MX i nauczyłem się tego samego: sprawdź, czy nie ma rekordu zastępczego Rekord przy braku rekordu MX. Zajrzę do koperty SMTP; dzieki za sugestie.
Eric Rath,
Sprawdziłem kopertę SMTP, przetestowałem to. Masz rację - niepoprawnie założyłem, że wszystkie sprawdzanie pochodzenia użyłoby nagłówka wiadomości „Od”, ale wygląda na to, że zamiast tego używana jest koperta.
Eric Rath,
5

Mogę się mylić, ale najbardziej prawdopodobną przyczyną powyższego błędu, szczególnie w przypadku Postini, jest to, że domeny, w których się odrzucasz, mają ścisłe zasady SPF. Większość serwerów pocztowych z funkcją sprawdzania SPF będzie sprawdzać tylko nagłówek From: nie będzie ich obchodził nagłówek Sender.

Aby sprawdzić, czy tak jest, uruchom „dig + short TXT domain.com”, gdzie domain.com jest tym, co wyświetla komunikat o błędzie. Powinieneś odzyskać coś takiego:

„v = spf1 mx -all”

Ważną częścią jest wszystko. Oznacza to, że właściciel domeny oświadczył, że zawsze będzie wysyłać wiadomości e-mail z serwerów, które działają jak ich serwery pocztowe, a wszystkie inne wiadomości będą odrzucane.

Na szczęście w takim przypadku możesz aktywnie sprawdzić przed wysłaniem wiadomości e-mail! Poproś WebApp o sprawdzenie SPF, gdy użytkownik poda swój adres e-mail. Jeśli obowiązują ścisłe zasady, dodaj domenę do listy. Nie brakuje bibliotek dla wszystkich języków, które mogą przeprowadzać kontrole SPF.

Niall Donegan
źródło
Dzięki, to dobry pomysł. Sprawdziłem (z wykopaniem) garstkę domen, które już prezentowały niepożądane zachowanie, a kilka miało rekordy SPF z ~ wszystkimi. Nie jest to więc kompletne rozwiązanie, ale myślę, że trudno będzie znaleźć kompletne rozwiązanie tego problemu. Myślę, że inni wymuszają tę samą podstawową logikę, ale bez przechowywania / publikowania informacji w rekordach SPF.
Eric Rath,
Twój pomysł sugerował wykonanie kolejnej weryfikacji: domena adresu powinna mieć prawidłowy rekord MX. Jeśli ktoś źle wpisuje swój adres e-mail, a błąd występuje w części adresu domeny (np. [email protected]), dostawa nie powiedzie się, ponieważ nie można znaleźć rekordu MX dla domeny (zakładając, że błąd nie spowodował inna, ale wciąż aktualna, domena).
Eric Rath,
Zmieniłem „akceptowaną odpowiedź” na JdeBP poniżej - rozróżnienie między nagłówkiem wiadomości a nagłówkiem koperty naprawdę ją przykuło. Ale dzięki za opinie.
Eric Rath,
5
Korekta: SPF sprawdza „MAIL FROM” w kopercie, a nie nagłówki „From” lub „Sender”.
Simon East