Qual è il metodo migliore per inviare e-mail per conto dei domini dei miei clienti?


15

Volevo sapere il modo migliore per fare in modo che il mio server di posta inviasse e-mail per conto dei domini dei miei clienti, senza essere inserito nella greylist ed evitando anche problemi di rimbalzo.

Ho letto alcune altre domande qui , qui e qui, ma nessuna esplora tutte le possibili soluzioni. Ecco alcune possibilità che vorrei confrontare:

UN.

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>

Domanda : questo è ciò che fa Gmail. È l'intestazione msg "Da:" che ha un dominio diverso, non il mittente della busta.
emailclients mostrerà "Da: res@client.com via do-not-reply@myapp.com" o "Da: do-not-reply@myapp.com per conto di res@client.com" , che non è un problema per me.
Ora, questo influenzerà gravemente la reputazione del mio dominio, il fatto che l'intestazione "Da:" abbia un dominio diverso? (e se non è Google che lo sta facendo ..)

B.

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

Sembra che Google una volta abbia fatto questo e lo abbia chiamato un errore http://groups.google.com/group/Gmail-Help-Message-Delivery-en/browse_thread/thread/f651cb1db5d9dd23/3a8bcd0548487863?lnk=gst&q=%22on+behalf + di% 22 & pli = 1
Un bug ha rimosso il "Mittente:" dai loro messaggi e la "via" non è stata visualizzata nel client di posta elettronica. (La RFC afferma che DEVE essere presente se non è uguale al "Da:")

C.

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

È come se client.com stesse inviando il messaggio (anche MAIL FROM è "contraffatto"). Ma se il dominio client.com è noto o ha una voce SPF nel suo DNS, dovrei modificare il suo DNS, permettendo a mymailserver.com di inviare messaggi a loro nome .. (Questo è impossibile per me a causa del nb . di clienti, e anche alcuni dei miei clienti non hanno il controllo sui loro domini, ovvero usano direttamente @ gmail.com)

D.

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

Domanda : questa è la più semplice, aggiungerei solo un'intestazione "Rispondi a:". Questo è davvero preso in considerazione TUTTO IL TEMPO dai client di posta elettronica? Anche questo può essere percepito come parodia, aggiungendo domini diversi all'intestazione "Rispondi a" e può avere una cattiva influenza sulla reputazione del mio dominio?
- La RFC dice solo che "se esiste il campo Rispondi a, la risposta DOVREBBE andare agli indirizzi indicati in quel campo e non agli indirizzi indicati nel campo Da".
- Solo l'etichetta di intestazione "Da:" verrebbe "falsificata":
"Da: myclient.com (tramite myapp.com) <do-not-reply@myapp.com>".


Quando si leggono le RFC, "DOVREBBE" significa che è una raccomandazione molto forte. L'unico motivo per cui un cliente non dovrebbe nella maggior parte dei casi è perché è vecchio e non è stato aggiornato da quando è stato scritto RFC. Vedere RFC 2119 per le definizioni standard: ietf.org/rfc/rfc2119.txt
Matthew Scharley,


Sfortunatamente a partire dal 2018 molti client di posta elettronica continuano a ignorare l'intestazione Rispondi a. meta.discourse.org/t/…
Martin Meixger,

Risposte:


2

Ottima domanda Ho appena trascorso diverse ore a cercare la stessa cosa.

In precedenza avevo distribuito numerosi siti Web che utilizzano l' opzione C per i moduli di posta elettronica (principalmente per ingenuità), ma stiamo riscontrando un numero crescente di problemi di consegna. I provider di posta elettronica si stanno gradualmente rafforzando. Ad esempio, Yahoo ha recentemente modificato la propria politica DMARC per chiedere ai destinatari di rifiutare tutte le e-mail From: ____@yahoo.comsenza una firma DKIM valida . La ricezione di server SMTP che seguono DMARC (che include Gmail, e probabilmente Hotmail / Outlook.com e Yahoo) farà rimbalzare questi messaggi. eBay e Paypal hanno politiche rigorose simili, credo, nel tentativo di ridurre il phishing. Purtroppo specificare un'intestazione "Mittente" non aiuta.

(Mi chiedo come funziona Gmail in questo caso quando si invia "Da" un alias Yahoo ?!)

L'opzione A sarebbe un'opzione migliore se si conosce che l'e-mail "Da" non ha un rigido criterio DMARC (è possibile confermarlo tramite una semplice query DNS).

Nonostante sia il meno attraente dal punto di vista visivo, l' Opzione D è davvero la più sicura ed è ciò che consiglierò per la maggior parte dei nostri progetti futuri. Ne vale la pena di notare che PayPal utilizzato in precedenza opzione A, ma ora sono passati a Opzione D .

Per ottenere ulteriore credibilità e maggiori possibilità di consegna, vorrei esaminare l'implementazione di SPF e / o DKIM. Queste e altre cose sono menzionate nelle Linee guida per i mittenti di massa di Google che ho trovato utili.


1

Non sono sicuro di quello che vuoi. Non esiste un modo "sicuro" o "non sicuro" per fare ciò che desideri.

Preferirei sempre D). Inoltre aggiungerei i record SPF. Ma come ho detto, questo non è più sicuro o pericoloso degli altri (qualunque cosa tu intenda con esso).

L'intestazione Reply-To non influenza in alcun modo la reputazione. Consiglia solo al client di utilizzare quell'indirizzo per le risposte (Duh, forse è da qui che viene il nome ?!). Se il cliente segue questa raccomandazione non è garantita.


Con "sicuro" intendo minimizzare le possibilità che il mio dominio venga greylist, erroneamente considerato uno spoofer / spammer a causa della soluzione che ho scelto. Sì, se vado con D, posso prendere in considerazione l'aggiunta di una voce SPF al mio dominio e la firma dei messaggi utilizzando DKIM.
dgaspar,

Ho modificato la mia domanda e ho cercato di chiarirlo ..
dgaspar,

@dgaspar Greylisting è basato su buste. Quindi il tuo contenuto (da:, mittente :, ...) è totalmente ignorato. Poiché tutti possono scrivere qualsiasi indirizzo di posta come mittente, ogni indirizzo del mittente è considerato contraffatto. Tranne che firmi la tua posta con SPF o DKIM.
mailq

0

Due soluzioni affidabili:

  1. chiedere ai clienti di aggiungere il tuo mailserver nel loro record di dominio SPF
  2. chiedi ai clienti di fornirti le credenziali di un account di posta elettronica (indirizzo IP server, nome utente, password) e di utilizzarli all'interno dell'applicazione per collegarti al server di posta e inviare e-mail (in realtà crei un client di posta elettronica all'interno dell'applicazione).
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.