Italiano
Español
РусскийTrimiterea email-urilor multipart (text/html) prin wp_mail() vă poate duce la blocarea domeniului
Sumar
Din cauza unui bug din WordPress Core, trimiterea email-urilor multipart (html/text) cu wp_mail() (pentru a reduce șansa ca email-urile să ajungă în folderele spam) va duce ironic la blocarea domeniului tău de către Hotmail (și alte email-uri Microsoft).
Aceasta este o problemă complexă pe care voi încerca să o detaliez pentru a ajuta pe cineva să găsească o soluție funcțională care ar putea fi implementată în core.
Va fi o lectură utilă. Să începem...
Bug-ul
Cel mai comun sfat pentru a evita ca newsletter-urile să ajungă în folderele spam este să trimiți mesaje multipart.
Multi-part (mime) se referă la trimiterea atât a părții HTML cât și TEXT într-un singur email. Când un client primește un mesaj multipart, acceptă versiunea HTML dacă poate reda HTML, altfel prezintă versiunea text.
S-a dovedit că funcționează. Când trimiteam către gmail, toate email-urile noastre ajungeau în spam până când am schimbat mesajele în multipart și au ajuns în inbox-ul principal. Minunat.
Acum, când trimiți mesaje multipart prin wp_mail(), acesta afișează Content Type (multipart/*) de două ori, o dată cu boundary (dacă este setat custom) și o dată fără. Acest comportament face ca email-ul să fie afișat ca mesaj brut și nu multipart pe unele clienturi de email, inclusiv pe toate cele Microsoft (Hotmail, Outlook, etc...)
Microsoft va marca acest mesaj ca spam, iar puținele mesaje care ajung vor fi marcate manual de către destinatar. Din păcate, adresele de email Microsoft sunt foarte utilizate. 40% din abonații noștri le folosesc.
Acest lucru este confirmat de Microsoft printr-un schimb de email-uri recent.
Marcarea mesajelor va duce la blocarea completă a domeniului. Asta înseamnă că mesajele nu vor fi trimise în folderul spam, nu vor fi livrate deloc destinatarului.
Am avut domeniul nostru principal blocat de 3 ori până acum.
Pentru că acesta este un bug în WordPress core, fiecare domeniu care trimite mesaje multipart este blocat. Problema este că majoritatea administratorilor web nu știu de ce. Am confirmat acest lucru când am făcut cercetări și am văzut alți utilizatori discutând despre asta pe forumuri etc. Este nevoie să intri în codul sursă și să ai cunoștințe bune despre cum funcționează acest tip de mesaje email, despre care vom discuta în continuare...
Să analizăm codul
Creează un cont hotmail/outlook. Apoi, rulează următorul cod:
// Setează $to la un email hotmail.com sau outlook.com
$to = "YourEmail@hotmail.com";
$subject = 'wp_mail testare multipart';
$message = '------=_Part_18243133_1346573420.1408991447668
Content-Type: text/plain; charset=UTF-8
Salut lume! Acesta este text simplu...
------=_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>Salut Lume! Acesta este 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"';
// trimite email
wp_mail( $to, $subject, $message, $headers );
Și dacă vrei să schimbi tipul de conținut implicit, folosește:
add_filter( 'wp_mail_content_type', 'set_content_type' );
function set_content_type( $content_type ) {
return 'multipart/alternative';
}
Acest lucru va trimite un mesaj multipart.
Deci dacă verifici sursa completă a mesajului, vei observa că tipul de conținut este adăugat de două ori, o dată fără boundary:
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="====f230673f9d7c359a81ffebccb88e5d61=="
MIME-Version: 1.0
Content-Type: multipart/alternative; charset=
Aceasta este problema.
Sursa problemei se află în pluggable.php - dacă ne uităm pe undeva pe aici:
// Setează Content-Type și charset
// Dacă nu avem un content-type din header-ele de intrare
if ( !isset( $content_type ) )
$content_type = 'text/plain';
/**
* Filtrează tipul de conținut wp_mail().
*
* @since 2.3.0
*
* @param string $content_type Tipul de conținut implicit wp_mail().
*/
$content_type = apply_filters( 'wp_mail_content_type', $content_type );
$phpmailer->ContentType = $content_type;
// Setează dacă este text simplu, în funcție de $content_type
if ( 'text/html' == $content_type )
$phpmailer->IsHTML( true );
// Dacă nu avem un charset din header-ele de intrare
if ( !isset( $charset ) )
$charset = get_bloginfo( 'charset' );
// Setează tipul de conținut și charset
/**
* Filtrează charset-ul implicit wp_mail().
*
* @since 2.3.0
*
* @param string $charset Charset-ul implicit pentru email.
*/
$phpmailer->CharSet = apply_filters( 'wp_mail_charset', $charset );
// Setează header-e personalizate
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;
}
}
}
Soluții potențiale
Așadar te întrebi, de ce nu ai raportat asta pe trac? Am făcut-o deja. Spre marea mea surpriză, un ticket diferit a fost creat în urmă cu 5 ani descriind aceeași problemă.
Să fim sinceri, au trecut cinci ani și jumătate. În ani de internet, asta înseamnă mai degrabă 30. Problema a fost în mod clar abandonată și practic nu va fi niciodată rezolvată (...dacă nu o rezolvăm aici).
Am găsit un thread excelent aici care oferă o soluție, dar deși soluția lui funcționează, strică email-urile care nu au setat custom $headers.
Aici ne împotmolim de fiecare dată. Fie versiunea multipart funcționează bine și mesajele normale cu $headers nesetate nu, fie invers.
Soluția la care am ajuns a fost:
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;
// Setează dacă este text simplu, în funcție de $content_type
if ( 'text/html' == $content_type )
$phpmailer->IsHTML( true );
// Dacă nu avem un charset din header-ele de intrare
if ( !isset( $charset ) )
$charset = get_bloginfo( 'charset' );
}
// Setează tipul de conținut și charset
/**
* Filtrează charset-ul implicit wp_mail().
*
* @since 2.3.0
*
* @param string $charset Charset-ul implicit pentru email.
*/
$phpmailer->CharSet = apply_filters( 'wp_mail_charset', $charset );
// Setează header-e personalizate
if ( !empty( $headers ) ) {
foreach( (array) $headers as $name => $content ) {
$phpmailer->AddCustomHeader( sprintf( '%1$s: %2$s', $name, $content ) );
}
}
Da, știu, editarea fișierelor core este tabu, stați jos... aceasta a fost o rezolvare disperată și o încercare slabă de a oferi o soluție pentru core.
Problema cu soluția noastră este că email-urile implicite precum înregistrări noi, comentarii, resetare parolă etc vor fi livrate ca mesaje goale. Deci avem un script wp_mail() funcțional care va trimite mesaje multipart dar nimic altceva.
Ce este de făcut
Scopul aici este să găsim o modalitate de a trimite atât mesaje normale (text simplu) cât și multipart folosind funcția core wp_mail() (nu o funcție sendmail personalizată).
Când încerci să rezolvi asta, principala problemă cu care te vei confrunta este cantitatea de timp pe care o vei petrece trimițând mesaje de test, verificând dacă sunt primite și practic deschizând o cutie de aspirină și înjurând Microsoft pentru că ești obișnuit cu problemele lor IE în timp ce gremlina aici este din păcate WordPress.
Actualizare
Soluția postată de @bonger permite ca $message să fie un array conținând alternative cu chei de tip conținut. Am confirmat că funcționează în toate scenariile.
Vom permite acestei întrebări să rămână deschisă până când expiră recompensa pentru a crește gradul de conștientizare despre problemă, poate până la un nivel unde va fi rezolvată în core. Simțiți-vă liberi să postați o soluție alternativă unde $message poate fi un string.
Am adăugat acest lucru la pluginurile esențiale și am rulat codul de test; a funcționat. Am testat notificările implicite din nucleu (notificare pentru utilizator nou etc.) și a funcționat și acolo. Voi continua să efectuez teste în acest weekend și voi vedea cum vor funcționa pluginurile cu aceasta și practic dacă totul funcționează. Voi analiza în mod specific datele brute ale mesajului. Aceasta va fi o sarcină care va dura mult timp, dar fiți siguri că voi raporta înapoi când voi termina. Dacă există un scenariu în care wp_mail() nu va funcționa (atunci când ar trebui să funcționeze), vă rog să mă anunțați. Mulțumesc pentru acest răspuns.
Christine Cooper
Lucruri bune, am verificat rezultatul și arată bine - de fapt, patch-ul face ca wp_mail să folosească procesarea standard robustă a PHPMailer în cazul în care se transmite un array, iar în rest revine la metodele mai puțin sigure ale WP (pentru compatibilitate inversă), deci ar trebui să fie ok (evident, meritul aici revine autorilor patch-ului)... De acum înainte voi folosi acest patch (și îl voi implementa retroactiv eventual) - și mulțumesc și eu pentru informația despre folosirea atât a html cât și a plain text pentru a reduce șansele de a fi marcat ca spam...
bonger
Am testat în toate scenariile posibile și funcționează excelent. Vom trimite un newsletter mâine și vom vedea dacă primim plângeri de la utilizatori. Singurele modificări minore pe care a trebuit să le facem au fost să sanificăm/desanificăm array-ul atunci când este introdus în baza de date (avem mesaje într-o coadă în baza de date unde un cron le trimite în loturi mici). Voi lăsa această întrebare deschisă și în așteptare până când bounty-ul expiră, astfel încât să putem crește conștientizarea asupra acestei probleme. Sperăm că acest patch, sau o alternativă, va fi adăugat în nucleu. Sau mai important, de ce nu. La ce se gândesc!
Christine Cooper
Am observat întâmplător că ai efectuat o actualizare la ticketul Trac menționat. Este aceasta o actualizare a acestui cod? Dacă da, ai putea să postezi această actualizare prin editarea răspunsului tău aici, astfel încât acest răspuns să rămână la zi? Mulțumesc mult.
Christine Cooper
Salut, nu, a fost doar o reîmprospătare a patch-ului față de versiunea curentă a trunk, astfel încât să se poată integra fără conflicte (în speranța că va primi ceva atenție), codul este exact același...
bonger
Nu pot să-ți mulțumesc suficient pentru această soluție, a funcționat imediat, chiar din prima. Dacă aș fi în locul tău, aș păstra doar 'fragmentul simplu de răspuns' singur la sfârșitul postării tale. :)
scooterlord
@scooterlord Cu plăcere, a fost cu siguranță un pic de muncă să rezolv asta! Am adăugat un rezumat al soluției la începutul răspunsului pentru cei care doresc doar remedierea.
majick
Nu e minunat când doar copiezi/lipești fragmente de cod și funcționează din prima? :)
scooterlord
wp_strip_all_tags ar putea fi mai bun decât strip_tags. Ultima va afișa conținutul tag-urilor <style>, care sunt comune în e-mailurile HTML.
James Beninger
@JamesBeninger ah, observație bună! Am editat răspunsul pentru a schimba la aceasta.
majick
Salut Paul. Sintaxa scurtă pentru array-uri a apărut cu mult înainte de PHP 7+ ;)
kaiser