Messaggi di posta elettronica a volte ottenere strapazzate

Question

Folks,

Ho un sito basato su PHP (utilizzando il QCubed framework); come parte del sito, ho un demone che sta inviando diverse migliaia di email al giorno (no non sono uno spammer, tutto è opt-in :)). Le email vengono inviate tramite un componente framework personalizzato; quel componente funge da client SMTP. Sto utilizzando un gateway SMTP a pagamento da DNSExit.com per ricevere effettivamente le email.

Queste e-mail sono semplici e-mail basate su HTML; hanno davvero dei semplici collegamenti all'interno.

Il mio problema è che a volte questi collegamenti (non costantemente!) Vengono codificati durante la transizione. I tag vengono in qualche modo confusi e alcuni link non sono funzionanti nell'e-mail. Il problema si verifica su una piccola percentuale di tutte le e-mail inviate; non è coerente (vale a dire lo stesso esatto messaggio sorgente HTML può o non può causare lo scrambling in transizione).

Qualcuno di voi ha visto questo? Qualche idea su come risolvere?

Answer 1

Aveva 2 problemi con i dati di posta elettronica - di solito "?" il simbolo in qualche modo è entrato dentro alcune parole, un altro era UTF e il titolo correlato. Prima è stato "riparato" cambiando il provider di hosting (quindi era legato al server di posta) il secondo è stato risolto cambiando la libreria di PHPmailer.

Provare a specificare in che modo esattamente i dati vengono codificati.

Answer 2

È possibile che si stiano utilizzando i file temporanei per creare le e-mail (o almeno per creare il contenuto della variabile)? Ho fatto qualcosa di vagamente simile una volta. Il testo dell'email è stato generato e scritto in un file temporaneo in base al tempo esatto in secondi. Sfortunatamente, quando invii migliaia al giorno, stavamo colpendo lo stesso secondo più di una volta (dal momento che sono disponibili solo 86k secondi). Ciò potrebbe spiegare a) il piccolo tasso di errore eb) l'apparente casualità. Per la risoluzione dei problemi, vorrei solo vedere se l'errore tasso aumenta con il numero di e-mail e andare da lì.

Answer 3

Hai qualche attributo speciale nei tuoi link? Può essere attributo titolo con citazioni non sfuggite all'interno?

Qualcosa di simile a questo: <a href="http://some.site" title="My "correct" link">Link</a>

Answer 4

mi sono imbattuto in un problema simile su un server che esegue sendmail.

Stavo creando e testando un'e-mail html che un giorno sarebbe stata inviata per posta di massa (opt-in, ovviamente). Avevo me stesso un modello per l'e-mail che era facile da leggere per qualsiasi programmatore html, ma come tale era pesante sugli spazi bianchi per allineare tutto correttamente. Ho pensato a me stesso, se questo verrà inviato via email di massa, dopo che il modello è stato renderizzato, penso che ridurrò al minimo lo spazio bianco nel file per risparmiare spazio! Così ho creato una brillante espressione regolare per eliminare ogni inutile invio di spazi bianchi dall'e-mail inviata.

Dopo aver inviato l'e-mail a me stesso, ho aperto l'e-mail ed ero sconcertato quando ho visto che alcuni dei css e html non venivano visualizzati correttamente, quando le mie e-mail precedenti prima del mio regexp erano. Osservando il messaggio originale ho notato che ogni tanto un punto esclamativo (!) Appariva in modo casuale in tutto il messaggio, rompendo ogni css e html che arrivava nel suo percorso casuale.

Si scopre che a sendmail non piace se una riga della posta elettronica diventa troppo lunga senza un'interruzione di riga. Quando la linea diventa troppo lunga, sendmail inserirà un punto esclamativo seguito da un'interruzione di riga proprio lì e lì, solo per confonderti e confonderti.

Perché non è stato solo scegliere uno spazio tra le parole e l'interruzione di riga? Perché inserire il punto esclamativo? Domande ho paura, senza risposte.

La mia soluzione?

sudo apt-get remove sendmail 
sudo apt-get install exim4 

ho avuto altri problemi con sendmail come se prendere un pieno 60 secondi per inviare una e-mail e exim4 appena finito di lavorare e non ho mai dovuto pensarci di nuovo.

Se il tuo server di posta sta usando sendmail, questo potrebbe essere il problema, se così non fosse, grazie per avermi permesso di condividere la mia storia con te. Avevo bisogno di sfogarmi.

Answer 5

Quando invii email, devi codificarlo in modo che ogni riga nel corpo del messaggio non sia più lunga di 76 caratteri. È possibile utilizzare base64 per questo, ma la maggior parte dei sistemi utilizza la codifica stampabile quotata per il testo in quanto genera messaggi più piccoli. Base64 viene in genere utilizzato solo per dati binari.

Answer 6

Il problema è che HTML non è compatibile con l'e-mail. Questo è il motivo per cui ho creato Mail Markup Language.

L'HTML è stato creato per funzionare con il protocollo HTTP poiché queste due tecnologie sono state inventate dalla stessa persona all'incirca nello stesso momento. La differenza è che HTTP è una singola sessione di trasferimento unidirezionale da un server a un client. Ciò non cambia mai quando il documento HTML viene sempre generato su un server, viene inviato a un client richiedente e, una volta completato il trasferimento, la connessione tra client e server viene interrotta.

L'e-mail non si comporta in questo modo. Nell'e-mail una comunicazione proviene da un cliente, viene inviata a una o più funzioni e-mail e termina in un client remoto. La più grande differenza, tuttavia, è che il documento non muore con finalità di una singola istanza di trasmissione, come nel caso di un trasferimento di documenti su HTTP. Un documento inviato in SMTP può essere risposto, inoltrato o copiato su più utenti non richiesti. Questa differenza è profonda quando viene presa in considerazione la considerazione per un thread di posta elettronica.

Il problema è che SMTP e HTTP sono diversi come dimostrato nei due paragrafi precedenti. Queste differenze sono aggravate dal fatto che SMTP e HTTP hanno metodi di formattazione radicalmente diversi per la creazione di dati di intestazione. L'HTML ha dati di intestazione che devono essere compatibili con le intestazioni delle trasmissioni HTTP e non offrono alcuna conformità alle trasmissioni SMTP. Anche le intestazioni HTML non tengono conto della complessità di un thread di posta elettronica.

Il problema è esemplificato quando il software di posta elettronica corrompe un documento HTML per aggiungere modifiche di formattazione necessarie per soddisfare le esigenze conformi di quel software e anche per scrivere i dati di intestazione direttamente nel documento. Questa esemplificazione diventa estremamente pronunciata quando un email HTML diventa un thread di posta elettronica. Poiché i dati dell'intestazione HTML non hanno alcun metodo per tenere conto delle complessità di un thread di posta elettronica, non è possibile fornire definizioni di presentazione pertinenti da un foglio di stile che sopravvive al trasferimento del documento. Ogni volta che un documento HTML o un documento con formattazione HTML viene inviato da un software di posta elettronica a un altro, il documento è corrotto e ogni dispositivo software di posta elettronica corrompe il danneggiamento precedente. Il software di elaborazione della posta elettronica può fare riferimento a un client di posta elettronica, che sicuramente corromperà un documento o un server di posta elettronica, che probabilmente corromperà probabilmente un documento di posta elettronica.

La soluzione al problema è creare una convenzione del linguaggio di markup che riconosca direttamente i requisiti dei dati dell'intestazione dell'email. Tali requisiti sono definiti in RFC 5321 per il protocollo SMTP e RFC 5322 per l'elaborazione client. L'unico modo per estendere correttamente questa soluzione per tenere conto delle complessità di un thread di posta elettronica consiste nel fornire una convenzione per un DOM multi-agente.

I paragrafi eliminati a causa di inesattezza tecnica e differenza tra il termine DOM multi-agente e la natura di una funzionalità inventata non menzionata qui anche prima della modifica.

MODIFICA: un DOM multi-agente applica un certo grado di gerarchia, che potrebbe non essere necessario per rappresentare un thread di posta elettronica.