Come migliorare l'invio di e-mail e l'affidabilità delle consegne?

Question

L'applicazione corrente utilizza Simple Java Mail per inviare email di coppia al giorno, ma alcune e-mail non arrivano mai al client.

In base ai registri del server delle applicazioni ci sono stati alcuni timeout del server di posta ma questo non spiega tutti i casi delle e-mail mancanti. L'aggiunta di una funzione di riprova potrebbe aiutare con il problema di timeout, ma esistono altri approcci per migliorare l'affidabilità dell'email in generale?

Answer 1

È la natura di SMTP che non implementa l'integrità transazionale.

Circa 6 anni fa ho fatto un'analisi dettagliata del perché le mail dell'azienda in cui lavoravo in quel momento stavano fallendo. Ho potuto vedere solo fino all'MTA ricevente, ma questo ha mostrato una forte correlazione tra il tipo di MTA e il tasso di errore (a quel tempo, Novell Groupwise e Sendmail sul lato remoto erano i più affidabili, MSExchange il minimo, con qmail e altri nel mezzo). Si noti che questo è stato altamente empirico e potrebbe aver rispecchiato la scelta del prodotto rispetto alle competenze disponibili piuttosto che i problemi intrinseci in specifici MTA, e ora è piuttosto datato. Inoltre, non è qualcosa che puoi controllare in modo efficace.

Anche se, dal momento che hai avuto l'opportunità di sviluppare e implementare la propria logica in cima al MTA, non v'è alcuna garanzia che:

1) se un messaggio non riesce dopo aver lasciato il vostro MTA otterrete qualsiasi notifica rimbalzo

2) se si invia un messaggio con una richiesta DSN (vedi RFC 1891) che il sistema remoto effettivamente restituire il DSN

le cose più importanti che potete fare per migliorare la deliverability è sapere molto su SMTP, mantenere il proprio MTA e configurarlo di conseguenza. Al giorno d'oggi uno dei problemi chiave è che tutti cercano di fermare lo spam e tutti hanno il loro metodo per farlo. E di solito non ti diranno la ricetta per la loro salsa segreta. In effetti, con il filtraggio bayesiano, potrebbero non sapere nemmeno!

Immagino che il prossimo porto di scalo (dopo aver controllato che il tuo SPF sia restrittivo e pubblicato e che tu non sia RBL'd) sarebbe guardare come stabilisci se la tua posta viene consegnata - come Ho detto, non puoi fare affidamento sui DSN. Non puoi fare affidamento sul bugging delle tue email (ad esempio inviandole come HTML con, ad esempio) poiché la maggior parte dei MUA non caricherà il contenuto remoto (di nuovo per impedire lo spam). Che lascia solo l'opzione di mantenere il contenuto server e l'invio di un link cliccabile al contenuto originale. Ma questo assume di nuovo che i tuoi destinatari vogliano sempre leggere il tuo messaggio.

C.

Answer 2

Se si desidera inviare solo un paio di e-mail al giorno a un gruppo finito di destinatari e questo è tutto, provare a inviarli tramite un account Gmail.

Answer 3

Impostare un server di posta di qualità di produzione disponibile per l'applicazione e lasciare che gestisca tutti i dettagli molto sporchi di invio di posta affidabile. Probabilmente stai colpendo alcuni dei limiti come il graylisting progettato per tenere lontani gli spambots.

Uno scenario ragionevolmente semplice sarebbe Postfix su una macchina Linux. Personalmente mi piace Ubuntu

Answer 4

Thorbjørn e symcbean hanno entrambi fornito un sacco di informazioni utili, ma può essere schiacciante nella sua completezza.Cercherò di renderlo più accessibile:

La cosa peggiore che puoi fare è creare un client SMTP nella tua applicazione e affidarti a questo per inviare posta in qualche parte del mondo. Una soluzione molto migliore è quella di eseguire un server MTA e/o SMTP "standard" sulla propria confezione locale o, nella peggiore delle ipotesi, all'interno della propria rete.

Quindi la tua app deve solo arrivare alla posta fino al tuo server di posta, che si spera possa essere sulla porta 25 sulla stessa macchina. Nessuna codifica SSL, nessun filtro spam, non un mucchio di cose che possono andare storte. Inoltre, se il tuo server di posta si trova sullo stesso computer della tua app, saranno (di solito) entrambi inattivi o inattivi.

Una volta che la tua app ha inserito la posta nel tuo server di posta locale (che è veloce e quasi infallibile), è il problema del server quello di far arrivare la posta alla destinazione finale. Su un server Linux avrai qualcosa come Sendmail, qmail, exim o postfix installati; su Windows, non lo so.

Uno qualsiasi di questi server di posta "pronti all'uso" è estremamente competente per ricevere la posta. Una ripetizione automatica è già incorporata, con tentativi dopo (ad esempio) 1 ora, 2 ore, 4, 12, 24 e 48 ore. Il tuo server di posta proverà il più maleducato a consegnare la tua posta, e lo farà senza ulteriori sforzi da parte tua. I tentativi falliti verranno visualizzati nel registro del server di posta, e potrai analizzarli e trarre le tue conclusioni. Se fallisce dopo l'ultimo tentativo possibile, questo viene anche annotato nel file di registro e si può concludere che qualcosa è andato storto sul lato ricevente. Tutto questo potere è già integrato e non dovresti nemmeno pensare di provare a crearlo in un tuo client di posta.

Nota finale: è possibile che il trasferimento abbia esito positivo, ovvero il messaggio è stato recapitato, ma successivamente è stato considerato come spam dal server o dal client di posta del destinatario; o il destinatario (umano) l'ha semplicemente cancellato per sbaglio. Nessun software risolverà il problema con certezza.

Answer 5

A mio parere, l'esecuzione del proprio server di posta sta rapidamente diventando un ricordo del passato.

Se la mia app invierà più di poche e-mail, di solito installo un provider di servizi di posta elettronica e ci dimentico. Molti di questi ti permettono di usare il loro SMTP nella tua applicazione.

Come bonus, la maggior parte di questi ti mostrerà le statistiche su chi fa cosa con le tue e-mail.

Alcuni dei nomi più noti in quello spazio sono sendgrid, mailjet e postmarkApp, ma è possibile trovare un interessante confronto here