Como criar e-mails e não bagunçar: dicas práticas

Um desenvolvedor, que encontrou a geração de emails pela primeira vez, quase não tem chance de escrever um aplicativo, que o fará corretamente. Cerca de 40% dos e-mails, gerados por aplicativos corporativos, estão violando alguma forma de padrão e, devido a isso, há problemas com a entrega e a exibição. Existem razões para isso: os e-mails são tecnicamente mais difíceis que a Web, e os e-mails em operação são regulados por algumas centenas de padrões, além de um número incontável de práticas geralmente aceitas (e não tanto), enquanto os clientes de e-mail são mais variados. e imprevisível que navegadores. Os testes podem melhorar significativamente a situação, mas os materiais dedicados ao teste do sistema de e-mail são praticamente inexistentes.

O Mail.ru interage regularmente com seus usuários por email. Em nossos projetos, todos os componentes responsáveis ​​por gerar emails e até correspondências individuais estão sujeitos a testes obrigatórios. Neste artigo, compartilharemos nossa experiência (aprendendo com nossos erros).

• Que tipo de e-mails existem?
  
• Quem está envolvido no processo de teste e controle?
  
• Correio e transporte de correio
  
• A interface da infraestrutura de email e os limites do aplicativo testado
  
• Definição dos parâmetros de teste
  
• Estrutura típica de um aplicativo de geração
  
• O que e quando testar
  
  • Infraestrutura de entrega
    
  • Gerando aplicativo
    
  • Modelos de email estruturais e tipográficos
    
• Requisitos básicos para verificar a infraestrutura
  
• Requisitos de autenticação
  
• Verificação do aplicativo de geração
  
  • Requisitos para endereços de email
    
    • Endereços de envelope
      
    • Endereços de cabeçalho de email
      
  • Requisitos para cabeçalhos
    
  • Requisitos para a estrutura do email
    
  • Requisitos de URI
    
  • Requisitos de layout de email
    
• Realização de testes divididos
  

Que tipo de e-mails existem?

O aplicativo pode gerar vários tipos de e-mails. Eles podem ser classificados em várias categorias. Pelo método de seleção de destinatários - pessoal / acionado - grupo seletivo. Com hora marcada: transações, marketing, serviço. Você pode definir requisitos diferentes para diferentes tipos de email e aplicar vários cenários de teste.

Os emails pessoais acionados são gerados em resposta a qualquer evento, por exemplo, ações do usuário ou alterações de status dos objetos do sistema. Eles são gerados pelo aplicativo e, portanto, são os mais interessantes em relação aos testes. Os emails acionados podem ser transacionais, de marketing e para uso do serviço. Os emails seletivos são enviados para uma seleção dinâmica de usuários, que atendem a alguma forma de critério. Os emails de grupo são enviados para um grupo permanente de destinatários, por exemplo, todos os usuários ou parceiros. Os e-mails seletivos e de grupo geralmente são para uso em marketing, e o envio desses e-mails é iniciado manualmente ou de acordo com a programação.

Os emails transacionais são gerados no processo de um usuário concluir alguma forma de ação. Esses e-mails incluem, por exemplo, faturas, tickets ou notificações de status de entrega. Os emails transacionais são sempre acionados e destinam-se a transportar informações importantes. Eles devem ser tão simples e compatíveis quanto possível, e testá-los em um grande número de clientes de email.

Os e-mails de marketing incentivam o usuário a executar uma ação, por exemplo, isso pode ser uma oferta para um desconto pessoal com base em compras anteriores. Os dados transacionais podem ser utilizados nesses emails e podem ser disparados por email ou em massa, periódicamente ou uma vez. Para esses e-mails, a eficiência é mais importante e os resultados do teste de divisão geralmente a determinam. Alguns aspectos da compatibilidade podem ser sacrificados por eficiência.

Os e-mails de marketing de grupo, por exemplo, mensagens sobre ofertas sazonais, promoções e vendas, geralmente são enviados 'manualmente' e não fazem parte do seu aplicativo, mas você pode (e deve) também aplicar princípios gerais de teste a eles.

Além disso, pode haver e-mails de serviço: notificações geradas para a equipe, para sistemas automatizados de CRM, registro no diário, auditoria ou DWH. Esses e-mails geralmente são acionados, o que significa que eles também fazem parte do aplicativo e devem ser testados.

Quem está envolvido no processo de teste e controle?

1. Engenheiro de controle de qualidade - participa de todas as etapas do processo.
   
2. Engenheiro de rede - responsável por configurar a infraestrutura de rede e a infraestrutura de entrega de mensagens. O engenheiro de rede deve estar envolvido no planejamento e nos testes de infraestrutura.
   
3. Especialista em entrega - pessoa que monitora a capacidade de entrega de emails, que também participa do monitoramento dos parâmetros técnicos e administrativos de todos os emails enviados e monitora o andamento do processo de correspondência. Ele é responsável por garantir que os emails enviados atinjam a maior porcentagem de usuários e não acabem em spam. Para esse fim, o especialista deve ter conhecimentos e contatos específicos. Se houver algum problema com a entrega de emails, é ele quem deve entender a causa provável e eliminá-la; seja eliminando obstáculos técnicos; ou alterar algo no conteúdo dos e-mails; ou tente resolver o problema com o serviço de suporte do provedor de email, ao qual os emails não chegam. Esse especialista (se houver) também deve estar envolvido na elaboração da lista de verificação e no teste de infraestrutura que gera aplicativos e e-mails. No entanto, o próprio processo de teste deve estar sob o controle do serviço de controle de qualidade.
   
4. Email-marketer - determina a eficácia dos boletins de marketing. Sob seu controle, ocorre o teste dividido para a distribuição do marketing ao público. O profissional de marketing por email também controla a segmentação da base de usuários, a composição e a frequência dos emails enviados, a 'apresentação' visual do email ao usuário.
   

Todas essas funções não são necessariamente desempenhadas por um funcionário dedicado; o papel do profissional de marketing pode ser desempenhado por um dos gerentes de produto, e o papel do especialista em entregas, por exemplo, pode ser desempenhado por um funcionário de suporte ou por um engenheiro de rede. Nas empresas iniciantes, é altamente provável que tudo isso tenha que ser tratado por uma pessoa, e eles podem se tornar um especialista em qualidade.

Correio e transporte de correio

A estrutura de email é como um enorme iceberg, e existem dois níveis nela. Existem mais de uma centena de padrões diferentes que regem os emails, mas quase todos pertencem a um desses dois níveis:

A parte subaquática de um serviço de rede de iceberg , cujo protocolo básico é o protocolo de aplicativo SMTP definido pela RFC 5321. É responsável pela entrega de emails. Um chamado envelope SMTP é formado para a entrega do email, que inclui os endereços do remetente e do destinatário do nível SMTP. Outros serviços de rede, como DNS, também são responsáveis ​​pela entrega do email. O principal componente da infraestrutura de rede é o Mail Transfer Agent (MTA). O MTA é responsável por entregar a fila de entrega de mensagens e o próprio processo de entrega aos servidores destinatários. Exemplos de MTA incluem Postfix, Sendmail, Exim, serviço SMTP da Microsoft.

Nesta parte subaquática do iceberg, que inclui os parâmetros MTA, DNS e outros parâmetros de rede, chamaremos a infraestrutura de email ou a infraestrutura de entrega de mensagens.

A ponta do iceberg - o próprio email. A estrutura básica do email é definida pelo padrão RFC 5322. O email consiste em cabeçalhos de serviço e uma ou mais partes de dados. Os dados podem estar em formato de texto sem formatação e / ou HTML ou mesmo AMP, com imagens ou anexos embutidos de quase qualquer tipo.

A interface da infraestrutura de email e os limites do aplicativo testado

A infraestrutura de email, como regra, possui uma ou várias interfaces pelas quais um email é enviado (quando entra na fila de entrega do MTA). Por exemplo, o serviço SMTP Submission, a função mail() em PHP, transferência de dados para um aplicativo de email ou sendmail externo, API para serviço interno ou externo (como GetResponse, SendPulse ou Amazon SES). Vamos considerar essas interfaces como parte da infraestrutura. Muitas vezes acontece que o Aplicativo A prepara dados para um email e uma lista de destinatários e os envia para o Aplicativo B por meio de sua API (para mala direta em massa, isso pode ser feito manualmente via interface do usuário), e o aplicativo B gera uma mensagem de email no RFC 5322 e a entrega ao MTA. Para o aplicativo A (e ao testá-lo), o aplicativo B fará parte da infraestrutura de email. A API ou interface do usuário do aplicativo B será para a interface do aplicativo A da infraestrutura de email. Embora para o Aplicativo B, a situação seja diferente e a infraestrutura de correio para ele seja aplicativos ou protocolos de rede de nível inferior.

Definição dos parâmetros de teste

Ao testar cada aplicativo, é importante selecionar todas as infraestruturas de correio usadas por ele (pode haver várias) e para cada infraestrutura destacar as interfaces usadas (também pode haver várias delas para cada infraestrutura). Para cada interface, a composição e o formato dos dados transmitidos são determinados com a maior precisão possível, por exemplo, texto de email em TEXT / HTML, texto de email em TEXT / PLAIN, assunto do email, nome do destinatário, endereço do destinatário, nome do remetente, endereço do remetente (RFC5321.From), o endereço do remetente do convector SMTP (RFC5322.mailfrom). Em seguida, um conjunto de requisitos é desenvolvido para cada parâmetro (representações, codificações, valores-limite etc.), são determinados métodos para monitorar cada um dos parâmetros (como comparar o resultado real com o esperado).

Estrutura típica de um aplicativo de geração

Como regra, o mesmo produto que estamos testando é responsável pela geração de e-mails e dados nele. Geralmente, esse é um aplicativo de servidor (mas às vezes cliente). Ele define a estrutura do email, parte dos cabeçalhos de serviço, formatos de encapsulamento de dados, representações de string e codificação de texto. Um exemplo simples desse aplicativo é o script que forma o email e chama a função mail() . Os principais elementos do aplicativo que devem ser controlados são:

• o código responsável pela geração de cabeçalhos e / ou estrutura de email, se a estrutura de email for gerada dinamicamente, e / ou modelos de email estáticos descrevendo sua estrutura;
  
• Layout HTML do email (idealmente, é uma entidade ou parte separada do modelo / layout do email, mas pode ser incorporado no código do aplicativo);
  
• substituição de dados do aplicativo em um email (ou em um modelo de email);
  
• integração do aplicativo com a infraestrutura de entrega de email, a correção dos parâmetros passados ​​para a interface da infraestrutura.
  

O que e quando testar

Quer gostemos ou não, todo o iceberg deve ser testado. Existem vários componentes principais que requerem testes:

Infraestrutura de entrega

A ênfase no teste deve ser feita em: capacidade de entrega do email; registros DNS corretos, incluindo registros PTR / FCrDNS, MX e A; Parâmetros de protocolo SMTP (HELO, use TLS); autorização de email (SPF / DKIM / DMARC); Endereços de envelope SMTP (se o aplicativo não os gerenciar); correção do processamento dos parâmetros de entrada da interface de infraestrutura; rastreamento, gravação e processamento de e-mails não entregues.

É necessário testar a infraestrutura durante a implementação inicial e sempre que forem feitas alterações na própria infraestrutura (a configuração do MTA, DNS ou alterações na rede) ou na interface para enviar um email; usando um novo domínio, rede ou API; testes adicionais são necessários se as características dos e-mails enviados, como idioma, tamanho ou número forem alteradas significativamente. Segundo a experiência, a infraestrutura tende a mudar "por si mesma", portanto testes básicos devem ser realizados periodicamente, mesmo se não houver informações sobre alterações.

É possível e necessário envolver o engenheiro de rede e o especialista em entregabilidade na elaboração do plano e nas listas de verificação para testar a infraestrutura.

Gerando aplicativo

Os endereços do envelope SMTP devem ser monitorados (se o aplicativo os controlar, ou seja, eles são transferidos para a interface - envelope de, envelope para), os valores dos cabeçalhos de serviço do email (Data, Mensagem -ID, Cancelar inscrição em lista, Submetido automaticamente etc.). Cláusula), autorização de email (DKIM / DMARC), codificação MIME (base64, impressão entre aspas), correção geral do formato do email, por exemplo, ausência de caracteres não ASCII nos cabeçalhos, composição dos dados injetados , o acionamento correto de acionadores, mecanismos de cancelamento de inscrição, mecanismos de rastreamento para gravação e coleta de estatísticas (cabeçalhos do postmaster, por exemplo, ID do Feedback ou X-Mailru-Msgtype, além de pixels de rastreamento).

É necessário testar um aplicativo durante seu desenvolvimento, quando todos os seus componentes relacionados são responsáveis ​​por gerar e armazenar alterações de dados, com alterações significativas nos modelos de email, ao alterar a infraestrutura ou interface usada, bem como dentro da estrutura do regressões gerais.

Modelos de email estruturais e tipográficos (podem fazer parte de um aplicativo de geração ou são desenvolvidos separadamente)

A estrutura do email é verificada (Tipo de Conteúdo, Disposição de Conteúdo, aninhamento de partes com várias partes do email, codificação de texto, parâmetros de sequência), o valor do destino e os cabeçalhos exibidos (De, Para, Responder a, Assunto ), a maneira como o email é exibido na lista de emails e ao ler em várias interfaces, microformatos (por exemplo, que um evento do calendário é reconhecido como um evento do calendário ou um bilhete aéreo como um bilhete aéreo), marca.

Os modelos de email devem ser testados toda vez que você fizer pelo menos as menores alterações, bem como separadamente, por exemplo, em uma situação em que os emails entram no aplicativo antes que a parte do servidor esteja pronta.

É recomendável envolver um especialista em marketing por email e um especialista em entregabilidade para compilar uma lista de verificação para testar um modelo de email.

Requisitos básicos para verificar a infraestrutura

O endereço IP selecionado para o servidor de email deve estar o mais próximo possível do endereço IP do servidor de email. É recomendável verificar usando o utilitário whois. Em particular, o endereço do remetente não deve pertencer à rede, que pode ser percebida como dinâmica; a rede selecionada deve ter contatos ativos para os quais as reclamações podem ser enviadas; a rede deve ser usada (com o status ASSIGNED in RIPE) O endereço IP deve ter um registro PTR configurado corretamente. Ele pode ser configurado de forma independente através do painel de controle de hospedagem ou com a ajuda do provedor de serviços. Um registro PTR deve apontar para o nome do host real e ainda ser significativo, resolvido de volta para o mesmo endereço IP (chamada verificação FCrDNS), não lembrar o nome do host dinâmico e não incluir um grande grupo de números ou caracteres. Um bom exemplo é mailserver.example.com.

Cada domínio usado em endereços de envelope ou cabeçalhos de email deve ter um registro MX válido apontando para um registro do host A, que, no mínimo, pode lidar com mensagens não entregues. MX não tem permissão para se referir diretamente a um endereço IP.

Controlar a passagem de SPF, DKIM, DMARC. O SPF permite que o proprietário do domínio especifique nos registros TXT uma lista de servidores autorizados a enviar e-mails com endereços de retorno nesse domínio. Ele está configurado para o endereço usado no envelope de (envelope SMTP) na seção de gerenciamento de zonas DNS do domínio. O DKIM fornece a verificação da autoria de uma mensagem ou de seu originador para um domínio específico usando tecnologias de assinatura digital, que são adicionadas ao próprio email (no cabeçalho DKIM-Signature). Normalmente, uma assinatura DKIM é configurada no nível MTA (infraestrutura). O DMARC define a política de verificar emails recebidos em um domínio específico e ações em emails que não passam na autenticação SPF ou DKIM. Ao tentar violar essa política, um relatório estruturado é fornecido com informações sobre essa tentativa. O DMARC, assim como o SPF, é publicado como um registro TXT na zona do domínio.

Verifique a capacidade de entrega de e-mails para os principais serviços postais - para Rússia Mail.Ru, Yandex, Gmail, Microsoft (Hotmail / Outlook.com / Office365), Rambler, nic.ru. Nos e-mails recebidos, você precisa verificar a exatidão do HELO; a presença e aprovação de cheques PTR / FCrDNS, SPF, DKIM e DMARC; a validade dos cabeçalhos e dados neles, em particular, o sincronismo do relógio nas datas e a exatidão dos fusos horários.


(O correio de registro quebrou a autenticação devido ao endereço de correio livre usado)

A formação de alguns parâmetros, por exemplo, autorização, capacidade de entrega e spam, é integralmente influenciada por todos os componentes, mas, para seu controle, geralmente existem ferramentas operacionais separadas - relatórios DMARC e FBL, API de serviços de postmaster, ferramentas de rastreamento de e-mail, estatísticas de entrega. Os testes devem levar em consideração o nível de implementação das ferramentas de monitoramento operacional na empresa - por exemplo, na ausência de controle operacional dos relatórios DMARC, a autorização de e-mails deve ser testada regularmente, enquanto na ausência de controle operacional da entregabilidade, onde e como os emails vão, mesmo se não houver desenvolvimento relacionado ao envio de emails.

Para testar a infraestrutura, você pode usar serviços especializados, por exemplo, mail-tester.com, mxtoolbox.com. Requisitos detalhados de infraestrutura podem ser encontrados neste artigo .


(um exemplo do registro SPF quebrado)

Requisitos de autenticação

A verificação da passagem de SPF, DKIM, DMARC geralmente é possível usando o cabeçalho Resultados da autenticação no servidor do destinatário.

Verifique a validade do registro SPF quanto à sintaxe, o limite para consultas DNS (por exemplo, usando mxtoolbox.com). Ao formar um SPF, todas as fontes de correspondência devem ser levadas em consideração (não se esqueça dos sistemas de CRM, todas as infraestruturas de entrega atualmente utilizadas, incluindo aquelas através das quais são realizadas campanhas de marketing únicas). É recomendável definir servidores permitidos para o domínio através da lista de redes ('ip4' / 'ip6'). O SPF é verificado quanto ao endereço do remetente no envelope SMTP. Verifique se o domínio do envelope SMTP (envelope-de) corresponde ao domínio do cabeçalho De. Erros comuns de SPF estão listados neste artigo (https://medium.com/hackernoon/myths-and-legends-of-spf-d17919a9e817).

Verifique o registro DNS do DKIM, a validade e a composição da assinatura DKIM. Verifique se você está usando uma chave DKIM de pelo menos 1024 bits. Modo hash recomendado de assinatura DKIM: relaxado / relaxado. Verifique se todos os cabeçalhos importantes estão assinados (de, até, assunto, data, ID da mensagem, versão MIME, tipo de conteúdo), se os cabeçalhos de rastreamento (Recebido, Entregue a, Caminho de Retorno) não estão assinados e DKIM é validado para serviços básicos de correio. Configure o encaminhamento para um dos serviços de correio para outro; O DKIM não deve "bater" nos emails encaminhados. Verifique se o domínio de assinatura DKIM corresponde ao domínio do remetente no cabeçalho 'De'.

Verifique o DMARC para obter serviços básicos de email. Verifique se há relatórios DMARC, identifique e solucione problemas de SPF e DKIM para todos os endereços IP da sua infraestrutura.

Verifique se as mensagens são entregues aos servidores externos usando criptografia (TLS). Às vezes, você pode procurar TLS pelo cabeçalho Recebido no servidor do destinatário: por exemplo, especificando o protocolo ESMTPS ou tendo parâmetros do formulário (versão = cifra TLS1_2 = bits ECDHE-RSA-AES128-GCM-SHA256 = 128/128); indica a presença de TLS.

Verificação do aplicativo de geração

Requisitos de endereço de email

Endereços de envelope

Iniciamos a verificação do aplicativo de geração com os endereços no envelope SMTP.
Endereços de envelope são endereços do nível de infraestrutura de email. Eles não são visíveis para o usuário, mas são importantes para entrega porque o endereço do envelope determina em qual caixa de correio o email entra.

O endereço do destinatário no envelope ( envelope-to , também conhecido como RCPT TO: é o endereço para o qual o email será realmente entregue.

• para todos os emails, exceto o registro, o endereço deve ser legalmente assinado e validado para envio, de acordo com os requisitos administrativos.
  
• para boletins informativos, o endereço deve ser "ativo", os endereços para os quais o email não pode ser entregue regularmente devem ser marcados como inativos; as correspondências para eles não devem ser feitas. Mas algumas categorias de e-mails (por exemplo, recuperação de acesso) também podem precisar ser enviadas para endereços marcados anteriormente como inativos.
  

Endereço do remetente em um envelope SMTP (geralmente chamado envelope-from , smtp.mailfrom , MAIL FROM: ou Return-Path ) - as mensagens serão entregues neste endereço sobre a incapacidade de enviar um email e respostas automáticas. Este endereço não é visível para o usuário. Este endereço também é usado para autorização do SPF. Verificamos que:

• O endereço está disponível;
  
• Não é o endereço do funcionário e não é redirecionado a ele para excluir respostas automáticas, mensagens sobre inacessibilidade, etc;
  
• É processado por um script que marcará os endereços de usuários inacessíveis como inativos;
  
• O endereço pode ser gerado automaticamente, ou seja, exclusivo para cada email;
  
• Um email para esse endereço não deve levar à geração de nenhum email de resposta, por exemplo, uma mensagem sobre um estouro de caixa de correio.
  

Endereços de cabeçalho de email

Esses endereços são diretamente visíveis ao usuário ou são usados ​​ao responder a um email.
Endereço do remetente (o cabeçalho From: é o endereço e o nome do remetente exibidos na lista de emails e ao ler um email. Verificamos que:

• Este é um endereço amigável legível por humanos que identifica a empresa.
  
• Ele contém não apenas um endereço de email, mas também o nome do remetente.
  
• Noreply @ é possível, mas somente se quisermos enfatizar que não esperamos receber uma resposta ao email e ele não será lido. É melhor duplicar essa ideia no texto do email.
  
• Na presença de caracteres não ASCII (por exemplo, cirílico), o nome do remetente deve ser codificado de acordo com MIME, o domínio na presença de caracteres não ASCII deve ser codificado no Punycode
  
• E-mails da mesma categoria devem ter o mesmo endereço; o uso de endereços gerados automaticamente deve ser evitado. Isso se deve ao fato de que 'De:' é mais frequentemente usado pelas pessoas para classificar emails por pastas usando filtros.
  
• O endereço deve ser diferente (de preferência em subdomínios diferentes) para emails transacionais, de marketing e urgentes (como emails do serviço de suporte). Isso também se deve ao fato de o usuário poder marcar e-mails de marketing como spam ou filtrá-los em uma pasta ilegível.
  
• O endereço From: e o endereço do envelope SMTP devem estar no mesmo domínio ou subdomínios do mesmo domínio organizacional para transmitir o SPF no DMARC.
  
• O endereço deve ser do domínio da organização. É inaceitável usar serviços de correio gratuitos e outros domínios públicos em From: pois essas correspondências não passam na autenticação SPF e DKIM na estrutura do DMARC.
  

O endereço Reply-to - respostas 'manuais' será enviado para este endereço quando um usuário responder a um email. É opcional Se estiver ausente, o endereço de 'De:' é usado para a resposta. Verifique se 'Responder para':

• Pode ser gerado automaticamente, ou seja, exclusivo para o email (permite descobrir em qual email a resposta veio).
  
• Não deve cair na caixa de correio do funcionário para evitar a resposta automática, mas, idealmente, deve ser "empacotado" no CRM.
  
• Ele pode gerar uma resposta automática padrão do CRM, mas não deve gerar nada supérfluo, por exemplo, estouro de caixa de correio ou mensagens "sob vocação". Ao gerar respostas automáticas, devem ser tomadas medidas para evitar loop, elas são listadas na RFC 3834.
  
• Pode ser de qualquer domínio que não necessariamente coincida com 'De:', mas às vezes isso assusta os usuários ao responder.
  
• Pode estar ausente, o endereço From: executa suas funções.
  
• Além do endereço, o nome do remetente é indicado.
  

O endereço To:

• Deve conter o email do destinatário (caso contrário, assusta o destinatário da mensagem e incomoda o anti-spam).
  
• Idealmente, deve conter o nome do destinatário. Mas se o nome for desconhecido ou duvidoso (por exemplo, o endereço ainda não foi confirmado), é melhor não indicá-lo (alguém pode inserir o endereço de outra pessoa com um nome ruim e o destinatário pode ficar ofendido).
  

Requisitos de cabeçalho de email

A codificação real do texto deve corresponder à indicada no cabeçalho. É aconselhável usar uma codificação em todos os cabeçalhos e partes do email. É recomendável que você use o UTF-8 como um amplamente suportado. A codificação é indicada nos cabeçalhos do tipo de conteúdo e na tag da parte HTML.

Os cabeçalhos De:, Message-ID: e Date: devem ser formados diretamente no script para enviar o email (e por padrões - junto com o texto do email) e sempre no formato correto. Se eles estiverem ausentes ou incorretamente formados, um dos servidores de trânsito poderá adicionar esses cabeçalhos, o que levará a uma violação da integridade da assinatura DKIM.

Caracteres de 8 bits nos cabeçalhos, incluindo a linha de assunto (Assunto) e os nomes dos arquivos anexados (Tipo de conteúdo e Disposição de conteúdo), devem estar ausentes; Todos os caracteres não ASCII, incluindo cirílico, devem ser codificados em citado-imprimível ou base64.


(confirmação de registro em codificação estranha)

Requisitos para a estrutura do email

Para a parte HTML do email, é desejável formar uma parte alternativa - texto (sem formatação). Também é necessário verificar a conformidade e a legibilidade da parte do texto sem formatação do email (se houver) e a estrutura geral do email.

De acordo com a RFC 5322, o comprimento de uma linha em um email não deve exceder 998 caracteres de 8 bits. Observe que em UTF-8, um personagem pode ocupar vários octetos. O terminador de linhas em um email é um par de CRLF (ascii 13, ascii 10), que leva 2 octetos. Você precisa verificar a exatidão do terminador de strings, já que os e-mails geralmente são enviados usando um script Unix e, no Unix, o terminador de strings é um caractere único - é um erro para o e-mail. Você também deve verificar se os terminadores de string quebram caracteres codificados em UTF-8: não é possível permitir a presença de um terminador de string entre dois octetos do mesmo caractere, por exemplo, símbolo cirílico. Para evitar tais situações, é necessário interromper o texto antes de formar o email ou codificar o texto em base64, base64 geralmente possui comprimento de linha fixo.

É necessário verificar a marcação correta de anexos e inline - ou seja, a correção da formação dos cabeçalhos "Content-Disposition: inline", se for uma imagem exibida dentro do email, ou "Content-Disposition: attachment" se o arquivo anexado se destina ao download.

A estrutura do email deve ser a mais simples possível: em particular, não deve haver mais de uma parte com várias partes de cada tipo (mista, alternativa, relacionada), e a multipart / mista será usada apenas se o email contiver anexos de arquivo, multipartes / related - se o HTML vier com imagens embutidas, multipart / alternativo - na presença de texto sem formatação e partes HTML. Em geral, a estrutura do email, na ausência de anexos e imagens embutidas, deve ficar assim:

multipart / alternativa
- texto / simples
- texto / html

A ordem das partes é importante, o texto / planície deve ir ANTES do texto / html ou multipart / relacionado. Isso é necessário para que a parte HTML seja exibida por padrão e somente se sua exibição estiver indisponível por algum motivo, a parte simples será exibida.

Se houver imagens embutidas no email, sua estrutura deve ficar assim:

multipart / alternativa
- texto / simples
- multipart / relacionado
- texto / html
—— imagem / ... (imagem embutida)
—— imagem / ... (imagem embutida)

As imagens embutidas devem ter Disposição de Conteúdo: embutida e estar estritamente dentro da parte multipart / relacionada.
No caso mais difícil, quando há imagens embutidas e arquivos anexados, o email tem a seguinte estrutura:

multipart / misto
- multipart / alternativa
- texto / simples
- multipart / relacionado
Texto / html
——— image / png
——— image / png
...
- application / octet-string (disposição do conteúdo: anexo)
- application / octet-string (disposição do conteúdo: anexo)
...
as peças relacionadas e multipartes e multipartes / alternativas devem ser fechadas antes dos anexos; os anexos pertencem à peça multipart / mista externa


(mensagem de registro com estrutura de peças incorreta)

Requisitos de URI

Quaisquer URIs (em src, atributos href, estilos etc.) devem conter o protocolo e o nome do host (https://example.com/somepath). Erros típicos são o uso de links relativos (/ somepath) e a falta de um protocolo (//example.com/somepath), o que é inaceitável para emails, porque neles, o protocolo padrão pode ser file:// .

• Qualquer serviço e caracteres não ASCII (em particular, cirílico) no URI devem ser codificados usando a porcentagem de codificação.
  
• Um link inserido como texto (ou seja, visível para o usuário como um URL e não como um pedaço de texto) ainda deve ser marcado com a tag <> , caso contrário, o usuário não poderá clicar nele. Alguns webmails marcam esses links por conta própria, mas esse não é um comportamento padrão. Nesse caso, o endereço href dentro de A deve corresponder ao texto do link; caso contrário, o filtro de conteúdo pode reagir a um link como uma tentativa de enganar o usuário. Isso vale especialmente a pena prestar atenção quando há "clickers" que rastreiam as transições do usuário a partir do email.
  
• É melhor limitar-se ao uso dos protocolos http:// , https:// e mailto:
  
• Com requisitos de alta segurança, você deve abandonar completamente o uso de http:// em favor de https:// .
  
• Portas não padrão não devem ser usadas (por exemplo, example.com : 8080 / somepath), pois podem não estar acessíveis ao usuário.
  
• Clicar no link dentro da parte HTML não deve levar a alterações no estado do aplicativo (assinatura, cancelamento de inscrição, cancelamento do pedido etc.) sem confirmação adicional do usuário na página, porque alguns sistemas de filtragem de conteúdo podem independentemente verifique a segurança de uma transição solicitando uma página por referência; o aplicativo de email pode mostrar a visualização da página pelo link ao passar o mouse e os navegadores modernos podem carregar a página antes que o usuário clique no link para reduzir o tempo de carregamento (no aplicativo da Web geralmente não é recomendável executar ações de modificação no Solicitação GET, todas as solicitações de modificação devem passar por POST ou PUT).
  
• Clicar no link no cabeçalho List-Unsubscribe, pelo contrário, não deve exigir nenhuma ação adicional do usuário, porque o cancelamento da inscrição por esse link geralmente é feito por programa de email ou webmail em nome do usuário. Além disso, há um novo cabeçalho List-Unsubscribe-Post introduzido pelo RFC 8058.
  
• Você não deve esperar que o usuário leia o email e siga o link no mesmo navegador em que inicia a ação que leva ao envio do email (por exemplo, registra uma conta). O link deve funcionar em qualquer outro navegador ou dispositivo móvel. Em particular, o usuário pode abrir o link sem ser autorizado ou autorizado em uma conta diferente daquela para a qual o email foi enviado.
  
• Porque o comprimento do URI pode ser limitado; você não deve usar URIs do tipo 'data:' para objetos grandes. Pelo mesmo motivo, não use URIs muito longos em hiperlinks.
  
• Você não deve usar encurtadores de links externos, isso afeta negativamente a entrega de emails. É melhor que todos os links apontem para seu domínio, pois isso reduzirá o potencial impacto negativo da reputação de outra pessoa na entrega de emails.
  
• Não coloque imagens externas em alguns serviços públicos ou hospedagem gratuita, use um serviço de hospedagem confiável ou CDN com bom desempenho e reputação.
  

(URI de imagem e âncora inválido devido à falta de especificação de protocolo)

Requisitos de layout de email

Por que é tão difícil criar e-mails?

Os clientes de email, de uma maneira ou de outra, exibem o conteúdo do usuário em sua interface. Potencialmente, isso pode levar a vários problemas de segurança - script entre sites (XSS, script Crossite), falsificação de interface, oscilação de DOM, desanonização do usuário / vazamento de informações (por exemplo, endereço IP ou cookies do usuário através de solicitações externas), etc. ., portanto, qualquer serviço de correio e aplicativo de correio possui alguma forma de proteção contra cada classe de ataques. Infelizmente, não existe uma abordagem única para organizar essa proteção. Pode ser organizado através de:

• quadros limitados isolados,
  
• filtragem de tags e / ou atributos,
  
• restrições ao posicionamento absoluto,
  
• proibição ou restrição do uso de estilos de bloco (que é fundamental para o layout adaptável),
  
• banir elementos externos por padrão (ou seja, baixar imagens externas requer permissão do usuário) ou usar um proxy para acessá-los,
  
• converter emails em HTML em outro formato intermediário (por exemplo, o Microsoft Exchange / Outlook usa RTF, o que pode tornar extremamente difícil exibir elementos corretamente no Outlook usando métodos convencionais),
  
• proibição ou restrição do uso de formulários ou de seus elementos individuais.
  

Os emails também usam elementos específicos, como imagens embutidas e URI cid:// , cujo suporte pode ser limitado. Por exemplo, o Mozilla Thunderbird não suporta cid:// para imagens de fundo.

Mesmo um email corretamente formado pode ser exibido de maneira diferente em diferentes interfaces devido às peculiaridades de sua implementação e filtragem do conteúdo do email.

Se houver erros no formato do email, o comportamento se tornará completamente imprevisível. Por exemplo, os clientes de email podem ter um comportamento diferente com URIs incorretos ou a formatação incorreta do cabeçalho é tratada de maneira diferente. Além disso, a detecção automática de codificação de texto funciona de maneira diferente se não for especificada ou especificada incorretamente. Portanto, o email deve ser visualizado em diferentes interfaces: a exibição correta do email em uma interface não significa que ele foi composto corretamente (na verdade, mesmo a exibição correta do email em todas as interfaces não garante que não haja problemas com a tela no futuro).



É necessário prestar atenção aos seguintes pontos:

• Verifique o texto do email quanto ao conteúdo semântico, exibição, ausência de erros de digitação, sintaxe, ortografia e erros lexicais.
  
• Verifique a correção da substituição dos dados do aplicativo no modelo ou layout do email.
  
• Verifique a correção dos valores, datas, números, itens de mercadorias e outras informações, levando em consideração as condições permitidas dos limites. As datas devem ter um ano (alguns usuários entram na caixa muito raramente). Um fuso horário deve estar presente no tempo. O endereço deve conter uma cidade e, em alguns casos, é necessário indicar o país.
  
• Verifique o status operacional de todos os links no email, se houver.
  
• Nos e-mails enviados antes da confirmação do endereço, incl. e-mails com um link de confirmação, não deve haver nenhum texto controlado externamente, nem mesmo o nome de usuário; caso contrário, eles podem ser usados ​​para spam (no campo exibido no e-mail, por exemplo, no nome, o texto de spam é inserido e o endereço é o endereço indicado da vítima). Por exemplo, se você pode enviar um texto obsceno no endereço do desenvolvedor em nome do seu serviço, existe um problema.
  
• Verifique a ausência de imagens externas em serviços de terceiros. Isso pode afetar a entrega e vazar informações sobre seus clientes.
  
• Verifique a disponibilidade dos contadores para envio, entrega, leitura de email e transições. Alguns deles estão localizados no próprio email (por exemplo, o contra-pixel da leitura do email), outros são rastreados pelo remetente, mas, como regra, todos estão disponíveis no painel de administração do remetente.
  
• Verifique a exatidão da categoria de assinatura e a desinscrição do usuário para esta categoria através do link no email.
  
• Verifique a aparência do email:
  
  • Versões populares da web do correio para um país de destino: os "três grandes" da Rússia são Mail.Ru, Yandex, Gmail. Você também pode adicionar o Rambler e o Outlook.com;
    
  • Aplicativos móveis dos provedores de e-mail acima;
    
  • Aplicativos móveis padrão usando IMAP, levando em conta plataformas móveis populares, para pelo menos o iPhone, Pixel (plataforma de referência Android), Samsung (a mais comum para Android), MIUI (ocupa o segundo lugar na Rússia para plataformas Android);
    
  • Vários navegadores de desktop: Chrome, Firefox, Edge, Internet Explorer, Opera, etc .;
    
  • Aplicativos de desktop (programas de email), especialmente Thunderbird, Outlook e Apple Mail, opcionalmente The Bat! e Opera Mail;
    
  • Soluções corporativas populares com uma interface da web (Exchange, talvez Roundcube, Communigate, Zimbra, SquirrelMail) - para soluções B2B;
    
  • Não se esqueça de verificar o layout nos monitores Retina e nos de baixa resolução.
    
• Durante a verificação em cada caso, você deve prestar atenção a:
  
  • Passando os cabeçalhos de autorização, SPF / DKIM / DMARC.
    
  • Velocidade de download de e-mails: ele deve carregar rapidamente e não levar tempo.
    
  • Exibindo um email na lista de emails: avatar, nome do remetente e assunto que se enquadra no snippet da mensagem, se sua categoria foi definida corretamente (por exemplo, se o pedido não se enquadra na categoria "redes sociais").
    
  • O layout do email como um todo: se o layout permanecesse consistente, houve quebra de palavras incorretas etc., inclusive ao dimensionar e redimensionar a janela.
    
  • As fontes não devem ser pequenas ou difíceis de ler.
    
  • Imagens de fundo e cores de fundo.
    
  • Combinando o livro da marca.
    
  • Facilidade de executar as ações implícitas no email. Por exemplo, se o email contiver um código de confirmação ou outras informações que talvez precisem ser armazenadas em algum lugar, ele deve não apenas ser bem lido, mas também conveniente selecioná-lo e copiá-lo, mesmo na interface móvel.
    
  
  
• Acompanhe o tamanho geral do email (incluindo imagens externas) e se ele não excede os valores razoáveis. Quanto mais pesado o tempo de carregamento, maior a probabilidade de uma pessoa ter uma reação negativa a ele.
  
• Mesmo os emails que não foram alterados devem ser verificados periodicamente, pois podem ocorrer alterações no lado do serviço postal e, por exemplo, "revelam" um problema anteriormente invisível.
  
• Alguns parâmetros devem ser controlados em todos os testes. Por exemplo, problemas na aprovação da autenticação DKIM podem ser causados ​​por problemas na infraestrutura (problemas com o DNS ou a formação de uma assinatura DKIM, erros de sincronização de horário), devido a erros no programa de geração (o endereço do remetente é formado incorretamente, caracteres incorretos em os cabeçalhos estão ausentes ou são obrigatórios, os cabeçalhos From, Date ou Message-ID foram duplicados) e devido a erros de conteúdo (terminadores de linha incorretos, linhas muito longas, endereços incorretos). Ao mesmo tempo, o email pode não "bater" e o problema pode não aparecer em nenhum serviço.
  

Realização de testes divididos

A pesquisa de marketing está além do escopo deste artigo, mas alguns pontos-chave que afetam significativamente a qualidade dos emails devem ser mencionados.

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 ).