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

El desarrollador, que se encontró por primera vez con la generación de correos electrónicos, no tiene prácticamente ninguna posibilidad de escribir una aplicación que lo haga correctamente. Alrededor del 40% de los correos electrónicos generados por las aplicaciones corporativas tienen algún tipo de violación de los estándares y, como resultado, problemas de entrega y visualización. Hay razones para esto: el correo electrónico es técnicamente mucho más complicado que la web, el correo está regulado por varios cientos de estándares y un número incontable de prácticas generalmente aceptadas (y no tan), y los clientes de correo electrónico son diversos e impredecibles. Las pruebas pueden mejorar significativamente la situación, pero prácticamente no hay materiales dedicados a probar el correo.

El correo Mail.Ru interactúa regularmente con sus usuarios a través de correos electrónicos. En nuestro proyecto, todos los componentes que son responsables de generar correos electrónicos, e incluso correos únicos, se someten a pruebas obligatorias. En este artículo compartiremos nuestra experiencia (y llena de golpes).

• ¿Qué son los correos electrónicos?
• ¿Quién participa en el proceso de prueba y control?
• Correo y transporte postal
• La interfaz de la infraestructura de correo y los límites de la aplicación bajo prueba.
• Definición de parámetros probados
• Estructura típica de una aplicación generadora.
• Qué y cuándo probar
  
  1. Infraestructura de entrega
  2. Aplicación de generación
  3. Plantillas de cartas estructurales y de diseño
• Requisitos básicos para verificar la infraestructura
• Requerimientos de Autorización
• Verificación de la aplicación generadora
  
  • Requisitos de dirección postal
  • Requisitos de encabezado de correo electrónico
  • Requisitos para la estructura de la carta.
  • Requisitos de URI
  • Requisitos de diseño
• Realizar pruebas divididas

¿Qué son los correos electrónicos?

La aplicación puede generar varios tipos de letras. Se pueden clasificar en varias categorías. Por el método de selección de destinatarios: disparador - selectivo - grupo. Con cita previa: transaccional - comercialización - servicio. Los diferentes tipos de letras pueden tener diferentes requisitos y aplicar diferentes scripts de prueba.

Los correos electrónicos de activación se generan en respuesta a cualquier evento, por ejemplo, acciones del usuario o cambios en el estado de cualquier objeto del sistema. Son generados por la aplicación y, por lo tanto, son los más interesantes en términos de pruebas. Los correos electrónicos de activación pueden ser tanto transaccionales como de marketing.

Se envían cartas personalizadas a una selección dinámica de usuarios que coinciden con cualquier criterio.

Los mensajes de grupo se envían a un grupo conocido de destinatarios, por ejemplo, a todos los usuarios o socios. Las cartas selectivas y grupales suelen ser marketing, el envío de dichas cartas se inicia manualmente o de acuerdo con un cronograma.

Las letras transaccionales se generan cuando un usuario realiza una acción. Dichas cartas incluyen, por ejemplo, facturas, tickets o notificaciones de estado de entrega, cartas con un código de recuperación de acceso, etc. Los correos electrónicos transaccionales siempre son desencadenantes. La máxima compatibilidad es importante para ellos, lo que significa que deben ser lo más simples posible y deben probarse en una gran cantidad de clientes.

Las cartas de marketing alientan al usuario a tomar cualquier medida, por ejemplo, puede ser una oferta de descuentos individuales basados ​​en compras anteriores. En estas cartas, se pueden usar datos transaccionales, que pueden ser tanto desencadenantes como masivos, periódicos o únicos. Para estas letras, la eficiencia es más importante, generalmente está determinada por los resultados de una prueba dividida. Algunos aspectos de compatibilidad pueden ser sacrificados por la eficiencia.

Las cartas 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 solicitud, pero puede (y debe) aplicarles principios de prueba generales.

Además, puede haber cartas de servicio generadas por los empleados para sistemas de CRM, diario, auditoría o DWH automatizados o automatizados. Dichas letras son desencadenantes, lo que significa que también forman parte de la aplicación y deben probarse.

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

1. Ingeniero de control de calidad: participa en todas las etapas del proceso.
2. Ingeniero de redes: responsable de configurar la red y la infraestructura de mensajería. Un ingeniero de redes debe participar en la planificación de las pruebas de infraestructura.
3. Un especialista en entregabilidad es una persona que supervisa la entrega de cartas, que también participa en la supervisión de los parámetros técnicos y administrativos de todos los mensajes enviados y supervisa el progreso del proceso de envío. Es responsable de garantizar que las cartas enviadas lleguen al máximo porcentaje posible de usuarios y no caigan en el correo no deseado, y para ello el especialista debe tener ciertos conocimientos y contactos. Si surgen problemas con la entrega de cartas, es él quien debe comprender la causa probable y eliminarla: ya sea eliminando obstáculos técnicos; o cambiar algo en el contenido de las letras; o resolver el problema con el servicio de soporte del proveedor de correo, al que no llegan las cartas. Dicho especialista (si lo hay) también debe participar en la preparación de una lista de verificación y pruebas de la infraestructura que genera aplicaciones y cartas. Sin embargo, el proceso de prueba en sí debe estar bajo el control del servicio de control de calidad.
4. Email marketing: determina la efectividad de las campañas de marketing. Bajo su control, se realizan las pruebas divididas para la audiencia necesarias para los correos de marketing. El vendedor del correo electrónico también controla la segmentación de la base de usuarios, la composición y frecuencia de los correos electrónicos enviados, y la "presentación" visual del correo electrónico al usuario.

Todos estos roles no los desempeña necesariamente un empleado separado: uno de los gerentes de producto puede desempeñar el papel de un comercializador y, por ejemplo, un empleado de soporte o un ingeniero de redes puede desempeñar el papel de un especialista en entrega. Y en las startups con un alto grado de probabilidad, todo esto tendrá que hacerlo una sola persona, y pueden llegar a ser un especialista de calidad.

Correo y transporte postal

La estructura del correo es similar a un enorme iceberg, y tiene dos niveles. Existen más de cien estándares diferentes que rigen el correo, pero casi todos pertenecen a uno de estos dos niveles:

La parte submarina del iceberg es un servicio de red cuyo protocolo básico es el protocolo de aplicación SMTP, definido por RFC 5321. Es responsable de la entrega de cartas. Para entregar la carta, se forma un llamado sobre SMTP, que incluye las direcciones del remitente y el receptor del nivel SMTP. Otros servicios de red como DNS también son responsables de entregar la carta. El componente principal de la infraestructura de red es el Agente de transferencia de correo, o la abreviatura MTA se usa con más frecuencia. MTA es responsable de manejar la cola de entrega de mensajes y el proceso de entrega a los servidores receptores. Ejemplos de MTA son 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 o infraestructura de entrega de mensajes.

La superficie del iceberg es la letra misma. La estructura básica de la carta se define en RFC 5322. La carta consta de encabezados de servicio y una o más partes con datos. Los datos pueden contener texto en texto plano y / o HTML, imágenes en línea o archivos adjuntos de casi cualquier tipo.

La interfaz de la infraestructura de correo y los límites de la aplicación bajo prueba.

La infraestructura de correo, por regla general, tiene una o más interfaces con las que se envía una carta (entra en la cola de entrega del MTA). Por ejemplo, el servicio de envío SMTP, la función mail() en PHP, la transferencia de datos a un correo externo o una aplicación sendmail, la API de servicios internos o externos (por ejemplo, GetResponse, SendPulse o Amazon SES). Consideraremos estas interfaces como parte de la infraestructura. Muy a menudo hay una situación en la que la aplicación A prepara datos para una carta y una lista de destinatarios, y luego los transfiere a la aplicación B a través de su API (para el marketing de envío masivo, esto se puede hacer manualmente a través de la interfaz de usuario - UI), y la aplicación B ya genera un mensaje de correo en Formato RFC 5322 y de alguna manera lo pone en cola para la entrega de MTA. Desde el punto de vista de la aplicación A (y al probarla), la aplicación B será parte de la infraestructura de correo. La API o UI de la aplicación B será la interfaz de infraestructura de correo para la aplicación A. Aunque desde el punto de vista de 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 probados

Al probar cada aplicación, es importante resaltar todas las infraestructuras de correo utilizadas (puede haber varias) 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 transfieren se determinan con la mayor precisión posible, por ejemplo: texto del mensaje en TEXTO / HTML, texto del mensaje en TEXTO / PLANO, asunto del mensaje, nombre del destinatario, dirección del destinatario, nombre del remitente, dirección del remitente de la carta (RFC5321.De ), la dirección del remitente del conductor SMTP (RFC5322.mailfrom). A continuación, se desarrolla un conjunto de requisitos para cada parámetro (representaciones, codificaciones, valores límite, etc.), se determinan los métodos de control para cada uno de los parámetros (de qué manera se puede comparar el resultado real con el esperado).

Estructura típica de una aplicación generadora.

Como regla general, el producto que estamos probando es responsable de generar la carta y los datos que contiene. Esta suele ser una aplicación de servidor (pero a veces cliente). Define la estructura de la letra, parte de los encabezados del servicio, formatos para la encapsulación de datos, presentación de cadenas y codificación de texto. Un ejemplo simple de tal aplicación es un script que forma una carta y llama a la función mail() .

Los principales elementos de la aplicación que deben controlarse:

• código responsable de generar encabezados y / o estructura de letras si la estructura de letras se genera dinámicamente y / o una plantilla de letras estática que describe su estructura;
• diseño de la parte HTML de la carta (idealmente, esta es una entidad separada o parte de la plantilla / diseño de la carta, pero se puede coser en el código de la aplicación);
• Sustitución de los datos de la aplicación en una carta (o en una plantilla de carta);
• integración de la aplicación con la infraestructura de entrega de cartas, la corrección de los parámetros transferidos 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:

1. Infraestructura de entrega

El énfasis en las pruebas debe colocarse en: entregabilidad de letras; la exactitud de los registros DNS, incluidos los registros PTR / FCrDNS, MX y A; Configuración del protocolo SMTP (HELO, usando TLS); autorización de carta (SPF / DKIM / DMARC); Direcciones de sobres SMTP (si la aplicación no las administra); procesamiento correcto de los parámetros de entrada de la interfaz de infraestructura; seguimiento, contabilidad y procesamiento de cartas no entregadas.

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 cartas; Usar un nuevo dominio, red o API Cambie significativamente las características de los correos electrónicos enviados, como su idioma, tamaño o cantidad. Según la experiencia, la infraestructura tiende a cambiar sin declarar la guerra, por lo que las pruebas básicas deben llevarse a cabo periódicamente, incluso si no hay información sobre los cambios.

Un ingeniero de redes y un especialista en capacidad de entrega pueden y deben participar en la preparación del plan y las listas de verificación de las pruebas de infraestructura.

2. La aplicación generadora

Debe controlar las direcciones del sobre SMTP (si están controladas por la aplicación, es decir, transferidas a la interfaz: desde-sobre, sobre-hasta), los valores de los encabezados de los mensajes de servicio (Fecha, ID de mensaje, Suscripción de lista, Envío automático, etc.) p.), autorización de letras (DKIM / DMARC), codificaciones MIME (base64, entre comillas), la corrección general del formato de letras, por ejemplo, la ausencia de caracteres no ASCII en los encabezados, la composición de los datos sustituidos, la activación correcta de los desencadenantes, mecanismos de cancelación de suscripción, mecanismos de seguimiento colección de cartas y estadísticas (encabezados de postmaster, por ejemplo, Feedback-ID o X-Mailru-Msgtype, así como píxeles de seguimiento) .

Debe probar la aplicación durante su desarrollo, al cambiar todos sus componentes relacionados responsables de generar y almacenar datos, con cambios significativos en las plantillas de letras, al cambiar la infraestructura utilizada o su interfaz, así como en el marco de regresiones generales.

3. Plantillas de cartas estructurales y de diseño (pueden ser parte de una aplicación generadora o se desarrollan por separado)

La estructura de la letra (Tipo de contenido, Disposición de contenido, anidamiento de las partes multiparte de la letra, codificación de texto, parámetros de cadena), el valor del objetivo y los encabezados mostrados (De, Para, Responder a, Asunto), la visualización de la letra en la lista de letras y cuando la lectura está marcada 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 cambios más pequeños, y también por separado, por ejemplo, en una situación en la que las cartas ingresan a la aplicación antes de que la parte del servidor esté lista.

Se recomienda que utilice un especialista en marketing por correo electrónico y capacidad de entrega para escribir una lista de verificación para probar una plantilla de carta.

Requisitos básicos para verificar la infraestructura

La dirección IP seleccionada para el servidor de correo debe ser lo más similar posible a 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 una red que pueda percibirse como dinámica; La red seleccionada debe tener contactos válidos a los que puede enviar quejas; se debe usar la red (tener 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 mediante el servicio de soporte del proveedor. El registro PTR debe apuntar al nombre real del host y, al mismo tiempo, ser significativo, resolver de nuevo a la misma dirección IP (la 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 mensajes debe tener un registro MX válido que apunte a un registro A del host, que, como mínimo, puede procesar mensajes sobre fallas en la entrega. Para MX, no está permitido referirse directamente a una dirección IP.

Controla el paso de SPF, DKIM, DMARC. SPF permite al propietario del dominio especificar en el registro TXT una lista de servidores que tienen derecho a enviar mensajes de correo electrónico 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 zona DNS del dominio. DKIM proporciona la verificación de la autoría de un mensaje o la pertenencia de su remitente a un dominio específico utilizando tecnologías de firma digital, que se agregan al mensaje 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 cartas que no pasan la autenticación SPF o DKIM. Cuando intenta violar esta política, llega un informe estructurado con información sobre dicho intento. DMARC, así como SPF, se publica como un registro TXT en la zona de dominio.

Verifique la entrega de cartas a los principales servicios postales: para Rusia, Mail.Ru, Yandex, GMail, Microsoft (Hotmail / Outlook.com / Office365), Rambler, nic.ru. En las cartas, debe verificar la corrección de HELO; disponibilidad y aprobación de cheques PTR / FCrDNS, SPF, DKIM y DMARC; la validez de los encabezados y los datos en ellos, en particular, el sincronismo de las horas en las fechas y la corrección de las zonas horarias.



La formación de ciertos parámetros, por ejemplo, autorización, entregabilidad y envío de correo no deseado, está influenciada integralmente por todos los componentes, sin embargo, generalmente hay herramientas operativas separadas para controlarlos: informes DMARC y FBL, API de servicio postmaster, herramientas de seguimiento de correo electrónico y estadísticas de entrega. Las pruebas deben tener en cuenta el nivel de implementación de las herramientas de supervisión operativa en la empresa; por ejemplo, en ausencia de la supervisión operativa de los informes DMARC, debe comprobar periódicamente la autorización por correo, en ausencia de la supervisión operativa de la capacidad de entrega: compruebe regularmente cómo y dónde se obtienen las cartas, incluso si no hay desarrollo relacionado con el envío de cartas No realizado.

Para verificar 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 .

Requerimientos de Autorizació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, 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 .

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 que DKIM esté validado para Servicios postales básicos. Configure el reenvío a uno de los servicios de correo a otro; DKIM no debe "vencer" en las cartas reenviadas. Verifique que el dominio de firma DKIM coincida con el dominio del remitente del encabezado De.

Verifique DMARC para servicios básicos de correo. 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 la presencia de parámetros del formulario (versión = TLS1_2 cifrado = ECDHE-RSA-AES128-GCM-SHA256 bits = 128/128); indica la presencia de TLS.

Verificación de la aplicación generadora

Requisitos de dirección postal

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. No son visibles para el usuario, pero son importantes para la entrega, porque en qué buzón se recibe la carta, está determinada precisamente por la dirección del sobre.

La dirección del destinatario en un sobre (sobre-a, también conocido como RCPT TO :) es la dirección a la que se entregará la carta.

• para todas las cartas, 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 no se pueden entregar cartas regularmente deben marcarse como inactivas, no se deben enviar correos a ellas. Pero algunas categorías de letras (por ejemplo, recuperación de acceso) también pueden necesitar ser enviadas a direcciones previamente marcadas como inactivas.

Dirección del remitente en un sobre SMTP (generalmente llamado sobre-desde, smtp.mailfrom o Return-Path): se enviarán mensajes a esta dirección sobre la imposibilidad de entregar una carta 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 le 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 exclusivo de cada letra;
• Una carta a esta dirección no debe generar una carta de respuesta, por ejemplo, un mensaje sobre un desbordamiento de cuadro.

Direcciones de encabezado de correo electrónico

Estas direcciones son directamente visibles para el usuario o se usan al responder una carta.

La dirección del remitente (del encabezado :) es la dirección y el nombre del remitente que se muestran en la lista de letras y al leer una carta. Verificamos que:

• Esta es una dirección amigable "legible para humanos" que identifica a la empresa.
• Contiene no solo correo electrónico, sino también el nombre del remitente.
• noreply @ es posible, pero solo si queremos enfatizar que no esperamos recibir una respuesta a la carta y que no será leída. Es mejor duplicar esta idea en el texto de la carta.
• 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.
• Las letras de la misma categoría deben tener la misma dirección; no se permite el uso de direcciones generadas automáticamente. Esto se debe al hecho de que From: se usa con mayor frecuencia por las personas para ordenar letras en carpetas mediante filtros.
• La dirección debe ser diferente (preferiblemente en diferentes subdominios) para cartas transaccionales, de marketing y urgentes (como cartas 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 De y la dirección del sobre SMTP deben estar en el mismo dominio o en subdominios del mismo dominio organizacional para poder 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.

Dirección de respuesta: las respuestas "manuales" se enviarán a esta dirección cuando el usuario responda a la carta. Es opcional: si está ausente, la dirección de From se usa para la respuesta. Verifique que Responder a:

• Se puede generar automáticamente, es decir exclusivo de la letra (le permite averiguar a qué letra llegó la respuesta).
• No debe caer en la casilla del empleado para evitar contestar llamadas, pero idealmente debe estar "envuelto" en CRM.
• Puede generar una respuesta automática CRM estándar, pero no debe generar nada superfluo, por ejemplo, mensajes sobre un desbordamiento de cuadro. 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 From, pero a veces esto asusta a los usuarios cuando responden.
• Puede estar ausente, entonces la dirección De realiza sus funciones.
• Además de la dirección, se indica el nombre del remitente.

Para abordar:

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

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 de la letra. 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 <META> de la parte HTML.

Los encabezados From:, Message-ID: y Date: deben formarse directamente en el script para enviar la carta (y según los estándares, junto con el texto de la carta) 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.

Requisitos para la estructura de la carta.

Para la parte HTML de la carta, es deseable formar una parte alternativa: texto (sin formato). También es necesario verificar la conformidad y la legibilidad de la parte de texto simple de la carta (si la hay) y la estructura general de la carta.

De acuerdo con RFC 5322, la longitud de la línea en una letra 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 las líneas en el correo electrónico es un par de CRLF (<cr> ascii 13, lf> ascii 10), que ocupa 2 octetos. Debe verificar la exactitud del terminador de cadena, ya que las letras a menudo se envían utilizando un script Unix, y en Unix, el terminador de línea es un solo carácter lf; 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, cirílico. , base64.

— «Content-Disposition: inline», , , «Content-Disposition: attachment», .
, , : , multipart- (mixed, alternative, related), multipart/mixed , multipart/related — , multipart/alternative — plain text- HTML-. , -, :

multipart/alternative
— text/plain
— text/html

, text/plain text/html multipart/related. , HTML-, - — plain-.

- :

multipart/alternative
— text/plain
— multipart/related
—— text/html
—— image/… (-)
—— image/… (-)

- Content-Disposition: inline multipart/related-.

, , , :

multipart/mixed
— multipart/alternative
—— text/plain
—— multipart/related
——— text/html
——— image/png
——— image/png
...
— application/octet-string (content-disposition: attachment)
— application/octet-string (content-disposition: attachment)
...

(multipart/related- multipart/alternative- , multipart/mixed-)

URI

URI ( src, href, ..) ( https://example.com/somepath ). (/somepath) (//example.com/somepath), , .. file://.

• ASCII- ( , ) URI percent encoding.
• , (.. URL, ), <>, . - , . href A , - . «», .
• htt://, htts:// milto:.
• http:// htts://.
• (, example.com :8080/somepath), .. .
• HTML- - (, , ..) , .. - , ; , , , ( - GET-, POST PUT).
• List-Unsubscribe, , - , .. .
• , , , (, ). . , , , , , .
• Porque URI , URI data:. URI.
• , . , , .
• - .

?

. — (XSS, Crossite scripting), (interface spoofing), DOM clobbering, / (, IP- ) .., . , . :

• ,
• / ,
• ,
• ( ),
• (.. ) ,
• HTML- ( Microsoft Exchange / Outlook RTF, - Outlook ),
• .

, - URI cid://, . , Mozilla Thunderbird cid:// .

- - .

. , URI, - , - , . : , ( , ).

:

• , , , , .
• .
• , , , . ( ). . , .
• , .
• , , .. -, - , c, , ( , , , , - ). , , .
• .
• , , , . (, - ), , , , .
• .
• :
  
  • : « » Mail.Ru, Yandex, Gmail, Rambler Outlook.com;
  • ;
  • , IMAP, , iPhone, Pixel ( Android), Samsung ( Android), MIUI ( Android-);
  • : Chrome, Firefox, Edge, Internet Explorer, Opera .;
  • ( ), Thunderbird, Outlook Apple Mail, The Bat! Opera Mail;
  • - (Exchange, Roundcube, Communigate, Zimbra, SquirrelMail) — B2B-;
  • Retina-, .
• :
  
  • , SPF/DKIM/DMARC.
  • : , .
  • : , , , (, «»).
  • : , .., .
  • .
  • .
  • .
  • , . , , - , , .
    
    
    
    
• ( ) , . , .
• , , , .. , , , «» .
• . , DKIM- - ( DNS DKIM-, ), - ( , , From, Date Message-ID) - ( , , ). «» , .

-

, , .

, , ( ). . , , .

CTR — . postmaster.mail.ru . (), . CTR < 10% — , . CTR > 30%. CTR («») . ( ). , — . , , : https://help.mail.ru/developers/mailing_rules/technical .

- . CTR . ( ). «» — 10 000 , .

: , , . « » . , .

z3apa3a s4ever . EdT 4Alexander .