Como enviar e-mails e não estragar: dicas práticas

O desenvolvedor, que encontrou a geração de emails pela primeira vez, praticamente não tem chance de escrever um aplicativo que faça isso corretamente. Cerca de 40% dos emails gerados por aplicativos corporativos apresentam algum tipo de violação dos padrões e, como resultado, problemas de entrega e exibição. Existem razões para isso: o e-mail é tecnicamente muito mais complicado que a web, o correio é regulado por várias centenas de padrões e um número incontável de práticas geralmente aceitas (e nem tanto), e os clientes de e-mail são diversos e imprevisíveis. O teste pode melhorar significativamente a situação, mas praticamente não há materiais dedicados ao teste do correio.

O correio Mail.Ru interage regularmente com seus usuários através de emails. Em nosso projeto, todos os componentes responsáveis ​​pela geração de emails e até mesmo correspondências únicas são submetidos a testes obrigatórios. Neste artigo, compartilharemos nossa experiência (e cheia de obstáculos).

• O que são e-mails
• Quem está envolvido no processo de teste e controle
• Correio e transporte postal
• A interface da infraestrutura de correio e os limites do aplicativo em teste
• Definição dos parâmetros testados
• Estrutura típica de um aplicativo de geração
• O que e quando testar
  
  1. Infraestrutura de entrega
  2. Gerando aplicativo
  3. Modelos de cartas estruturais e de layout
• Requisitos básicos para verificar a infraestrutura
• Requisitos de autorização
• Verificação do aplicativo de geração
  
  • Requisitos de endereço postal
  • Requisitos de cabeçalho de email
  • Requisitos para a estrutura da carta
  • Requisitos de URI
  • Requisitos de layout
• Realização de testes divididos

O que são e-mails

O aplicativo pode gerar vários tipos de letras. Eles podem ser classificados em várias categorias. Pelo método de seleção de destinatários: gatilho - seletivo - grupo. Com hora marcada: transacional - marketing - serviço. Diferentes tipos de letras podem ter requisitos diferentes e aplicar scripts de teste diferentes.

Os emails de acionamento são gerados em resposta a qualquer evento, por exemplo, ações do usuário ou alterações no status de qualquer objeto do sistema. Eles são gerados pelo aplicativo e, portanto, os mais interessantes em termos de teste. Os emails de acionamento podem ser transacionais e de marketing.

Cartas personalizadas são enviadas para uma seleção dinâmica de usuários que correspondem a qualquer critério.

As mensagens de grupo são enviadas para um grupo conhecido de destinatários, por exemplo, para todos os usuários ou parceiros. As cartas seletivas e de grupo costumam ser comercializadas, o envio dessas cartas é iniciado manualmente ou de acordo com uma programação.

Letras transacionais são geradas quando um usuário executa uma ação. Essas cartas incluem, por exemplo, faturas, tickets ou notificações de status de entrega, cartas com um código de recuperação de acesso etc. Os emails transacionais são sempre acionados. A compatibilidade máxima é importante para eles, o que significa que eles devem ser o mais simples possível e precisam ser testados em um grande número de clientes.

As cartas de marketing incentivam o usuário a executar qualquer ação, por exemplo, pode ser uma oferta de descontos individuais com base em compras anteriores. Nessas cartas, os dados transacionais podem ser usados, tanto podem ser acionados quanto em massa - periódicos ou únicos. Para essas cartas, a eficiência é mais importante, geralmente é determinada pelos resultados de um teste de divisão. Alguns aspectos da compatibilidade podem ser sacrificados por eficiência.

As cartas de marketing do grupo, por exemplo, mensagens sobre ofertas sazonais, promoções e vendas, geralmente são enviadas "manualmente" e não fazem parte do seu aplicativo, mas você pode (e deve) aplicar princípios gerais de teste a elas.

Além disso, pode haver cartas de serviço geradas pelos funcionários para sistemas automatizados ou automatizados de CRM, registro no diário, auditoria ou DWH. Essas letras são acionadas, o que significa que também fazem parte do aplicativo e devem ser testadas.

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 pela configuração da infraestrutura de rede e de mensagens. Um engenheiro de rede deve estar envolvido no planejamento de testes de infraestrutura.
3. Um especialista em entregabilidade é uma pessoa que monitora a entrega de cartas, que também participa do monitoramento dos parâmetros técnicos e administrativos de todas as mensagens enviadas e do progresso do processo de correspondência. Ele é responsável por garantir que as cartas enviadas atinjam a porcentagem máxima possível de usuários e não caiam em spam. Por isso, o especialista deve ter certos conhecimentos e contatos. Se surgirem problemas com a entrega de cartas, é ele quem deve entender a causa provável e eliminá-la: eliminando obstáculos técnicos; ou mudar algo no conteúdo das letras; ou resolver o problema com o serviço de suporte do provedor de correio, para o qual as cartas não chegam. Esse especialista (se houver) também deve estar envolvido na preparação de uma lista de verificação e no teste da infraestrutura que gera aplicativos e cartas. No entanto, o próprio processo de teste deve estar sob o controle do serviço de controle de qualidade.
4. E-mail marketing - determina a eficácia das campanhas de marketing. Sob seu controle, é realizado o teste dividido para o público necessário para as correspondências de marketing. O profissional de marketing de email também controla a segmentação da base de usuários, a composição e a frequência dos emails enviados e a "apresentação" visual do email ao usuário.

Todas essas funções não são necessariamente desempenhadas por um funcionário separado: o papel de um profissional de marketing pode ser desempenhado por um dos gerentes de produto e o papel de um especialista em entregabilidade por, por exemplo, um funcionário de suporte ou engenheiro de rede. E em startups com um alto grau de probabilidade, tudo isso terá que ser feito por uma pessoa, e elas podem se tornar um especialista em qualidade.

Correio e transporte postal

A estrutura do correio é semelhante a um enorme iceberg e possui dois níveis. Existem mais de cem padrões diferentes que regem o correio, mas quase todos pertencem a um desses dois níveis:

A parte subaquática do iceberg é um serviço de rede cujo protocolo básico é o protocolo de aplicativo SMTP, definido pela RFC 5321. É responsável pela entrega de cartas. Para entregar a carta, é formado um chamado envelope SMTP, que inclui os endereços do remetente e do destinatário do nível SMTP. Outros serviços de rede, como o DNS, também são responsáveis ​​pela entrega da carta. O principal componente da infraestrutura de rede é o Mail Transfer Agent, ou a abreviação MTA é usada com mais frequência. O MTA é responsável por manipular a fila de entrega de mensagens e o processo de entrega para os servidores destinatários. Exemplos de MTA são 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 correio ou infraestrutura de entrega de mensagens.

A superfície do iceberg é a própria letra. A estrutura básica da carta é definida na RFC 5322. A carta consiste em cabeçalhos de serviço e uma ou mais partes com dados. Os dados podem conter texto em texto sem formatação e / ou HTML, imagens embutidas ou anexos de quase qualquer tipo.

A interface da infraestrutura de correio e os limites do aplicativo em teste

A infraestrutura de correio, por regra, possui uma ou mais interfaces com as quais uma carta é enviada (entra na fila de entrega do MTA). Por exemplo, o serviço de Envio SMTP, a função mail() em PHP, a transferência de dados para um aplicativo de email ou sendmail externo, a API de serviços internos ou externos (por exemplo, GetResponse, SendPulse ou Amazon SES). Vamos considerar essas interfaces como parte da infraestrutura. Muitas vezes, há uma situação em que o aplicativo A prepara dados para uma carta e uma lista de destinatários e os transfere para o aplicativo B por meio de sua API (para marketing de mala direta, isso pode ser feito manualmente através da interface do usuário - UI), e o aplicativo B já gera uma mensagem de correio em Formato RFC 5322 e de alguma forma o enfileira para entrega do MTA. Do ponto de vista do aplicativo A (e ao testá-lo), o aplicativo B fará parte da infraestrutura de correio. A API ou interface do usuário do aplicativo B será a interface de infraestrutura de email do aplicativo A. Embora, do ponto de vista do 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 testados

Ao testar cada aplicativo, é importante destacar todas as infraestruturas de correio usadas por ele (pode haver várias) e, para cada infraestrutura, selecione as interfaces usadas (também pode haver várias para cada infraestrutura). Para cada interface, a composição e o formato dos dados transferidos para ele são determinados com a maior precisão possível, por exemplo: texto da mensagem em TEXT / HTML, texto da mensagem em TEXT / PLAIN, assunto da mensagem, nome do destinatário, endereço do destinatário, endereço do destinatário, nome do remetente, endereço do remetente da carta (RFC5321. ), o endereço do remetente do condutor SMTP (RFC5322.mailfrom). Em seguida, um conjunto de requisitos é desenvolvido para cada parâmetro (representações, codificações, valores-limite, etc.), os métodos de controle para cada um dos parâmetros são determinados (de que maneira o resultado real pode ser comparado ao esperado).

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

Como regra, o produto que estamos testando é responsável por gerar a letra e os dados nela. Geralmente, esse é um aplicativo de servidor (mas às vezes cliente). Ele define a estrutura da carta, parte dos cabeçalhos do serviço, formatos para encapsulamento de dados, apresentação de strings e codificação de texto. Um exemplo simples desse aplicativo é um script que forma uma carta e chama a função mail() .

Os principais elementos do aplicativo que precisam ser controlados:

• código responsável por gerar cabeçalhos e / ou estrutura de letras se a estrutura de letras for gerada dinamicamente e / ou um modelo de letra estático descrevendo sua estrutura;
• layout da parte HTML da carta (idealmente, essa é uma entidade ou parte separada do modelo / layout da carta, mas pode ser costurada no código do aplicativo);
• Substituição de dados do aplicativo em uma carta (ou em um modelo de carta);
• integração de aplicativos com a infraestrutura de entrega de correspondência, a correção dos parâmetros transferidos para a interface da infraestrutura.

O que e quando testar

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

1. Infraestrutura de entrega

A ênfase nos testes deve ser colocada em: entrega de cartas; a correção dos registros DNS, incluindo registros PTR / FCrDNS, MX e A; Configurações do protocolo SMTP (HELO, usando TLS); autorização por carta (SPF / DKIM / DMARC); Endereços de envelope SMTP (se não forem gerenciados pelo aplicativo); processamento correto dos parâmetros de entrada da interface de infraestrutura; rastreamento, contabilidade e processamento de cartas 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 o envio de cartas; Usando um novo domínio, rede ou API Altere significativamente as características dos emails enviados, como idioma, tamanho ou quantidade. Segundo a experiência, a infraestrutura tende a mudar sem declarar guerra; portanto, testes básicos devem ser realizados periodicamente, mesmo se não houver informações sobre alterações.

Um engenheiro de rede e um especialista em entregabilidade podem e devem estar envolvidos na preparação do plano e nas listas de verificação dos testes de infraestrutura.

2. O aplicativo gerador

Você deve controlar os endereços do envelope SMTP (se eles forem controlados pelo aplicativo, ou seja, transferidos para a interface - envelope de, envelope para), os valores dos cabeçalhos das mensagens de serviço (Data, ID da mensagem, Cancelar inscrição na lista, Submetido automaticamente, etc.) p.), autorização de carta (DKIM / DMARC), codificações MIME (base64, impressão entre aspas), correção geral do formato da carta, por exemplo, ausência de caracteres não ASCII nos cabeçalhos, composição dos dados substituídos, acionamento correto dos gatilhos, mecanismos de cancelamento de assinatura, mecanismos de rastreamento coleção de cartas e estatísticas (cabeçalhos do postmaster, por exemplo, Feedback-ID ou X-Mailru-Msgtype, além de pixels de rastreamento) .

Você precisa testar o aplicativo durante seu desenvolvimento, ao alterar todos os seus componentes relacionados, responsáveis ​​por gerar e armazenar dados, com alterações significativas nos modelos de cartas, ao alterar a infraestrutura usada ou sua interface, bem como no quadro de regressões gerais.

3. Modelos de cartas estruturais e de layout (podem fazer parte de um aplicativo de geração ou são desenvolvidos separadamente)

A estrutura da mensagem é verificada (Tipo de Conteúdo, Disposição de Conteúdo, aninhamento das partes de várias partes da carta, codificação de texto, parâmetros de sequência), valor do destino e cabeçalhos exibidos (De, Para, Resposta a Assunto), a mensagem é exibida na lista de letras e ao ler em várias interfaces, microformatos (por exemplo, que um evento do calendário é reconhecido como um evento do calendário ou uma passagem aérea como passagem aérea), marca.

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

É recomendável que você use um profissional de marketing por e-mail e um especialista em entregabilidade para escrever uma lista de verificação para testar um modelo de carta.

Requisitos básicos para verificar a infraestrutura

O endereço IP selecionado para o servidor de email deve ser o mais semelhante possível ao 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 a uma rede que possa ser percebida como dinâmica; A rede selecionada deve ter contatos válidos para os quais você pode enviar reclamações; a rede deve ser usada (tem o status ATRIBUÍDO no 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 usando o serviço de suporte do provedor. O registro PTR deve apontar para o nome real do host e, ao mesmo tempo, ser significativo, resolver novamente para o mesmo endereço IP (a 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 mensagens deve ter um registro MX válido apontando para um registro A do host, que, no mínimo, pode processar mensagens sobre falha na entrega. Para MX, não é permitido 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 no registro TXT uma lista de servidores com o direito de enviar mensagens de email 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 zona DNS do domínio. O DKIM fornece a verificação da autoria de uma mensagem ou de seu remetente pertencente a um domínio específico usando tecnologias de assinatura digital, que são adicionadas à própria mensagem (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 cartas que não passam na autenticação SPF ou DKIM. Quando você tenta violar essa política, chega um relatório estruturado com informações sobre essa tentativa. O DMARC, assim como o SPF, é publicado como um registro TXT na zona do domínio.

Verifique a entrega de cartas aos principais serviços postais - para Rússia, Mail.Ru, Yandex, GMail, Microsoft (Hotmail / Outlook.com / Office365), Rambler, nic.ru. Nas letras, você precisa verificar a exatidão do HELO; disponibilidade e aprovação de cheques PTR / FCrDNS, SPF, DKIM e DMARC; a validade dos cabeçalhos e os dados neles contidos, em particular, o sincronismo das horas nas datas e a exatidão dos fusos horários.



A formação de certos parâmetros, por exemplo, autorização, capacidade de entrega e envio de spam, é influenciada integralmente por todos os componentes; no entanto, geralmente existem ferramentas operacionais separadas para controlá-los - relatórios DMARC e FBL, APIs de serviço do postmaster, ferramentas de rastreamento de email e 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 monitoramento operacional dos relatórios DMARC, você deve testar regularmente a autorização por correio, na ausência de monitoramento operacional da entregabilidade - verificar regularmente como e onde as cartas são recebidas, mesmo se não houver desenvolvimento relacionado ao envio de cartas não conduzido.

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

Requisitos de autorizaçã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 usadas, 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 .

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 o DKIM é validado para serviços postais básicos. Configure o encaminhamento para um dos serviços de correio para outro; o DKIM não deve "bater" nas cartas encaminhadas. 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 correio. 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 verificar o TLS no cabeçalho Recebido no servidor do destinatário: por exemplo, especificando o protocolo ESMTPS ou a presença de parâmetros no 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 postal

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 correio. Eles não são visíveis para o usuário, mas são importantes para a entrega, porque em qual caixa de correio a carta é recebida, é determinada precisamente pelo endereço do envelope.

O endereço do destinatário em um envelope (envelope para, também conhecido como RCPT TO :) é o endereço no qual a carta será realmente entregue.

• para todas as cartas, exceto para registro, o endereço deve ser legalmente assinado e validado para envio, de acordo com os requisitos administrativos.
• para boletins, o endereço deve ser “ativo”, os endereços para os quais as cartas não podem ser entregues regularmente devem ser marcados como inativos, e não devem ser enviadas correspondências. Mas algumas categorias de cartas (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-de, smtp.mailfrom ou Return-Path) - as mensagens serão entregues neste endereço sobre a incapacidade de entregar uma carta 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:

• endereço está disponível;
• Não é o endereço do funcionário e não é redirecionado para 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 letra;
• Uma carta para esse endereço não deve levar à geração de nenhuma carta de resposta, por exemplo, uma mensagem sobre um estouro de caixa.

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 uma carta.

Endereço do remetente (De :) é o endereço e o nome do remetente exibidos na lista de letras e ao ler uma carta. Verificamos que:

• Este é um endereço amigável "legível por humanos" que identifica a empresa.
• Ele contém não apenas email, mas também o nome do remetente.
• noreply @ é possível, mas apenas se quisermos enfatizar que não esperamos receber uma resposta à carta e ela não será lida. É melhor duplicar essa idéia no texto da carta.
• 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.
• Cartas da mesma categoria devem ter o mesmo endereço; o uso de endereços gerados automaticamente não é permitido. Isso se deve ao fato de que De: é mais frequentemente usado pelas pessoas para classificar letras em pastas usando filtros.
• O endereço deve ser diferente (de preferência em subdomínios diferentes) para cartas transacionais, de marketing e urgentes (como cartas 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 De e o endereço do envelope SMTP devem estar no mesmo domínio ou nos subdomínios do mesmo domínio organizacional para passar 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 de correio público em From, pois essas correspondências não passam na autenticação SPF e DKIM na estrutura do DMARC.

Endereço de resposta - as respostas “manuais” serão enviadas para esse endereço quando o usuário responder à carta. É opcional: se estiver ausente, o endereço de De será usado para a resposta. Verifique se Responder para:

• Pode ser gerado automaticamente, ou seja, exclusivo da letra (permite descobrir a qual letra a resposta veio).
• Não deve cair na caixa do funcionário para evitar atender chamadas, mas, idealmente, deve ser "encapsulado" no CRM.
• Ele pode gerar uma resposta automática padrão do CRM, mas não deve gerar nada supérfluo, por exemplo, mensagens sobre um estouro de caixa. 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, então o endereço De executa suas funções.
• Além do endereço, o nome do remetente é indicado.

Para endereçar:

• Ele deve conter o email do destinatário (caso contrário, assusta o destinatário da mensagem e protege 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 se ofender com você).

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 da carta. É recomendável que você use o UTF-8 como um amplamente suportado. A codificação é indicada nos cabeçalhos Content-Type e na tag <META> da parte HTML.

Os cabeçalhos From:, Message-ID: e Date: devem ser formados diretamente no script para o envio da carta (e pelos padrões - junto com o texto da carta) 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.

Requisitos para a estrutura da carta

Para a parte HTML da carta, é 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 da carta (se houver) e a estrutura geral da carta.

De acordo com a RFC 5322, o comprimento da linha em uma letra não deve exceder 998 caracteres de 8 bits. Observe que em UTF-8, um personagem pode ocupar vários octetos. O terminador das linhas no email é um par de CRLF (<cr> ascii 13, lf> ascii 10), que ocupa 2 octetos. Você precisa verificar a exatidão do terminador de strings, pois as cartas geralmente são enviadas usando um script Unix e, no Unix, o terminador de linha é um único caractere lf - esse é um erro no email. 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, 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 .