Sommario:
Stiamo cercando di estendere il nostro uso della posta elettronica a scopi di notifica. Siamo consapevoli che genererà più volume della posta in arrivo, ma siamo selettivi su quali eventi attiviamo la notifica per mantenere alto il rapporto segnale / rumore.
La grande domanda che stiamo affrontando è la progettazione di un sistema che garantisce che l'e-mail sia stata consegnata. Se non viene recapitata un'email, considereremo un evento eccezionale che deve essere esaminato. In realtà, dico garanzie quasi perché non ci sono garanzie reali con la posta elettronica. Stiamo solo cercando una soluzione pratica per assicurarci che l'e-mail sia arrivata là e le esperienze che altri hanno avuto con i vari approcci per garantire la consegna.
TL; DR - Come possiamo progettare un sistema per garantire la consegna delle e-mail? Quali tecniche dovremmo prendere in considerazione in modo che sappiamo che le e-mail sono state consegnate?
Altre preoccupazioni:
La nostra principale area di interesse riguarda le tecniche da utilizzare per sapere quando viene inviato un messaggio che atterra in una casella di posta in arrivo o che non funziona e dobbiamo fare qualcos'altro.
Requisiti aggiuntivi:
- Non siamo nella fase di includere una risposta di escalation, ma lo desidereremo nel futuro o così pensiamo.
- La maggior parte delle notifiche sarà interna alla nostra azienda, ma avremo alcune notifiche inviate a client esterni.
- Alcune delle nostre applicazioni si trovano in un ambiente ospitato. Non abbiamo determinato se tali server possano accedere ai nostri server di posta elettronica aziendali per l'inoltro o se agiranno da server di posta.
Design / moduli base (al momento):
Un modulo per assegnare l'identificazione della tracciabilità
Un modulo per inviare e-mail
Un modulo per ricevere la notifica di consegna (forse questo è lo stesso del modulo email)
Un modulo che controlla i messaggi inviati contro la notifica di consegna e gli avvisi sull'e-mail non consegnata.
Alcuni riferimenti:
Atwood: invia un'email
Tracciamento email
Approcci che abbiamo considerato:
- Richiesta di una risposta (ovvero read-receipt o Message Disposition Notification).
Sembra incline al fallimento poiché abbiamo problemi di compatibilità incrociata a causa di diversi server di posta e software. - Ricevuta di ritorno (alias Notifica dello stato di consegna).
Non sono sicuro che tutti i server di posta rispettino o meno questa richiesta - Richiedere un'azione e quindi provare a rispondere.
Sembra oneroso obbligare i destinatari a svolgere un'attività aggiuntiva non correlata alla risoluzione del problema. E no, non abbiamo trovato un modo per collegare il problema di stabilire se l'email è stata ricevuta o meno. - Forza un accesso di click-through / altro sito.
Simile a richiedere una sorta di azione, questo sembra un onere aggiuntivo e infastidirà gli utenti. D'altra parte, sembra più probabile che qualcuno abbia ricevuto la notifica. - Tracciamento di immagini nascoste.
Non tutti i provider di posta elettronica caricano automaticamente l'immagine e in che modo associamo l'immagine / le immagini con l'ID di tracciamento della posta elettronica? - Consegna in outsourcing.
Questo ci porta fuori dal business delle e-mail, ma ritorna su come garantire lo scontrino dell'out-sourcer e la successiva consegna al destinatario finale.
Come preoccupazione correlata, ci sarà una relazione n: n tra la notifica del problema e i destinatari.
Il problema 1: il sottoinsieme di destinatari n non è tanto un problema, anche se avessimo un errore di consegna, vorremmo investigare e risolvere il problema principale.
Di maggiore preoccupazione sono i problemi: 1 destinatario, e siamo specificamente interessati a fare in modo che tutti i n problemi siano stati ricevuti dal destinatario. In che modo il software del forum o il software di gestione dei problemi gestiscono questo requisito? Se viene utilizzato un identificatore di tracciamento, dove viene inserito nell'e-mail? Nel soggetto o nel corpo?