Español
Română
РусскийL'invio di email multipart (text/html) tramite wp_mail() potrebbe causare il ban del tuo dominio
Riepilogo
A causa di un bug nel Core di WordPress, l'invio di email multipart (html/text) con wp_mail() (per ridurre la possibilità che le email finiscano nelle cartelle spam) ironicamente farà sì che il tuo dominio venga bloccato da Hotmail (e altre email Microsoft).
Questo è un problema complesso che cercherò di analizzare in dettaglio nel tentativo di aiutare qualcuno a trovare una soluzione funzionante che potrebbe eventualmente essere implementata nel core.
Sarà una lettura gratificante. Iniziamo...
Il bug
Il consiglio più comune per evitare che le email della newsletter finiscano nelle cartelle spam è quello di inviare messaggi multipart.
Multi-part (mime) si riferisce all'invio sia della parte HTML che di quella TESTO di un messaggio email in una singola email. Quando un client riceve un messaggio multipart, accetta la versione HTML se può renderizzare l'HTML, altrimenti presenta la versione in testo semplice.
Questo è dimostrato che funziona. Quando inviavamo a Gmail, tutte le nostre email finivano nelle cartelle spam finché non abbiamo cambiato i messaggi in multipart, quando sono arrivati nella casella principale. Ottimo risultato.
Ora, quando si inviano messaggi multipart tramite wp_mail(), viene emesso il Content Type (multipart/*) due volte, una volta con boundary (se impostato manualmente) e una volta senza. Questo comportamento fa sì che l'email venga visualizzata come messaggio raw e non multipart su alcune email, incluse tutte quelle Microsoft (Hotmail, Outlook, ecc...)
Microsoft contrassegnerà questo messaggio come spam, e i pochi messaggi che passano verranno segnalati manualmente dal destinatario. Sfortunatamente, gli indirizzi email Microsoft sono ampiamente utilizzati. Il 40% dei nostri iscritti li utilizza.
Questo è stato confermato da Microsoft tramite uno scambio di email che abbiamo avuto recentemente.
La segnalazione dei messaggi porterà al blocco completo del dominio. Ciò significa che i messaggi non verranno inviati alla cartella spam, non verranno proprio consegnati al destinatario.
Il nostro dominio principale è stato bloccato già 3 volte finora.
Poiché questo è un bug nel core di WordPress, ogni dominio che invia messaggi multipart viene bloccato. Il problema è che la maggior parte dei webmaster non sa perché. L'ho confermato durante la mia ricerca vedendo altri utenti discuterne nei forum ecc. Richiede di addentrarsi nel codice raw e avere una buona conoscenza di come funzionano questi tipi di messaggi email, che andremo ad analizzare ora...
Analizziamo il codice
Crea un account hotmail/outlook. Quindi, esegui il seguente codice:
// Imposta $to con un'email hotmail.com o outlook.com
$to = "TuaEmail@hotmail.com";
$subject = 'test wp_mail multipart';
$message = '------=_Part_18243133_1346573420.1408991447668
Content-Type: text/plain; charset=UTF-8
Ciao mondo! Questo è testo semplice...
------=_Part_18243133_1346573420.1408991447668
Content-Type: text/html; charset=UTF-8
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<p>Ciao Mondo! Questo è HTML...</p>
</body>
</html>
------=_Part_18243133_1346573420.1408991447668--';
$headers = "MIME-Version: 1.0\r\n";
$headers .= "From: Foo <foo@bar.com>\r\n";
$headers .= 'Content-Type: multipart/alternative;boundary="----=_Part_18243133_1346573420.1408991447668"';
// invia email
wp_mail( $to, $subject, $message, $headers );
E se vuoi cambiare il content type predefinito, usa:
add_filter( 'wp_mail_content_type', 'set_content_type' );
function set_content_type( $content_type ) {
return 'multipart/alternative';
}
Questo invierà un messaggio multipart.
Quindi se controlli il codice sorgente completo del messaggio, noterai che il content type viene aggiunto due volte, una volta senza boundary:
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="====f230673f9d7c359a81ffebccb88e5d61=="
MIME-Version: 1.0
Content-Type: multipart/alternative; charset=
Questo è il problema.
L'origine del problema si trova in pluggable.php - se guardiamo da qualche parte qui:
// Imposta Content-Type e charset
// Se non abbiamo un content-type dagli header di input
if ( !isset( $content_type ) )
$content_type = 'text/plain';
/**
* Filtra il content type di wp_mail().
*
* @since 2.3.0
*
* @param string $content_type Content type predefinito di wp_mail().
*/
$content_type = apply_filters( 'wp_mail_content_type', $content_type );
$phpmailer->ContentType = $content_type;
// Imposta se è testo semplice, in base a $content_type
if ( 'text/html' == $content_type )
$phpmailer->IsHTML( true );
// Se non abbiamo un charset dagli header di input
if ( !isset( $charset ) )
$charset = get_bloginfo( 'charset' );
// Imposta il content-type e charset
/**
* Filtra il charset predefinito di wp_mail().
*
* @since 2.3.0
*
* @param string $charset Charset email predefinito.
*/
$phpmailer->CharSet = apply_filters( 'wp_mail_charset', $charset );
// Imposta gli header personalizzati
if ( !empty( $headers ) ) {
foreach( (array) $headers as $name => $content ) {
$phpmailer->AddCustomHeader( sprintf( '%1$s: %2$s', $name, $content ) );
}
if ( false !== stripos( $content_type, 'multipart' ) && ! empty($boundary) )
$phpmailer->AddCustomHeader( sprintf( "Content-Type: %s;\n\t boundary=\"%s\"", $content_type, $boundary ) );
}
if ( !empty( $attachments ) ) {
foreach ( $attachments as $attachment ) {
try {
$phpmailer->AddAttachment($attachment);
} catch ( phpmailerException $e ) {
continue;
}
}
}
Potenziali soluzioni
Ti starai chiedendo, perché non hai segnalato questo su trac? L'ho già fatto. Con mia grande sorpresa, un ticket diverso era stato creato 5 anni fa che descriveva lo stesso problema.
Ammettiamolo, sono passati cinque anni. In anni internet, è più come 30. Il problema è stato chiaramente abbandonato e praticamente non verrà mai risolto (...a meno che non lo risolviamo qui).
Ho trovato un ottimo thread qui che offre una soluzione, ma mentre la sua soluzione funziona, rompe le email che non hanno $headers personalizzati impostati.
È qui che ci blocchiamo ogni volta. O la versione multipart funziona bene e i messaggi normali senza $headers impostati no, o viceversa.
La soluzione che abbiamo trovato è stata:
if ( false !== stripos( $content_type, 'multipart' ) && ! empty($boundary) ) {
$phpmailer->ContentType = $content_type . "; boundary=" . $boundary;
}
else {
$content_type = apply_filters( 'wp_mail_content_type', $content_type );
$phpmailer->ContentType = $content_type;
// Imposta se è plaintext, in base a $content_type
if ( 'text/html' == $content_type )
$phpmailer->IsHTML( true );
// Se non abbiamo un charset dagli header di input
if ( !isset( $charset ) )
$charset = get_bloginfo( 'charset' );
}
// Imposta il content-type e charset
/**
* Filtra il charset predefinito di wp_mail().
*
* @since 2.3.0
*
* @param string $charset Charset email predefinito.
*/
$phpmailer->CharSet = apply_filters( 'wp_mail_charset', $charset );
// Imposta gli header personalizzati
if ( !empty( $headers ) ) {
foreach( (array) $headers as $name => $content ) {
$phpmailer->AddCustomHeader( sprintf( '%1$s: %2$s', $name, $content ) );
}
}
Sì, lo so, modificare i file core è tabù, siediti... questa era una correzione disperata e un tentativo poco efficace di fornire una correzione per il core.
Il problema con la nostra correzione è che le email predefinite come nuove registrazioni, commenti, reset password ecc. verranno consegnate come messaggi vuoti. Quindi abbiamo uno script wp_mail() funzionante che invierà messaggi multipart ma nient'altro.
Cosa fare
L'obiettivo qui è trovare un modo per inviare sia messaggi normali (testo semplice) che multipart usando la funzione wp_mail() del core (non una funzione sendmail personalizzata).
Quando si tenta di risolvere questo problema, il problema principale che incontrerai è la quantità di tempo che passerai a inviare messaggi di prova, controllare se vengono ricevuti e praticamente aprire una scatola di aspirina e maledire Microsoft perché sei abituato ai loro problemi con IE mentre il gremlin qui è sfortunatamente WordPress.
Aggiornamento
La soluzione pubblicata da @bonger permette a $message di essere un array contenente alternative con chiave content-type. Ho confermato che funziona in tutti gli scenari.
Permetteremo a questa domanda di rimanere aperta fino alla scadenza della taglia per sensibilizzare sul problema, forse a un livello tale da essere corretto nel core. Sentiti libero di pubblicare una soluzione alternativa dove $message può essere una stringa.
Ho aggiunto questo ai plugin indispensabili e ho eseguito il codice di test; ha funzionato. Ho testato le notifiche predefinite del core (come la notifica per nuovo utente, ecc.) e ha funzionato anche quello. Continuerò a fare test questo fine settimana per vedere come i plugin funzioneranno con questo e fondamentalmente se tutto funziona. Controllerò specificamente i dati grezzi del messaggio. Sarà un compito molto dispendioso in termini di tempo, ma state certi che vi farò sapere quando avrò finito. Se c'è uno scenario in cui wp_mail() non funzionerà (quando invece dovrebbe), per favore fatemelo sapere. Grazie per questa risposta.
Christine Cooper
Ottime cose, ho dato un'occhiata all'output e sembra buono - in effetti la patch fa semplicemente sì che wp_mail utilizzi l'elaborazione standard solida di PHPMailer nel caso in cui venga passato un array, mentre in caso contrario torna al materiale approssimativo di WP (per compatibilità all'indietro), quindi dovrebbe andare bene (ovviamente il merito qui va agli autori della patch)... Da ora in poi lo userò (e alla fine lo retrofitterò) - e grazie anche a te per le informazioni sull'uso sia di html che di plain per ridurre le possibilità di essere marchiati come spam...
bonger
L'abbiamo testato in tutti gli scenari possibili e funziona alla grande. Manderemo una newsletter domani e vedremo se riceviamo lamentele dagli utenti. Le uniche piccole modifiche che abbiamo dovuto fare sono state sanificare/desanificare l'array quando viene inserito nel db (abbiamo i messaggi in una coda nel db dove un cron li invia in piccoli lotti). Lascerò questa domanda aperta e in attesa fino a quando il bounty scadrà, in modo da poter portare consapevolezza su questo problema. Speriamo che questa patch, o un'alternativa, venga aggiunta al core. O, ancora più importante, perché no. Cosa stanno pensando!
Christine Cooper
Ho notato casualmente che hai eseguito un aggiornamento al ticket trac collegato. Si tratta di un aggiornamento a questo codice? Se è così, potresti cortesemente pubblicare questo aggiornamento modificando anche la tua risposta qui in modo che questa risposta rimanga aggiornata? Grazie mille.
Christine Cooper
Ciao, no è stato solo un refresh della patch rispetto all'attuale trunk in modo che si fonda senza conflitti (nella speranza che riceva un po' di attenzione), il codice è esattamente lo stesso...
bonger
Non posso ringraziarti abbastanza per questa soluzione, ha funzionato immediatamente, subito pronta all'uso. Se fossi in te terrei solo lo 'snippet della risposta semplice' da solo alla fine del tuo post. :)
scooterlord
@scooterlord Prego, è stato sicuramente un po' complicato risolvere questo problema! Ho aggiunto una soluzione riassuntiva all'inizio della risposta per chi vuole solo la correzione.
majick
Non è fantastico quando puoi semplicemente copiare/incollare snippet e funzionano subito senza problemi? :)
scooterlord
wp_strip_all_tags potrebbe essere migliore di strip_tags. Quest'ultimo renderà il contenuto dei tag <style>, che sono comuni nelle email HTML.
James Beninger
@JamesBeninger ah, ottima osservazione! Ho modificato la risposta per cambiare con questa.
majick
Ciao Paul. La sintassi abbreviata degli array esiste già da molto prima di PHP 7+ ;)
kaiser