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

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: autor@example.com
DO: adresat@example.com
SENDER: webapp@mycompany.com

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.

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.

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.