Italiano
Română
РусскийEl envío de correos multipart (text/html) vía wp_mail() probablemente hará que tu dominio sea bloqueado
Resumen
Debido a un error en el núcleo de WP, enviar correos multipart (html/text) con wp_mail() (para reducir la probabilidad de que los correos terminen en carpetas de spam) irónicamente resultará en que tu dominio sea bloqueado por Hotmail (y otros correos de Microsoft).
Este es un problema complejo que intentaré desglosar en gran detalle para ayudar a encontrar una solución viable que eventualmente pueda implementarse en el núcleo.
Será una lectura gratificante. Empecemos...
El error
El consejo más común para evitar que tus correos de newsletter terminen en carpetas de spam es enviar mensajes multipart.
Multi-part (mime) se refiere a enviar tanto una parte HTML como TEXT de un mensaje de correo en un solo email. Cuando un cliente recibe un mensaje multipart, acepta la versión HTML si puede renderizar HTML, de lo contrario presenta la versión en texto plano.
Está comprobado que funciona. Al enviar a Gmail, todos nuestros correos iban a carpetas de spam hasta que cambiamos los mensajes a multipart cuando llegaron a la bandeja principal. Excelente.
Ahora, cuando se envían mensajes multipart a través de wp_mail(), genera el Content Type (multipart/*) dos veces, una con boundary (si se establece personalmente) y otra sin él. Este comportamiento hace que el correo se muestre como un mensaje sin formato y no multipart en algunos clientes de correo, incluyendo todos los de Microsoft (Hotmail, Outlook, etc...)
Microsoft marcará este mensaje como basura, y los pocos mensajes que llegan serán marcados manualmente por el destinatario. Desafortunadamente, las direcciones de correo de Microsoft son ampliamente utilizadas. El 40% de nuestros suscriptores las usan.
Esto fue confirmado por Microsoft a través de un intercambio de correos que tuvimos recientemente.
El marcado de los mensajes resultará en que el dominio sea completamente bloqueado. Esto significa que los mensajes no serán enviados a la carpeta de spam, ni siquiera serán entregados al destinatario.
Hemos tenido nuestro dominio principal bloqueado 3 veces hasta ahora.
Debido a que este es un error en el núcleo de WP, todos los dominios que envían mensajes multipart están siendo bloqueados. El problema es que la mayoría de los webmasters no saben por qué. He confirmado esto al hacer mi investigación y ver a otros usuarios discutiendo esto en foros, etc. Requiere profundizar en el código crudo y tener un buen conocimiento de cómo funcionan este tipo de mensajes de correo, lo cual veremos a continuación...
Vamos a desglosarlo en código
Crea una cuenta de hotmail/outlook. Luego, ejecuta el siguiente código:
// Establece $to a un correo hotmail.com u outlook.com
$to = "TuCorreo@hotmail.com";
$subject = 'Prueba wp_mail multipart';
$message = '------=_Part_18243133_1346573420.1408991447668
Content-Type: text/plain; charset=UTF-8
¡Hola mundo! Esto es texto plano...
------=_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>¡Hola Mundo! Esto es 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"';
// enviar email
wp_mail( $to, $subject, $message, $headers );
Y si quieres cambiar el tipo de contenido predeterminado, usa:
add_filter( 'wp_mail_content_type', 'set_content_type' );
function set_content_type( $content_type ) {
return 'multipart/alternative';
}
Esto enviará un mensaje multipart.
Si verificas el código fuente completo del mensaje, notarás que el tipo de contenido se agrega dos veces, una vez sin boundary:
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="====f230673f9d7c359a81ffebccb88e5d61=="
MIME-Version: 1.0
Content-Type: multipart/alternative; charset=
Ese es el problema.
El origen del problema está en pluggable.php - si miramos por aquí:
// Establecer Content-Type y charset
// Si no tenemos un content-type de los headers de entrada
if ( !isset( $content_type ) )
$content_type = 'text/plain';
/**
* Filtrar el content type de wp_mail().
*
* @since 2.3.0
*
* @param string $content_type Content type predeterminado de wp_mail().
*/
$content_type = apply_filters( 'wp_mail_content_type', $content_type );
$phpmailer->ContentType = $content_type;
// Establecer si es texto plano, dependiendo de $content_type
if ( 'text/html' == $content_type )
$phpmailer->IsHTML( true );
// Si no tenemos un charset de los headers de entrada
if ( !isset( $charset ) )
$charset = get_bloginfo( 'charset' );
// Establecer el content-type y charset
/**
* Filtrar el charset predeterminado de wp_mail().
*
* @since 2.3.0
*
* @param string $charset Charset predeterminado del email.
*/
$phpmailer->CharSet = apply_filters( 'wp_mail_charset', $charset );
// Establecer headers personalizados
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;
}
}
}
Soluciones potenciales
Así que te preguntarás, ¿por qué no has reportado esto en trac? Ya lo he hecho. Para mi gran sorpresa, se creó un ticket diferente hace 5 años describiendo el mismo problema.
Seamos realistas, han pasado cinco años. En años de internet, eso es más como 30. El problema claramente ha sido abandonado y básicamente nunca será arreglado (...a menos que lo resolvamos aquí).
Encontré un excelente hilo aquí ofreciendo una solución, pero aunque su solución funciona, rompe los correos que no tienen $headers personalizados establecidos.
Ahí es donde nos estrellamos cada vez. O la versión multipart funciona bien y los mensajes normales sin $headers establecidos no, o viceversa.
La solución que desarrollamos fue:
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;
// Establecer si es texto plano, dependiendo de $content_type
if ( 'text/html' == $content_type )
$phpmailer->IsHTML( true );
// Si no tenemos un charset de los headers de entrada
if ( !isset( $charset ) )
$charset = get_bloginfo( 'charset' );
}
// Establecer el content-type y charset
/**
* Filtrar el charset predeterminado de wp_mail().
*
* @since 2.3.0
*
* @param string $charset Charset predeterminado del email.
*/
$phpmailer->CharSet = apply_filters( 'wp_mail_charset', $charset );
// Establecer headers personalizados
if ( !empty( $headers ) ) {
foreach( (array) $headers as $name => $content ) {
$phpmailer->AddCustomHeader( sprintf( '%1$s: %2$s', $name, $content ) );
}
}
Sí, lo sé, editar archivos del núcleo es tabú, siéntate... esta fue una solución desesperada y un pobre intento de proporcionar una corrección para el núcleo.
El problema con nuestra solución es que los correos predeterminados como nuevos registros, comentarios, restablecimiento de contraseña, etc. se entregarán como mensajes en blanco. Así que tenemos un script wp_mail() funcional que enviará mensajes multipart pero nada más.
Qué hacer
El objetivo aquí es encontrar una manera de enviar tanto mensajes normales (texto plano) como multipart usando la función wp_mail() del núcleo (no una función sendmail personalizada).
Al intentar resolver esto, el principal problema que encontrarás es la cantidad de tiempo que pasarás enviando mensajes de prueba, verificando si se reciben y básicamente abriendo una caja de aspirinas y maldiciendo a Microsoft porque estás acostumbrado a sus problemas con IE mientras que el gremlim aquí es desafortunadamente WordPress.
Actualización
La solución publicada por @bonger permite que $message sea un array que contiene alternativas con claves de tipo de contenido. He confirmado que funciona en todos los escenarios.
Permitiremos que esta pregunta permanezca abierta hasta que se agote la recompensa para crear conciencia sobre el problema, tal vez a un nivel donde se arreglará en el núcleo. Siéntete libre de publicar una solución alternativa donde $message pueda ser una cadena.
He añadido esto a los plugins imprescindibles y ejecuté el código de prueba; funcionó. He probado las notificaciones predeterminadas del núcleo (notificación de nuevo usuario, etc.) y también funcionó. Continuaré realizando pruebas este fin de semana y veré cómo funcionarán los plugins con esto y básicamente si todo funciona. Revisaré específicamente los datos brutos del mensaje. Será una tarea que consumirá mucho tiempo, pero descuiden, informaré cuando termine. Si hay un escenario donde wp_mail() no funcione (cuando debería hacerlo), por favor hágamelo saber. Gracias por esta respuesta.
Christine Cooper
Buen material, he revisado visualmente la salida y se ve bien - de hecho, el parche simplemente hace que wp_mail use el procesamiento estándar sólido como una roca de PHPMailer en el caso de pasar un array, y de lo contrario recurre a las cosas dudosas de WP (para compatibilidad hacia atrás) así que debería estar bien (obviamente el crédito aquí es para los autores del parche)... Voy a empezar a usarlo desde ahora (y a adaptarlo eventualmente) - y gracias de vuelta por la información sobre usar tanto html como texto plano para reducir las posibilidades de ser marcado como spam...
bonger
Lo hemos probado en todos los escenarios posibles y funciona genial. Enviaremos un boletín mañana y veremos si recibimos quejas de los usuarios. Los únicos cambios menores que tuvimos que hacer fueron sanear/desanear el array cuando se inserta en la base de datos (tenemos mensajes en una cola en la base de datos donde un cron los envía en pequeños lotes). Dejaré esta pregunta abierta y pendiente hasta que se acabe la recompensa para poder dar visibilidad a este problema. Con suerte, este parche, o una alternativa, se añadirá al núcleo. O más importante, ¿por qué no? ¡En qué están pensando!
Christine Cooper
Noté aleatoriamente que realizaste una actualización en el ticket de trac enlazado. ¿Es esta una actualización de este código? Si es así, ¿podrías amablemente publicar esta actualización editando tu respuesta aquí también para que esta respuesta se mantenga actualizada? Muchas gracias.
Christine Cooper
Hola, no, solo fue una actualización del parche contra la versión actual del trunk para que se fusione sin conflictos (con la esperanza de que reciba algo de atención), el código es exactamente el mismo...
bonger
No tengo palabras para agradecerte esta solución, funcionó inmediatamente, sin necesidad de ajustes. Si fuera tú, dejaría solo el 'fragmento de respuesta simple' al final de tu publicación. :)
scooterlord
@scooterlord De nada, ¡definitivamente requirió un poco de esfuerzo resolver esto! He añadido un resumen de la solución al principio de la respuesta para quienes solo quieren la solución rápida.
majick
¿No es genial cuando puedes copiar/pegar fragmentos de código y simplemente funcionan? :)
scooterlord
wp_strip_all_tags podría ser mejor que strip_tags. Este último renderizará el contenido de las etiquetas <style>, que son comunes en los correos HTML.
James Beninger
@JamesBeninger ah, ¡buen apunte! He editado la respuesta para cambiarlo.
majick
Hola Paul. La sintaxis corta de arrays llegó mucho antes de PHP 7+ ;)
kaiser