Jaka jest najlepsza metoda wysyłania wiadomości e-mail w imieniu domen moich klientów?


15

Chciałem poznać najlepszy sposób, aby mój serwer pocztowy wysyłał e-maile w imieniu domen moich klientów, nie będąc na szarej liście, a także unikając problemów związanych z odrzutami.

Czytałem kilka innych pytań tutaj , tu i tutaj, ale żadne nie analizuje wszystkich możliwych rozwiązań. Oto kilka możliwości, które chciałbym porównać:

ZA.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>  # mymailserver.com same IP as myapp.com
DATA
  From: <res@client.com>
  Sender: <do-not-reply@myapp.com>

Pytanie : To właśnie robi Gmail. Jest to nagłówek msg „From:”, który ma inną domenę, a nie nadawca koperty.
emailclients pokaże „From: res@client.com przez do-not-reply@myapp.com” lub „From: do-not-reply@myapp.com w imieniu Res@client.com” , co nie jest problemem dla mnie.
Czy to wpłynie negatywnie na reputację mojej domeny, fakt, że nagłówek „Od:” ma inną domenę? (a jeśli to nie Google to robi…)

B.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>
DATA
   From: <res@client.com>
   # same as A, but no "Sender:"

Wygląda na to, że Google kiedyś to zrobił i nazwał to błędem http://groups.google.com/group/Gmail-Help-Message-Delivery-en/browse_thread/thread/f651cb1db5d9dd23/3a8bcd0548487863?lnk=gst&q=%22on+behalf + of% 22 & pli = 1
Błąd usunął „Sender:” z ich wiadomości, a „via” nie pojawił się w kliencie e-mail. (RFC mówi, że MUSI być obecny, jeśli nie jest taki sam jak „Od:”)

DO.

HELO mymailserver.com
MAIL FROM<res@client.com>
DATA 
  From: <res@client.com>

To tak, jakby klient.com wysyłał wiadomość (MAIL FROM też jest „sfałszowany”). Ale jeśli domena client.com jest dobrze znana lub ma wpis SPF w swoim DNS, musiałbym zmienić jej DNS, pozwalając mymailserver.com na wysyłanie wiadomości w ich imieniu. (To dla mnie niemożliwe z powodu nb klientów, a także niektórzy z moich klientów nie mają kontroli nad swoimi domenami, tj. używają samych @ gmail.com)

RE.

HELO mymailserver.com    
MAIL FROM<do-not-reply@myapp.com>
DATA 
  From: <do-not-reply@myapp.com>
  Reply-to: <res@myclient.com>

Pytanie : To jest najprostsze, dodam tylko nagłówek „Odpowiedz na:”. Czy to naprawdę jest brane pod uwagę CAŁY CZAS przez klientów e-mail? Czy można to również postrzegać jako fałszowanie, dodawanie różnych domen do nagłówka „Odpowiedź do” i mieć zły wpływ na reputację mojej domeny?
- RFC mówi tylko, że „jeśli istnieje pole Odpowiedz-do, wówczas odpowiedź POWINNA kierować się na adresy wskazane w tym polu, a nie na adresy wskazane w polu Od”.
- Tylko etykieta nagłówka „From:” byłaby „sfałszowana”:
„From: myclient.com (przez myapp.com) <do-not-reply@myapp.com>”.


Podczas czytania RFC „POWINNY” oznacza, że ​​jest to bardzo silna rekomendacja. Jedynym powodem, dla którego klient w większości przypadków tego nie zrobił, jest to, że jest stary i nie został zaktualizowany od czasu napisania RFC. Zobacz RFC 2119, aby uzyskać standardowe definicje: ietf.org/rfc/rfc2119.txt
Matthew Scharley


Niestety od 2018 r. Wielu klientów poczty e-mail nadal ignoruje nagłówek odpowiedzi do. meta.discourse.org/t/…
Martin Meixger

Odpowiedzi:


2

Doskonałe pytanie. Właśnie spędziłem kilka godzin badając to samo.

Wcześniej wdrożyłem wiele stron internetowych, które używają Opcji C do formularzy e-mail (głównie z naiwności), ale mamy coraz więcej problemów z dostarczaniem. Dostawcy poczty e-mail stopniowo się zaostrzają. Na przykład Yahoo niedawno zmieniło zasady DMARC, aby prosić odbiorców o odrzucenie wszystkich wiadomości e-mail From: ____@yahoo.combez ważnego podpisu DKIM . Odbieranie serwerów SMTP następujących po DMARC (w tym Gmaila, i prawdopodobnie Hotmail / Outlook.com i Yahoo) będzie mocno odbijało te wiadomości. Uważam, że eBay i Paypal mają podobne surowe zasady, próbując ograniczyć phishing. Niestety określenie nagłówka „Sender” nie pomaga.

(Zastanawiam się, jak Gmail działa w tym przypadku, wysyłając „Z” aliasu Yahoo ?!)

Opcja A byłaby lepszym rozwiązaniem, jeśli wiesz, że wiadomość e-mail „Od” nie ma ścisłych zasad DMARC (możesz to potwierdzić za pomocą prostego zapytania DNS).

Pomimo tego, że jest najmniej atrakcyjna wizualnie, Opcja D jest naprawdę najbezpieczniejsza i to zalecę w przypadku większości naszych przyszłych projektów. Warto zauważyć, że poprzednio używany PayPal Opcji A, ale teraz włączone do Opcji D .

Aby uzyskać dodatkową wiarygodność i zwiększoną szansę dostawy, przyjrzałbym się implementacji SPF i / lub DKIM. Te i inne rzeczy są wymienione w Wytycznych Google dla nadawców masowych, które okazały się pomocne.


1

Nie jestem pewien, czego chcesz. Nie ma „bezpiecznego” ani „niebezpiecznego” sposobu robienia tego, co chcesz.

Zawsze wolałbym D). Dodatkowo dodałbym rekordy SPF. Ale, jak powiedziałem, nie jest to bezpieczniejsze ani nieprzejrzyste od innych (cokolwiek masz na myśli).

Nagłówek odpowiedzi w żaden sposób nie wpływa na reputację. Radzi tylko klientowi, aby używał tego adresu do odpowiedzi (Duh, może właśnie stąd pochodzi nazwa ?!). Jeśli klient zastosuje się do tego zalecenia, nie jest to gwarantowane.


Przez „bezpieczny” mam na myśli zminimalizowanie prawdopodobieństwa, że ​​moja domena będzie szarej listy, błędnie uznana za spoofera / spamera ze względu na wybrane przeze mnie rozwiązanie. Tak, jeśli skorzystam z D, mogę rozważyć dodanie wpisu SPF do mojej domeny i podpisanie wiadomości przy użyciu DKIM.
dgaspar

Zredagowałem swoje pytanie i próbowałem je wyjaśnić.
dgaspar

@dgaspar Greylisting jest oparty na kopertach. Twoja treść (od :, nadawca: ...) jest całkowicie ignorowana. Ponieważ każdy może napisać dowolny adres e-mail jako nadawca, każdy adres nadawcy jest uważany za sfałszowany. Z wyjątkiem podpisywania wiadomości e-mail za pomocą SPF lub DKIM.
mailq

0

Dwa niezawodne rozwiązania:

  1. poproś klientów o dodanie Twojego serwera pocztowego do rekordu domeny SPF
  2. poproś klientów o podanie poświadczeń konta e-mail (adres IP serwera poczty, nazwa użytkownika, hasło) i użycie ich w aplikacji do połączenia się z serwerem poczty i wysłania wiadomości e-mail (w rzeczywistości tworzysz klienta poczty w aplikacji).
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.