⚓️ 🙆🏾 🦊 Cómo hacer correos electrónicos y no desordenar: consejos prácticos 🌷 👩🏼‍🚀 ♻️

Un desarrollador, que se encontró por primera vez generando correos electrónicos, casi no tiene oportunidad de escribir una aplicación, que lo hará correctamente. Alrededor del 40% de los correos electrónicos, generados por aplicaciones corporativas, están violando alguna forma de estándar, y debido a esto, hay problemas con la entrega y la visualización. Hay razones para esto: los correos electrónicos son técnicamente más difíciles que la web, y el funcionamiento de los correos electrónicos está regulado por unos cientos de estándares, así como por un número incontable de prácticas generalmente aceptadas (y no tanto), mientras que los clientes de correo electrónico son más variados e impredecible que los navegadores. Las pruebas pueden mejorar significativamente la situación, pero los materiales que se dedican a probar el sistema de correo electrónico son prácticamente inexistentes.

Mail.ru interactúa regularmente con sus usuarios por correo electrónico. En nuestros proyectos, todos los componentes responsables de generar correos electrónicos e incluso correos individuales están sujetos a pruebas obligatorias. En este artículo, compartiremos nuestra experiencia (aprender de nuestros errores).

¿Qué tipo de correos electrónicos hay?

La aplicación puede generar varios tipos de correos electrónicos. Se pueden clasificar en varias categorías. Por el método de selección de destinatarios - personal / activado - selectivo-grupal. Con cita previa: transacciones- comercialización- servicio. Puede establecer diferentes requisitos para diferentes tipos de correo electrónico y aplicar varios escenarios de prueba.

Los correos electrónicos personales activados se generan en respuesta a cualquier evento, por ejemplo, acciones del usuario o cambios de estado de los objetos del sistema. Son generados por la aplicación y, por lo tanto, son los más interesantes en lo que respecta a las pruebas. Los correos electrónicos activados pueden ser transaccionales, de marketing y para uso del servicio. Los correos electrónicos selectivos se envían a una selección dinámica de usuarios que cumplen algún tipo de criterio. Los correos electrónicos grupales se envían a un grupo permanente de destinatarios, por ejemplo, a todos los usuarios o socios. Los correos electrónicos selectivos y grupales son a menudo para fines de marketing, y el envío de dichos correos electrónicos se inicia manualmente o de manera programada.

Los correos electrónicos transaccionales se generan en el proceso de un usuario que completa alguna forma de acción. Dichos correos electrónicos incluyen, por ejemplo, facturas, tickets o notificaciones de estado de entrega. Los correos electrónicos transaccionales siempre se activan y están destinados a transportar información importante. Deben ser lo más simples y compatibles posible, y las pruebas deben realizarse en una gran cantidad de clientes de correo.

Los correos electrónicos de marketing alientan al usuario a tomar medidas, por ejemplo, esta puede ser una oferta de un descuento personal basado en compras anteriores. Los datos transaccionales se pueden utilizar en estos correos electrónicos, y se pueden activar correos electrónicos o de forma masiva, periódica o una sola vez. Para estos correos electrónicos, la eficiencia es más importante, y los resultados de la prueba dividida generalmente lo determinan. Algunos aspectos de compatibilidad pueden ser sacrificados por la eficiencia.

Los correos electrónicos de marketing grupales, por ejemplo, mensajes sobre ofertas de temporada, promociones y ventas, a menudo se envían 'manualmente' y no son parte de su aplicación, pero también puede (y debe) aplicarles principios de prueba generales.

Además, puede haber correos electrónicos de servicio: notificaciones generadas para el personal, para sistemas CRM automatizados, registro en diario, auditoría o DWH. Dichos correos electrónicos generalmente son correos electrónicos activados, lo que significa que también son parte de la aplicación y deben ser probados.

¿Quién participa en el proceso de prueba y control?

Ingeniero de control de calidad: participa en todas las etapas del proceso.
Ingeniero de redes: responsable de configurar la infraestructura de red y la infraestructura de entrega de mensajes. El ingeniero de redes debe participar en la planificación y las pruebas de infraestructura.
Especialista en entrega: persona que monitorea la capacidad de entrega de los correos electrónicos, que también participa en el monitoreo de los parámetros técnicos y administrativos de todos los correos electrónicos enviados, y monitorea el progreso del proceso de envío de correos. Es responsable de garantizar que los correos electrónicos enviados lleguen al mayor porcentaje de usuarios y no terminen en spam. Para este propósito, el especialista debe tener conocimiento y contactos específicos. Si hay algún problema con la entrega de correos electrónicos, él es quien debe comprender la causa probable y eliminarla; ya sea eliminando obstáculos técnicos; o cambiar algo en el contenido de los correos electrónicos; o intente resolver el problema con el servicio de soporte del proveedor de correo, al que no llegan los correos electrónicos. Dicho especialista (si lo hay) también debe participar en la elaboración de la lista de verificación y en la prueba de infraestructura que genera aplicaciones y correos electrónicos. Sin embargo, el proceso de prueba en sí mismo debe estar bajo el control del servicio de control de calidad.
Email-marketer: determina la efectividad de los boletines de marketing. Bajo su control, se realizan las pruebas divididas para la distribución de marketing a la audiencia. Email-marketer también controla la segmentación de la base de usuarios, la composición y la frecuencia de los correos electrónicos enviados, la 'presentación' visual del correo electrónico al usuario.

Todos estos roles no son necesariamente realizados por un empleado dedicado; El rol del vendedor puede ser realizado por uno de los gerentes de producto, y el rol del especialista en entrega, por ejemplo, puede ser realizado por un empleado de soporte o un ingeniero de redes. En las empresas de nueva creación, es muy probable que todo esto tenga que ser tratado por una sola persona, y pueden llegar a ser un especialista de calidad.

Correo y transporte de correo

La estructura del correo electrónico es como un iceberg masivo, y tiene dos niveles. Existen más de cien estándares diferentes que rigen los correos electrónicos, pero casi todos pertenecen a uno de estos dos niveles:

La parte submarina de un servicio de red iceberg , cuyo protocolo básico es el protocolo de aplicación SMTP definido por RFC 5321. Es responsable de la entrega de correos electrónicos. Se forma un sobre denominado SMTP para la entrega del correo electrónico, que incluye las direcciones del remitente y el destinatario del nivel SMTP. Otros servicios de red, como DNS, también son responsables de entregar el correo electrónico. El componente principal de la infraestructura de red es el Agente de transferencia de correo (MTA). El MTA es responsable de entregar la cola de entrega de mensajes y el proceso de entrega a los servidores receptores. Los ejemplos de MTA incluyen Postfix, Sendmail, Exim, servicio SMTP de Microsoft.

A esta parte submarina del iceberg, que incluye el MTA, los parámetros de DNS y otros parámetros de red, llamaremos infraestructura de correo electrónico o infraestructura de entrega de mensajes.

La punta del iceberg : el correo electrónico en sí. La estructura básica del correo electrónico está definida por el RFC 5322 estándar. El correo electrónico consta de encabezados de servicio y una o más partes de datos. Los datos pueden estar en formato de texto plano y / o HTML o incluso AMP, con imágenes en línea o archivos adjuntos de casi cualquier tipo.

La interfaz de la infraestructura de correo electrónico y los límites de la aplicación probada.

La infraestructura de correo electrónico, como regla, tiene una o varias interfaces a través de las cuales se envía un correo electrónico (cuando ingresa a la cola de entrega del MTA). Por ejemplo, el servicio de envío SMTP, la función mail() en PHP, transferencia de datos a una aplicación de correo externo o sendmail, API para servicio interno o externo (como GetResponse, SendPulse o Amazon SES). Consideraremos estas interfaces como parte de la infraestructura. A menudo sucede que la Aplicación A prepara los datos para un correo electrónico y una lista de destinatarios, y luego los envía a la Aplicación B a través de su API (para los correos masivos de marketing, esto se puede hacer manualmente a través de la interfaz de usuario-UI), y la aplicación B genera un mensaje de correo en RFC 5322 y lo entrega al MTA. Para la aplicación A (y al probarla), la aplicación B será parte de la infraestructura de correo electrónico. La API o IU de la aplicación B será para la interfaz de la aplicación A de la infraestructura de correo. Aunque para la Aplicación B, la situación será diferente, y la infraestructura de correo para ella será aplicaciones o protocolos de red de nivel inferior.

Definición de parámetros de prueba

Al probar cada aplicación, es importante seleccionar todas las infraestructuras de correo utilizadas (puede haber varias de ellas) y para cada infraestructura seleccionar las interfaces utilizadas (también puede haber varias para cada infraestructura). Para cada interfaz, la composición y el formato de los datos que se le transmiten se determina con la mayor precisión posible, por ejemplo, texto de correo electrónico en TEXTO / HTML, texto de correo electrónico en TEXTO / NORMAL, asunto del correo electrónico, nombre del destinatario, dirección del destinatario, nombre del remitente, dirección del remitente (RFC5321.From), la dirección del remitente del convector SMTP (RFC5322.mailfrom). A continuación, se desarrolla un conjunto de requisitos para cada parámetro (representaciones, codificaciones, valores límite, etc.), se determinan métodos para monitorear cada uno de los parámetros (cómo comparar el resultado real con el esperado).

Estructura típica de una aplicación generadora.

Como regla general, el mismo producto que estamos probando es responsable de la generación de correos electrónicos y datos en él. Esta suele ser una aplicación de servidor (pero a veces cliente). Define la estructura del correo electrónico, parte de los encabezados del servicio, formatos de encapsulación de datos, representaciones de cadenas y codificación de texto. Un ejemplo simple de tal aplicación es el script que forma el correo electrónico y llama a la función mail() . Los principales elementos de la aplicación que deben controlarse son:

el código responsable de generar encabezados y / o estructura de correo electrónico, si la estructura de correo electrónico se genera dinámicamente, y / o plantillas de correo electrónico estáticas que describen su estructura;
Diseño HTML del correo electrónico (idealmente, es una entidad separada o parte de la plantilla / diseño del correo electrónico, pero se puede incrustar en el código de la aplicación);
sustitución de datos de la aplicación en un correo electrónico (o en una plantilla de correo electrónico);
integración de la aplicación con la infraestructura de entrega de correo electrónico, la corrección de los parámetros pasados a la interfaz de la infraestructura.

Qué y cuándo probar

Nos guste o no, todo el iceberg debe ser probado. Hay varios componentes principales que requieren pruebas:

Infraestructura de entrega

El énfasis en las pruebas debe hacerse en: entregabilidad del correo electrónico; registros DNS correctos, incluidos registros PTR / FCrDNS, MX y A; Parámetros del protocolo SMTP (HELO, use TLS); autorización por correo electrónico (SPF / DKIM / DMARC); Direcciones de sobres SMTP (si la aplicación no las administra); corrección del procesamiento de los parámetros de entrada de la interfaz de infraestructura; seguimiento, grabación y procesamiento de correos electrónicos no entregados.

Es necesario probar la infraestructura durante la implementación inicial y cada vez que se realizan cambios en la infraestructura misma (la configuración del MTA, DNS o cambios de red) o la interfaz para enviar un correo electrónico; utilizando un nuevo dominio, red o API; se requieren pruebas adicionales si las características de los correos electrónicos enviados, como su idioma, tamaño o números, cambian significativamente. Según la experiencia, la infraestructura tiende a cambiar "por sí misma", por lo que las pruebas básicas deben realizarse periódicamente, incluso si no hay información sobre los cambios.

Es posible y necesario involucrar al ingeniero de redes y al especialista en entregabilidad en la elaboración del plan y las listas de verificación para probar la infraestructura.

Aplicación de generación

Las direcciones del sobre SMTP deben ser monitoreadas (si la aplicación las controla, es decir, se transfieren a la interfaz - desde-sobre, sobre-hasta), los valores de los encabezados de servicio del correo electrónico (Fecha, Mensaje -ID, Lista-Darse de baja, Autoenviado, etc.). Cláusula), autorización de correo electrónico (DKIM / DMARC), codificación MIME (base64, entre comillas), corrección general del formato de correo electrónico, por ejemplo, la ausencia de caracteres no ASCII en los encabezados, la composición de los datos que se inyectan , la activación correcta de los desencadenantes, los mecanismos de cancelación de suscripción, los mecanismos de seguimiento para escribir y recopilar estadísticas (encabezados de administrador de correo, por ejemplo, Feedback-ID o X-Mailru-Msgtype, así como píxeles de seguimiento).

Es necesario probar una aplicación durante su desarrollo, cuando todos sus componentes relacionados que son responsables de generar y almacenar datos cambian, con cambios significativos en las plantillas de correo electrónico, al cambiar la infraestructura o interfaz utilizada, así como en el marco de regresiones generales

Plantillas de correo electrónico estructurales y tipográficas (pueden ser parte de una aplicación generadora o se desarrollan por separado)

Se verifica la estructura del correo electrónico (Tipo de contenido, Disposición de contenido, anidamiento de partes multiparte del correo electrónico, codificación de texto, parámetros de cadena), el valor del destino y los encabezados mostrados (De, Para, Responder a, Asunto ), la forma en que se muestra el correo electrónico en la lista de correos electrónicos y cuando se lee en varias interfaces, microformatos (por ejemplo, que un evento de calendario se reconoce como un evento de calendario o un boleto aéreo como boleto aéreo), marca.

Las plantillas de correo electrónico deben probarse cada vez que realice al menos los más mínimos cambios, así como por separado, por ejemplo, en una situación en la que los correos electrónicos ingresan a la aplicación antes de que la parte del servidor esté lista.

Se recomienda involucrar a un especialista en marketing por correo electrónico y a un especialista en capacidad de entrega para compilar una lista de verificación para probar una plantilla de correo electrónico.

Requisitos básicos para verificar la infraestructura

La dirección IP seleccionada para el servidor de correo debe estar lo más cerca posible de la dirección IP del servidor de correo. Se recomienda verificarlo utilizando la utilidad whois. En particular, la dirección del remitente no debe pertenecer a la red, que puede percibirse como dinámica; la red seleccionada debe tener contactos activos a los cuales se pueden enviar quejas; se debe usar la red (tener el estado ASIGNADO en RIPE) La dirección IP debe tener un registro PTR configurado correctamente. Se puede configurar de forma independiente a través del panel de control de hosting o con la ayuda del proveedor de servicios. Un registro PTR debe apuntar al nombre de host real y aún ser significativo, resuelto de nuevo a la misma dirección IP (llamada verificación FCrDNS), no recordar el nombre del host dinámico y no incluir un gran grupo de números o caracteres. Un buen ejemplo es mailserver.example.com.

Cada dominio utilizado en direcciones de sobres o encabezados de correo electrónico debe tener un registro MX válido que apunte a un registro de host A, que, como mínimo, pueda manejar mensajes no entregados. MX no puede hacer referencia directa a una dirección IP.

Controla el paso de SPF, DKIM, DMARC. SPF permite al propietario del dominio especificar en los registros TXT una lista de servidores que están autorizados a enviar correos electrónicos con direcciones de retorno en este dominio. Está configurado para la dirección utilizada en el sobre desde (sobre SMTP) en la sección de gestión de zonas DNS del dominio. DKIM proporciona la verificación de la autoría de un mensaje o de su creador a un dominio específico utilizando tecnologías de firma digital, que se agrega al correo electrónico en sí (en su encabezado DKIM-Signature). Normalmente, una firma DKIM se configura en el nivel MTA (infraestructura). DMARC establece la política de verificar el correo entrante en un dominio específico y acciones en correos electrónicos que no pasan la autenticación SPF o DKIM. Al intentar infringir esta política, aparece un informe estructurado junto con información sobre dicho intento. DMARC, así como SPF, se publica como un registro TXT en la zona de dominio.

Compruebe la capacidad de entrega de los correos electrónicos a los principales servicios postales: para Rusia Mail.Ru, Yandex, Gmail, Microsoft (Hotmail / Outlook.com / Office365), Rambler, nic.ru. En los correos electrónicos recibidos, debe verificar la corrección de HELO; la presencia y aprobación de cheques PTR / FCrDNS, SPF, DKIM y DMARC; la validez de los encabezados y datos en ellos, en particular, el sincronismo del reloj en las fechas y la corrección de las zonas horarias.

(El correo de registro ha roto la autenticación debido a la dirección de correo electrónico utilizada)

La formación de algunos parámetros, por ejemplo, la autorización, la capacidad de entrega y el correo no deseado, están influenciados integralmente por todos los componentes, pero para su control, generalmente existen herramientas operativas separadas: informes DMARC y FBL, API de servicios de postmaster, herramientas de seguimiento de correo electrónico, estadísticas de entrega. Las pruebas deben tener en cuenta el nivel de implementación de las herramientas de monitoreo operativo en la empresa; por ejemplo, en ausencia de control operativo de los informes DMARC, la autorización de los correos electrónicos se debe probar regularmente, mientras que en ausencia de control operativo de la capacidad de entrega, donde y cómo van los correos electrónicos, incluso si no hay desarrollo relacionado con el envío de correos electrónicos.

Para probar la infraestructura, puede utilizar servicios especializados, por ejemplo, mail-tester.com, mxtoolbox.com. Los requisitos detallados de infraestructura se pueden encontrar en este artículo .

(un ejemplo del registro SPF roto)

Requisitos de autenticación

Por lo general, es posible verificar el paso de SPF, DKIM, DMARC utilizando el encabezado Authentication-Results en el servidor del destinatario.

Verifique la validez del registro SPF para la sintaxis, el límite para consultas DNS (por ejemplo, usando mxtoolbox.com). Al formar un SPF, se deben tener en cuenta todas las fuentes de correo (no olvide los sistemas CRM, todas las infraestructuras de entrega utilizadas actualmente, incluidas aquellas a través de las cuales se realizan campañas de marketing únicas). Se recomienda configurar los servidores permitidos para el dominio a través de la lista de redes ('ip4' / 'ip6'). SPF se verifica para la dirección del remitente desde el sobre SMTP. Verifique que el dominio del sobre SMTP (sobre-de) coincida con el dominio del encabezado De. Los errores comunes de SPF se enumeran en este artículo (https://medium.com/hackernoon/myths-and-legends-of-spf-d17919a9e817).

Verifique el registro DNS de DKIM, la validez y la composición de la firma DKIM. Verifique que está utilizando una clave DKIM de al menos 1024 bits. Modo hash recomendado de la firma DKIM: relajado / relajado. Asegúrese de que todos los encabezados importantes estén firmados (De, Para, Asunto, Fecha, ID de mensaje, Versión MIME, Tipo de contenido), que los encabezados de seguimiento (Recibido, Entregado a, Ruta de retorno) no estén firmados y DKIM está validado para servicios de correo básicos. Configure el reenvío a uno de los servicios de correo a otro; DKIM no debe "vencer" en los correos electrónicos reenviados. Verifique que el dominio de firma DKIM coincida con el dominio del remitente del encabezado 'De'.

Verifique DMARC para servicios básicos de correo electrónico. Verifique los informes DMARC, identifique y solucione problemas de SPF y DKIM para todas las direcciones IP de su infraestructura.

Verifique que los mensajes se entreguen a servidores externos mediante cifrado (TLS). A veces puede verificar TLS mediante el encabezado Recibido en el servidor del destinatario: por ejemplo, especificando el protocolo ESMTPS o teniendo parámetros de la forma (versión = cifrado TLS1_2 = ECDHE-RSA-AES128-GCM-SHA256 bits = 128/128); indica la presencia de TLS.

Verificación de la aplicación generadora

Requisitos de dirección de correo electrónico

Direcciones de sobres

Comenzamos la verificación de la aplicación generadora con las direcciones en el sobre SMTP.
Las direcciones de sobre son direcciones del nivel de infraestructura de correo electrónico. No son visibles para el usuario, pero son importantes para la entrega porque la dirección del sobre determina en qué buzón ingresa el correo electrónico.

La dirección del destinatario en el sobre ( envelope-to , también conocido como RCPT TO: es la dirección a la que realmente se entregará el correo electrónico.

Para todos los correos electrónicos, excepto para el registro, la dirección debe estar legalmente firmada y validada para su envío de acuerdo con los requisitos administrativos.
para los boletines, la dirección debe ser "en vivo", las direcciones a las que el correo electrónico no se puede entregar regularmente deben marcarse como inactivas, no se deben enviar correos a ellos. Pero algunas categorías de correos electrónicos (por ejemplo, recuperación de acceso) también pueden necesitar enviarse a direcciones previamente marcadas como inactivas.

Dirección del remitente en un sobre SMTP (generalmente llamado envelope-from , smtp.mailfrom , MAIL FROM: o Return-Path ): se enviarán mensajes a esta dirección sobre la imposibilidad de entregar un correo electrónico y respuestas automáticas. Esta dirección no es visible para el usuario. Esta dirección también se utiliza para la autorización SPF. Verificamos que:

La dirección está disponible;
No es la dirección del empleado y no se redirige a él para excluir respuestas automáticas, mensajes sobre inaccesibilidad, etc.
Es procesado por un script que marcará las direcciones de usuarios inaccesibles como inactivas;
La dirección se puede generar automáticamente, es decir, exclusiva de cada correo electrónico;
Un correo electrónico a esta dirección no debe generar la generación de ningún correo electrónico de respuesta, por ejemplo, un mensaje sobre el desbordamiento de un buzón.

Direcciones de encabezado de correo electrónico

Estas direcciones son directamente visibles para el usuario o se utilizan al responder a un correo electrónico.
Dirección del remitente (el encabezado From: es la dirección y el nombre del remitente que se muestran en la lista de correos electrónicos y al leer un correo electrónico. Verificamos que:

Esta es una dirección amigable y legible que identifica a la empresa.
Contiene no solo una dirección de correo electrónico, sino también el nombre del remitente.
Noreply @ es posible, pero solo si queremos enfatizar que no esperamos recibir una respuesta al correo electrónico y que no se leerá. Es mejor duplicar esta idea en el texto del correo electrónico.
En presencia de caracteres no ASCII (por ejemplo, cirílico), el nombre del remitente debe codificarse de acuerdo con MIME, el dominio en presencia de caracteres no ASCII debe codificarse en Punycode
Los correos electrónicos de la misma categoría deben tener la misma dirección; Se debe evitar el uso de direcciones autogeneradas. Esto se debe al hecho de que "De:" se usa con mayor frecuencia por las personas para ordenar los correos electrónicos por carpetas mediante filtros.
La dirección debe ser diferente (preferiblemente en diferentes subdominios) para correos electrónicos transaccionales, de marketing y urgentes (como correos electrónicos del servicio de soporte). Esto también se debe al hecho de que el usuario puede marcar los correos electrónicos de marketing como spam o filtrarlos en una carpeta ilegible.
La dirección From: y la dirección del sobre SMTP deben estar en el mismo dominio o en subdominios del mismo dominio organizacional para pasar el SPF dentro del DMARC.
La dirección debe ser del dominio de la organización. Es inaceptable utilizar servicios de correo gratuitos y otros dominios de correo público en From: ya que dichos correos no pasarán la autenticación SPF y DKIM en el marco de DMARC.

La dirección Reply-to - las respuestas 'manuales' se enviarán a esta dirección cuando un usuario responda un correo electrónico. Es opcional. Si está ausente, la dirección de 'De:' se usa para la respuesta. Compruebe que 'Responder a':

Se puede generar automáticamente, es decir, exclusivo del correo electrónico (le permite averiguar a qué correo electrónico llegó la respuesta).
No debe caer en el buzón del empleado para evitar la respuesta automática, sino que idealmente debe estar "envuelto" en CRM.
Puede generar una respuesta automática CRM estándar, pero no debe generar nada superfluo, por ejemplo, desbordamiento de buzón o mensajes "en vocación". Cuando se generan respuestas automáticas, se deben tomar medidas para evitar bucles, se enumeran en RFC 3834.
Puede ser de cualquier dominio que no necesariamente coincida con 'De:', pero a veces esto asusta a los usuarios cuando responden.
Puede estar ausente, entonces la dirección From: realiza sus funciones.
Además de la dirección, se indica el nombre del remitente.

La dirección To:

Debe contener el correo electrónico del destinatario (de lo contrario, asusta al destinatario del mensaje y molesta al antispam).
Idealmente, debe contener el nombre del destinatario. Pero si el nombre es desconocido o dudoso (por ejemplo, la dirección aún no se ha confirmado), es mejor no indicarlo (alguien puede ingresar la dirección de otra persona con un nombre incorrecto y el destinatario puede ofenderse).

Requisitos de encabezado de correo electrónico

La codificación real del texto debe coincidir con la indicada en el encabezado. Es recomendable utilizar una codificación en todos los encabezados y partes del correo electrónico. Se recomienda que use UTF-8 como uno ampliamente compatible. La codificación se indica en los encabezados de tipo de contenido y en la etiqueta de la parte HTML.

Los encabezados From:, Message-ID: y Date: deben formarse directamente en el script para enviar el correo electrónico (y según los estándares, junto con el texto del correo electrónico) y siempre en el formato correcto. Si están ausentes o se formaron incorrectamente, uno de los servidores de tránsito puede agregar estos encabezados, lo que lleva a una violación de la integridad de la firma DKIM.

Los caracteres de 8 bits en los encabezados, incluida la línea de asunto (Asunto) y los nombres de los archivos adjuntos (Tipo de contenido y Disposición de contenido), deben estar ausentes; Todos los caracteres no ASCII, incluidos los cirílicos, deben codificarse en comillas imprimibles o en base64.

(confirmación de registro en codificación extraña)

Requisitos para la estructura del correo electrónico.

Para la parte HTML del correo electrónico, es deseable formar una parte alternativa: texto (sin formato). También es necesario verificar la conformidad y la legibilidad de la parte de texto sin formato del correo electrónico (si corresponde) y la estructura general del correo electrónico.

Según RFC 5322, la longitud de una línea en un correo electrónico no debe exceder los 998 caracteres de 8 bits. Tenga en cuenta que en UTF-8, un personaje puede ocupar varios octetos. El terminador de líneas en un correo electrónico es un par de CRLF (ascii 13, ascii 10), que toma 2 octetos. Debe verificar la exactitud del terminador de cadena, ya que los correos electrónicos a menudo se envían utilizando un script Unix, y en Unix, el terminador de cadena es un solo carácter; este es un error para el correo electrónico. También debe verificar si los terminadores de cadena rompen caracteres codificados UTF-8: no puede permitir la presencia de un terminador de cadena entre dos octetos del mismo carácter, por ejemplo, símbolo cirílico. Para evitar tales situaciones, es necesario romper el texto antes de formar el correo electrónico o codificar el texto en base64, base64 generalmente tiene una longitud de línea fija.

Es necesario verificar el marcado correcto de los archivos adjuntos e inlines, es decir, la corrección de la formación de los encabezados "Content-Disposition: inline", si se trata de una imagen que se muestra dentro del correo electrónico, o "Content-Disposition: adjunto" si el archivo adjunto está destinado a la descarga.

La estructura del correo electrónico debe ser lo más simple posible: en particular, no debe haber más de una parte multiparte de cada tipo (mixta, alternativa, relacionada), y multiparte / mixta se usa solo si el correo electrónico contiene archivos adjuntos, multiparte / relacionado - si HTML viene con imágenes en línea, multiparte / alternativa - en presencia de texto sin formato y partes HTML. En general, la estructura del correo electrónico, en ausencia de archivos adjuntos e imágenes en línea, debería verse así:

multiparte / alternativa
- texto / sin formato
- texto / html

El orden de las partes es importante, text / plain debe ir ANTES de text / html o multipart / related. Esto es necesario para que la parte HTML se muestre de manera predeterminada, y solo si su visualización no está disponible por alguna razón, se muestra la parte simple.

Si hay imágenes en línea en el correo electrónico, su estructura debería verse así:

multiparte / alternativa
- texto / sin formato
- multiparte / relacionado
—— texto / html
—— imagen / ... (imagen en línea)
—— imagen / ... (imagen en línea)

Las imágenes en línea deben tener Content-Disposition: en línea y estar estrictamente dentro de la parte multiparte / relacionada.
En el caso más difícil, cuando hay imágenes en línea y archivos adjuntos, el correo electrónico tiene la siguiente estructura:

multiparte / mixto
- multiparte / alternativa
—— texto / sin formato
—— multiparte / relacionado
——— texto / html
——— image / png
——— image / png
...
- application / octet-string (disposición de contenido: archivo adjunto)
- application / octet-string (disposición de contenido: archivo adjunto)
...
las partes relacionadas con varias partes y las partes alternativas deben estar cerradas antes de los archivos adjuntos, los archivos adjuntos pertenecen a la parte externa de partes múltiples y mixtas)

(mensaje de registro con estructura de piezas incorrecta)

Requisitos de URI

Cualquier URI (en src, atributos href, estilos, etc.) debe contener el protocolo y el nombre de host (https://example.com/somepath). Los errores típicos son el uso de enlaces relativos (/ somepath) y la falta de un protocolo (//example.com/somepath), que es inaceptable para los correos electrónicos, porque en ellos, el protocolo predeterminado puede ser file:// .

Cualquier servicio y caracteres no ASCII (en particular, cirílico) en el URI deben codificarse utilizando codificación porcentual.
Un enlace insertado como texto (es decir, visible para el usuario como una URL, y no como un texto) aún debe estar marcado con la etiqueta <> , de lo contrario, el usuario no podrá hacer clic en él. Algunos correos web marcan dichos enlaces por sí mismos, pero este no es un comportamiento estándar. En este caso, la dirección href dentro de A debe coincidir con el texto del enlace, de lo contrario, el filtro de contenido puede reaccionar a dicho enlace como un intento de engañar al usuario. Vale la pena prestar especial atención a esto cuando hay "clickers" que rastrean las transiciones del usuario desde el correo electrónico.
Es mejor limitarse al uso de los protocolos http:// , https:// y mailto:
Con requisitos de alta seguridad, debe abandonar por completo el uso de http:// en favor de https:// .
No se deben utilizar puertos no estándar (por ejemplo, example.com : 8080 / somepath), ya que es posible que el usuario no pueda acceder a ellos.
Al hacer clic en el enlace dentro de la parte HTML no se deben realizar cambios en el estado de la aplicación (suscripción, cancelación de la suscripción, cancelación del pedido, etc.) sin la confirmación adicional del usuario en la página, ya que algunos sistemas de filtrado de contenido pueden verificar la seguridad de tal transición solicitando una página por referencia; la aplicación de correo puede mostrar la vista previa de la página mediante el enlace al pasar el mouse, y los navegadores modernos pueden cargar la página antes de que el usuario haga clic en el enlace para reducir el tiempo de carga (en la aplicación web generalmente no se recomienda realizar ninguna acción de modificación en el Solicitud GET, todas las solicitudes de modificación deben pasar por POST o PUT).
Al hacer clic en el enlace en el encabezado List-Unsubscribe, por el contrario, no debería requerir ninguna acción adicional del usuario, ya que la cancelación de la suscripción por este enlace generalmente se realiza por correo electrónico o webmail en nombre del usuario. Además, hay un nuevo encabezado List-Unsubscribe-Post introducido por RFC 8058.
No debe esperar que el usuario lea el correo electrónico y siga el enlace en el mismo navegador en el que inicia la acción que conduce al envío del correo electrónico (por ejemplo, registra una cuenta). El enlace debería funcionar en cualquier otro navegador o dispositivo móvil. En particular, el usuario puede abrir el enlace sin estar autorizado, o autorizado en una cuenta diferente a la que se envió el correo electrónico.
Porque la longitud del URI puede ser limitada; no debe usar URI del tipo 'datos:' para objetos grandes. Por la misma razón, no use URI que sean demasiado largos en hipervínculos.
No debe usar acortadores de enlaces externos, esto afecta negativamente la entrega de correos electrónicos. Es mejor si todos los enlaces apuntan a su dominio, esto reducirá el impacto negativo potencial de la reputación de otra persona en la entrega de correos electrónicos.
No coloque imágenes externas en algunos servicios públicos o alojamiento gratuito, utilice un servicio de alojamiento confiable o CDN con buen rendimiento y reputación.

(imagen no válida y URI de anclaje debido a la falta de especificación de protocolo)

Requisitos de diseño de correo electrónico

¿Por qué es tan difícil inventar correos electrónicos?

Los clientes de correo electrónico de una forma u otra muestran el contenido del usuario dentro de su interfaz. Potencialmente, esto puede conducir a varios problemas de seguridad: scripting entre sitios (XSS, scripts Crossite), suplantación de interfaz, clobber DOM, desanonimización del usuario / fuga de información (por ejemplo, la dirección IP del usuario o cookies a través de solicitudes externas), etc. ., por lo tanto, cualquier servicio de correo y aplicación de correo tiene alguna forma de protección contra cada clase de ataques. Desafortunadamente, no existe un enfoque único para organizar esta protección. Se puede organizar a través de:

marcos limitados aislados,
filtrado de etiquetas y / o atributos,
restricciones en el posicionamiento absoluto,
prohibición o restricción en el uso de estilos de bloque (que es crítico para el diseño adaptativo),
prohibir elementos externos de forma predeterminada (es decir, descargar imágenes externas requiere permiso del usuario) o usar un proxy para acceder a ellos,
convertir correos electrónicos HTML a otro formato intermedio (por ejemplo, Microsoft Exchange / Outlook usa RTF, lo que puede hacer que sea extremadamente difícil mostrar elementos correctamente en Outlook usando métodos convencionales),
prohibición o restricción en el uso de formularios o sus elementos individuales.

Los correos electrónicos también usan elementos específicos, como imágenes en línea y URI cid:// , cuyo soporte puede ser limitado. Por ejemplo, Mozilla Thunderbird no admite cid:// para imágenes de fondo.

Incluso un correo electrónico formado correctamente se puede mostrar de manera diferente en diferentes interfaces debido a las peculiaridades de su implementación y filtrado de los contenidos del correo electrónico.

Si hay errores en el formato del correo electrónico, el comportamiento se vuelve completamente impredecible. Por ejemplo, los clientes de correo electrónico pueden tener un comportamiento diferente con URI incorrectos, o ese formato de encabezado incorrecto se maneja de manera diferente. Además, la detección automática de codificación de texto funciona de manera diferente si no se especifica o se especifica incorrectamente. Por lo tanto, el correo electrónico debe verse en diferentes interfaces: la visualización correcta del correo electrónico en una interfaz no significa que esté compuesto correctamente (de hecho, incluso la visualización correcta del correo electrónico en todas las interfaces no garantiza que no habrá problemas con la pantalla en el futuro).

Es necesario prestar atención a los siguientes puntos:

Verifique el texto del correo electrónico en busca de contenido semántico, visualización, ausencia de errores tipográficos, errores sintácticos, ortográficos y léxicos.
Verifique la corrección de la sustitución de los datos de la aplicación en la plantilla o el diseño del correo electrónico.
Verifique la exactitud de las cantidades, fechas, números, artículos de bienes y otra información, teniendo en cuenta las condiciones límite permitidas. Las fechas deben tener un año (algunos usuarios ingresan al cuadro muy raramente). Una zona horaria debe estar presente en el tiempo. La dirección debe contener una ciudad y, en algunos casos, es necesario indicar el país.
Verifique el estado operativo de todos los enlaces en el correo electrónico, si corresponde.
En correos electrónicos enviados antes de la confirmación de la dirección, incl. correos electrónicos con un enlace de confirmación, no debe haber ningún texto controlado desde el exterior, ni siquiera el nombre de usuario, de lo contrario, se pueden usar para correo no deseado (en el campo que se muestra en el correo electrónico, por ejemplo, en el nombre, se inserta el texto de correo no deseado y la dirección es la dirección indicada de la víctima). Por ejemplo, si puede enviar un texto obsceno en la dirección del desarrollador en nombre de su servicio, entonces hay un problema.
Verifique la ausencia de imágenes externas en servicios de terceros. Puede afectar la entrega y la filtración de información sobre sus clientes.
Verifique la disponibilidad de contadores para envío, entrega, lectura de correo electrónico, transiciones. Algunos de ellos se encuentran en el propio correo electrónico (por ejemplo, el contrapíxel de la lectura del correo electrónico), algunos son rastreados por el correo, pero, por regla general, todos están disponibles en el panel de administración del correo.
Verifique la corrección de la categoría de suscripción y la cancelación de la suscripción del usuario para esta categoría a través del enlace en el correo electrónico.
Comprueba cómo se ve el correo electrónico a:
- Versiones web populares de correo para un país objetivo: los "tres grandes" para Rusia son Mail.Ru, Yandex, Gmail. También puede agregar Rambler y Outlook.com;
- Aplicaciones móviles de los proveedores de correo electrónico anteriores;
- Aplicaciones móviles estándar que utilizan IMAP, teniendo en cuenta las plataformas móviles populares, al menos para iPhone, Pixel (plataforma de referencia de Android), Samsung (la más común para Android), MIUI (ocupa el segundo lugar en Rusia para las plataformas de Android);
- Varios navegadores de escritorio: Chrome, Firefox, Edge, Internet Explorer, Opera, etc.
- Aplicaciones de escritorio (programas de correo electrónico), especialmente Thunderbird, Outlook y Apple Mail, opcionalmente The Bat! y Opera Mail;
- Soluciones corporativas populares con una interfaz web (Exchange, quizás Roundcube, Communigate, Zimbra, SquirrelMail) - para soluciones B2B;
- No olvide comprobar el diseño tanto en los monitores Retina como en los monitores con una resolución más baja.
Durante el control en cada caso, debe prestar atención a:
- Pasando los encabezados de autorización, SPF / DKIM / DMARC.
- Velocidad de descarga del correo electrónico: debe cargarse rápidamente y no tomarse su tiempo.
- Mostrar un correo electrónico en la lista de correos electrónicos: avatar, nombre del remitente y el asunto que pertenece al fragmento del mensaje, si su categoría se definió correctamente (por ejemplo, si el pedido no se incluyó en la categoría de "redes sociales").
- El diseño del correo electrónico en su conjunto: si el diseño se mantuvo constante, ¿hubo saltos de palabra incorrectos, etc., incluso al escalar y cambiar el tamaño de la ventana?
- Las fuentes no deben ser pequeñas o difíciles de leer.
- Imágenes de fondo y colores de fondo.
- A juego con el libro de la marca.
- Facilidad de realizar las acciones que implica el correo electrónico. Por ejemplo, si el correo electrónico contiene un código de confirmación u otra información que deba almacenarse en algún lugar, entonces no solo debe leerse bien, también debe ser conveniente seleccionarlo y copiarlo incluso en la interfaz móvil.
Mantenga un registro del tamaño general del correo electrónico (incluidas las imágenes externas) y de que no exceda los valores razonables. Cuanto más pesado sea el tiempo de carga, más probable es que una persona tenga una reacción negativa.
Incluso los correos electrónicos que no se han modificado deben revisarse periódicamente, ya que los cambios pueden ocurrir en el lado del servicio postal y, por ejemplo, "revelar" un problema previamente invisible.
Algunos parámetros deben controlarse en todas las pruebas. Por ejemplo, los problemas al pasar la autenticación DKIM pueden deberse a problemas en la infraestructura (problemas con el DNS o la formación de una firma DKIM, errores de sincronización de tiempo), debido a errores en el programa generador (la dirección del remitente está formada incorrectamente, caracteres incorrectos en faltan los encabezados o los encabezados obligatorios From, Date o Message-ID se han duplicado) y debido a errores de contenido (terminadores de línea incorrectos, las líneas son demasiado largas, direcciones incorrectas). Al mismo tiempo, el correo electrónico no puede "vencer" y el problema puede no aparecer en ningún servicio.

Realización de pruebas divididas

La investigación de mercado está más allá del alcance de este artículo, pero se deben mencionar algunos puntos clave que afectan significativamente la calidad de los correos electrónicos.

The newsletter has a purpose, so it should entail through its quality, not quantity (which is the opposite for spammers). The newsletter must be segmented. When conducting an advertising campaign, you need to know exactly who gets into the segment sample, why they need the offered product and what they want to convey.

For each mailing list, it is necessary to calculate the CTR of the list of emails — this is the ratio of the number of emails read to the total number that has been sent out. In postmaster.mail.ru, you can see indicators for unique users. If the measurement goes through the counter in the email (pixel), then the absolute number of openings is estimated. CTR <10% is a very low indicator, it is undesirable to carry out such mailing. It should strive for a CTR> 30%. For marketing emails, the clickthrough rate of clickthroughs and the percentage of completed actions («sales») on these links are also of great importance. Be sure to monitor complaints (marking the email as spam). Typically, for one-time mailings, a tenth of a percent is a good indicator, for regular ones, a hundredth of a percent. The critical values, after which the mailing is always interpreted as spam, are indicated here: https://help.mail.ru/developers/mailing_rules/technical .

It is necessary to conduct split testing of various distribution options to obtain optimal performance. Just changing the name of the sender and the subject of the email can increase the CTR by several times and significantly reduce the number of complaints. The number of emails should be statistically significant for evaluating the results (for large projects, usually a few thousand). The final version of the email is sent in several stages for additional measurement of indicators and «warming up» — starting with about 10,000 recipients, with an increase of about an order of the day.

The main idea: emails are part of your application, perhaps one of the most complex and problematic. At the same time, this is often a «blind spot» in terms of testing. I hope that I was able to draw your attention to this issue.

I would like to thank Vladimir Dubrovin ( z3apa3a ) and Alena Likhacheva ( s4ever ) for helping me with this article. As well as that, the article utilised sources of Eduard Tyantov ( edT ) and Alexander Purtov ( 4Alexander ).

Cómo hacer correos electrónicos y no desordenar: consejos prácticos