Comment faire des e-mails et ne pas gâcher: conseils pratiques

Un développeur, qui a rencontré pour la première fois la génération d'e-mails, n'a presque aucune chance d'écrire une application, qui le fera correctement. Environ 40% des e-mails, générés par des applications d'entreprise, violent une certaine forme de norme, et à cause de cela, il y a des problèmes de livraison et d'affichage. Il y a des raisons à cela: les e-mails sont techniquement plus difficiles que le Web, et le fonctionnement des e-mails est réglementé par quelques centaines de normes, ainsi qu'un nombre incalculable de pratiques généralement acceptées (et pas autant), tandis que les clients de messagerie sont plus variés et imprévisible que les navigateurs. Les tests peuvent améliorer considérablement la situation, mais le matériel dédié au test du système de messagerie électronique est pratiquement inexistant.

Mail.ru interagit régulièrement avec ses utilisateurs par e-mail. Dans nos projets, tous les composants responsables de la génération des emails et même des mailings individuels, sont soumis à des tests obligatoires. Dans cet article, nous partagerons notre expérience (apprendre de nos erreurs).

• Quels types d'e-mails existe-t-il?
  
• Qui est impliqué dans le processus de test et de contrôle?
  
• Envoi et transport du courrier
  
• L'interface de l'infrastructure de messagerie et les limites de l'application testée
  
• Définition des paramètres de test
  
• Structure typique d'une application génératrice
  
• Quoi et quand tester
  
  • Infrastructure de livraison
    
  • Génération d'une application
    
  • Modèles d'e-mails structurels et typographiques
    
• Exigences de base pour vérifier l'infrastructure
  
• Exigences d'authentification
  
• Vérification de l'application génératrice
  
  • Conditions requises pour les adresses e-mail
    
    • Adresses d'enveloppe
      
    • Adresses d'en-tête de messagerie
      
  • Exigences pour les en-têtes
    
  • Conditions requises pour la structure de l'e-mail
    
  • Exigences d'URI
    
  • Exigences de mise en page des e-mails
    
• Réalisation de tests fractionnés
  

Quels types d'e-mails existe-t-il?

L'application peut générer différents types d'e-mails. Ils peuvent être classés en plusieurs catégories. Par la méthode de sélection des destinataires - personnels / déclenchés - groupe sélectif. Sur rendez-vous: transactions-marketing-service. Vous pouvez définir différentes exigences pour différents types de courrier électronique et appliquer différents scénarios de test.

Les e-mails personnels déclenchés sont générés en réponse à tout événement, par exemple, les actions de l'utilisateur ou les changements d'état des objets système. Ils sont générés par l'application et sont donc les plus intéressants pour les tests. Les e-mails déclenchés peuvent être transactionnels, marketing et à usage de service. Des e-mails sélectifs sont envoyés à une sélection dynamique d'utilisateurs, qui répondent à une forme de critère. Les e-mails de groupe sont envoyés à un groupe permanent de destinataires, par exemple, tous les utilisateurs ou partenaires. Les e-mails sélectifs et de groupe sont souvent à des fins marketing, et l'envoi de tels e-mails est démarré manuellement ou selon un calendrier.

Les e-mails transactionnels sont générés au cours d'un utilisateur effectuant une certaine forme d'action. Ces e-mails incluent, par exemple, des factures, des tickets ou des notifications d'état de livraison. Les e-mails transactionnels sont toujours déclenchés et sont destinés à véhiculer des informations importantes. Ils doivent être aussi simples et compatibles que possible, et les tester doit être effectué sur un grand nombre de clients de messagerie.

Les e-mails marketing encouragent l'utilisateur à entreprendre une action, par exemple, cela peut être une offre de remise personnelle basée sur des achats précédents. Les données transactionnelles peuvent être utilisées dans ces e-mails et peuvent être déclenchées par e-mails ou en masse, périodiques ou ponctuelles. Pour ces e-mails, l'efficacité est plus importante et les résultats du split-test le déterminent généralement. Certains aspects de la compatibilité peuvent être sacrifiés pour l'efficacité.

Les e-mails de marketing de groupe, par exemple, les messages sur les offres saisonnières, les promotions et les ventes, sont souvent envoyés `` manuellement '' et ne font pas partie de votre application, mais vous pouvez (et devez) également leur appliquer des principes de test généraux.

Il peut également y avoir des e-mails de service: notifications générées pour le personnel, pour les systèmes CRM automatisés, journalisation, audit ou DWH. Ces e-mails sont généralement des e-mails déclenchés, ce qui signifie qu'ils font également partie de l'application et doivent être testés.

Qui est impliqué dans le processus de test et de contrôle?

1. Ingénieur AQ - participe à toutes les étapes du processus.
   
2. Ingénieur réseau - responsable de la configuration de l'infrastructure réseau et de l'infrastructure de livraison des messages. L'ingénieur réseau doit être impliqué dans la planification et les tests d'infrastructure.
   
3. Spécialiste de la livraison - personne qui surveille la délivrabilité des courriels, qui participe également au suivi des paramètres techniques et administratifs de tous les courriels envoyés et surveille la progression du processus d'envoi. Il est chargé de s'assurer que les e-mails envoyés atteignent le pourcentage le plus élevé d'utilisateurs et ne se retrouvent pas dans le spam. Pour cela, le spécialiste doit avoir des connaissances et des contacts spécifiques. S'il y a des problèmes avec la livraison des courriels, c'est lui qui doit comprendre la cause probable et l'éliminer; soit en éliminant les obstacles techniques; ou changer quelque chose dans le contenu des e-mails; ou essayez de résoudre le problème avec le service d'assistance du fournisseur de messagerie, auquel les e-mails ne parviennent pas. Un tel spécialiste (le cas échéant) devrait également être impliqué dans l'élaboration de la liste de contrôle et le test des infrastructures générant des applications et des e-mails. Cependant, le processus de test lui-même devrait être sous le contrôle du service QA.
   
4. Email-marketer - détermine l'efficacité des newsletters marketing. Sous son contrôle, le split-testing pour la distribution de marketing au public se produit. Le marketing par e-mail contrôle également la segmentation de la base d'utilisateurs, la composition et la fréquence des e-mails envoyés, la «présentation» visuelle de l'e-mail à l'utilisateur.
   

Tous ces rôles ne sont pas nécessairement exécutés par un employé dévoué; le rôle de l'agent de commercialisation peut être effectué par l'un des chefs de produit, et le rôle du spécialiste de la livraison, par exemple, peut être joué par un employé de support ou un ingénieur réseau. Dans les start-ups, il est très probable que tout cela devra être traité par une seule personne, et il se peut qu’elles soient un spécialiste de la qualité.

Envoi et transport du courrier

La structure de l'e-mail est comme un énorme iceberg, et il y a deux niveaux. Il existe plus d'une centaine de normes différentes régissant les e-mails, mais presque toutes appartiennent à l'un de ces deux niveaux:

La partie sous-marine d'un service de réseau iceberg , dont le protocole de base est le protocole d'application SMTP défini par la RFC 5321. Il est responsable de la livraison des courriels. Une enveloppe dite SMTP est formée pour la remise de l'e-mail, qui comprend les adresses de l'expéditeur et du destinataire du niveau SMTP. D'autres services réseau, tels que DNS, sont également responsables de la livraison de l'e-mail. Le composant principal de l'infrastructure réseau est l'agent de transfert de courrier (MTA). Le MTA est responsable de la remise de la file d'attente de remise des messages et du processus de remise lui-même aux serveurs destinataires. Les exemples MTA incluent Postfix, Sendmail, Exim, le service Microsoft SMTP.

Cette partie sous-marine de l'iceberg, qui comprend le MTA, les paramètres DNS et d'autres paramètres de réseau, nous appellerons l'infrastructure de messagerie ou l'infrastructure de livraison de messages.

La pointe de l'iceberg - l'e-mail lui-même. La structure de base de l'e-mail est définie par la norme RFC 5322. L'e-mail se compose d'en-têtes de service et d'une ou plusieurs parties de données. Les données peuvent être au format texte brut et / ou HTML ou même AMP, avec des images en ligne ou des pièces jointes de presque n'importe quel type.

L'interface de l'infrastructure de messagerie et les limites de l'application testée

L'infrastructure de messagerie, en règle générale, possède une ou plusieurs interfaces via lesquelles un e-mail est envoyé (lorsqu'il entre dans la file d'attente de remise MTA). Par exemple, le service de soumission SMTP, la fonction mail() en PHP, le transfert de données vers une application de messagerie externe ou sendmail, une API pour un service interne ou externe (comme GetResponse, SendPulse ou Amazon SES). Nous considérerons ces interfaces comme faisant partie de l'infrastructure. Il arrive souvent que l'application A prépare des données pour un e-mail et une liste de destinataires, puis les envoie à l'application B via son API (pour le marketing de publipostage, cela peut être fait manuellement via l'interface utilisateur - UI), et l'application B génère un message électronique dans RFC 5322 et le remet au MTA. Pour l'application A (et lors de son test), l'application B fera partie de l'infrastructure de messagerie. L'API ou l'interface utilisateur de l'application B sera pour l'interface A de l'application de l'infrastructure de messagerie. Bien que pour l'application B, la situation sera différente et l'infrastructure de messagerie pour elle sera constituée d'applications ou de protocoles réseau de niveau inférieur.

Définition des paramètres de test

Lors du test de chaque application, il est important de sélectionner toutes les infrastructures de messagerie utilisées par celle-ci (il peut y en avoir plusieurs), et pour chaque infrastructure de distinguer les interfaces utilisées (il peut également y en avoir plusieurs pour chaque infrastructure). Pour chaque interface, la composition et le format des données qui lui sont transmises sont déterminés aussi précisément que possible, par exemple, texte de l'e-mail en TEXT / HTML, texte de l'e-mail en TEXT / PLAIN, objet de l'e-mail, nom du destinataire, adresse du destinataire, nom de l'expéditeur, adresse de l'expéditeur (RFC5321.From), l'adresse de l'expéditeur du convecteur SMTP (RFC5322.mailfrom). Ensuite, un ensemble d'exigences est développé pour chaque paramètre (représentations, codages, valeurs limites, etc.), des méthodes de surveillance de chacun des paramètres sont déterminées (comment comparer le résultat réel avec le résultat attendu).

Structure typique d'une application génératrice

En règle générale, le même produit que nous testons est responsable de la génération d'e-mails et de données qu'il contient. Il s'agit généralement d'une application serveur (mais parfois cliente). Il définit la structure de l'e-mail, une partie des en-têtes de service, les formats d'encapsulation des données, les représentations de chaînes et l'encodage de texte. Un exemple simple d'une telle application est le script qui forme l'e-mail et appelle la fonction mail() . Les principaux éléments de l'application à contrôler sont:

• le code responsable de la génération des en-têtes et / ou de la structure des e-mails, si la structure des e-mails est générée dynamiquement, et / ou des modèles d'e-mails statiques décrivant sa structure;
  
• Disposition HTML de l'e-mail (idéalement, il s'agit d'une entité ou d'une partie distincte du modèle / de la mise en page de l'e-mail, mais elle peut être intégrée dans le code de l'application);
  
• substitution des données d'application dans un e-mail (ou dans un modèle d'e-mail);
  
• intégration de l'application avec l'infrastructure de livraison des e-mails, la justesse des paramètres passés à l'interface de l'infrastructure.
  

Quoi et quand tester

Que cela nous plaise ou non, tout l'iceberg doit être testé. Il existe plusieurs composants principaux qui nécessitent des tests:

Infrastructure de livraison

L'accent doit être mis sur les tests: délivrabilité des e-mails; les enregistrements DNS corrects, y compris les enregistrements PTR / FCrDNS, MX et A; Paramètres du protocole SMTP (HELO, utilisez TLS); autorisation par e-mail (SPF / DKIM / DMARC); Adresses d'enveloppe SMTP (si l'application ne les gère pas); exactitude du traitement des paramètres d'entrée de l'interface d'infrastructure; suivi, enregistrement et traitement des e-mails non livrés.

Il est nécessaire de tester l'infrastructure lors de la mise en œuvre initiale et chaque fois que des modifications sont apportées à l'infrastructure elle-même (la configuration du MTA, du DNS ou des modifications du réseau) ou à l'interface d'envoi d'un e-mail; en utilisant un nouveau domaine, réseau ou API; des tests supplémentaires sont nécessaires si les caractéristiques des e-mails envoyés, telles que leur langue, leur taille ou leur nombre, sont considérablement modifiées. Selon l'expérience, l'infrastructure a tendance à changer «par elle-même», de sorte que des tests de base devraient être effectués périodiquement, même en l'absence d'informations sur les changements.

Il est possible et nécessaire d'impliquer l'ingénieur réseau et le spécialiste de la délivrabilité dans l'élaboration du plan et des check-lists de test de l'infrastructure.

Génération d'une application

Les adresses de l'enveloppe SMTP doivent être surveillées (si l'application les contrôle, c'est-à-dire qu'elles sont transférées vers l'interface - enveloppe-de, enveloppe-à), les valeurs des en-têtes de service de l'e-mail (Date, Message -ID, Liste-Désabonnement, Soumission automatique, etc.). Clause), autorisation de courrier électronique (DKIM / DMARC), encodage MIME (base64, quoted-printable), exactitude générale du format de courrier électronique, par exemple, l'absence de caractères non ASCII dans les en-têtes, la composition des données injectées , le déclenchement correct des déclencheurs, les mécanismes de désabonnement, les mécanismes de suivi écrivant et collectant des statistiques (en-têtes de postmaster, par exemple, Feedback-ID ou X-Mailru-Msgtype, ainsi que les pixels de suivi).

Il est nécessaire de tester une application au cours de son développement, lorsque tous ses composants liés qui sont responsables de la génération et du stockage des données changent, avec des changements importants dans les modèles de courrier électronique, lors du changement de l'infrastructure utilisée ou de l'interface avec celle-ci, ainsi que dans le cadre de régressions générales.

Modèles d'e-mails structurels et typographiques (peuvent faire partie d'une application génératrice ou sont développés séparément)

La structure de l'e-mail est vérifiée (Content-Type, Content-Disposition, imbrication de plusieurs parties de l'e-mail, encodage de texte, paramètres de chaîne), la valeur de la cible et les en-têtes affichés (From, To, Reply-to, Subject ), la façon dont le courrier électronique est affiché dans la liste des courriels et lors de la lecture dans diverses interfaces, les microformats (par exemple, qu'un événement de calendrier est reconnu comme un événement de calendrier ou un billet d'avion comme un billet d'avion), l'image de marque.

Les modèles d'e-mails doivent être testés chaque fois que vous effectuez au moins les moindres modifications, ainsi que séparément, par exemple, dans une situation où des e-mails pénètrent dans l'application avant que la partie serveur ne soit prête.

Il est recommandé d'impliquer un spécialiste du marketing par e-mail et un spécialiste de la délivrabilité pour compiler une liste de contrôle pour tester un modèle de courrier électronique.

Exigences de base pour vérifier l'infrastructure

L'adresse IP sélectionnée pour le serveur de messagerie doit être aussi proche que possible de l'adresse IP du serveur de messagerie. Il est recommandé de le vérifier à l'aide de l'utilitaire whois. En particulier, l'adresse de l'expéditeur ne doit pas appartenir au réseau, ce qui peut être perçu comme dynamique; le réseau sélectionné doit avoir des contacts actifs auxquels les plaintes peuvent être envoyées; le réseau doit être utilisé (avoir le statut ASSIGNÉ dans RIPE) L'adresse IP doit avoir un enregistrement PTR correctement configuré. Il peut être configuré indépendamment via le panneau de contrôle d'hébergement ou avec l'aide du fournisseur de services. Un enregistrement PTR doit pointer vers le véritable nom d'hôte et toujours être significatif, résolu à la même adresse IP (soi-disant vérification FCrDNS), ne pas rappeler le nom de l'hôte dynamique et ne pas inclure un grand groupe de chiffres ou de caractères. Un bon exemple est mailserver.example.com.

Chaque domaine utilisé dans les adresses d'enveloppe ou les en-têtes de courrier électronique doit avoir un enregistrement MX valide pointant vers un enregistrement hôte A, qui, au minimum, peut gérer les messages non distribuables. MX n'est pas autorisé à se référer directement à une adresse IP.

Contrôlez le passage de SPF, DKIM, DMARC. SPF permet au propriétaire du domaine de spécifier dans les enregistrements TXT une liste de serveurs autorisés à envoyer des e-mails avec des adresses de retour dans ce domaine. Il est configuré pour l'adresse utilisée dans l'enveloppe-de (enveloppe SMTP) dans la section de gestion des zones DNS du domaine. DKIM fournit la vérification de la paternité d'un message ou de son expéditeur à un domaine spécifique à l'aide des technologies de signature numérique, qui est ajoutée à l'e-mail lui-même (dans son en-tête DKIM-Signature). En règle générale, une signature DKIM est configurée au niveau MTA (infrastructure). DMARC définit la politique de vérification du courrier entrant dans un domaine spécifique et des actions sur les e-mails qui ne passent pas l'authentification SPF ou DKIM. Lorsque vous tentez de violer cette politique, un rapport structuré s'accompagne d'informations sur une telle tentative. DMARC, ainsi que SPF, est publié en tant qu'enregistrement TXT dans la zone de domaine.

Vérifiez la délivrabilité des e-mails vers les principaux services postaux - pour Russia Mail.Ru, Yandex, Gmail, Microsoft (Hotmail / Outlook.com / Office365), Rambler, nic.ru. Dans les e-mails arrivés, vous devez vérifier l'exactitude de HELO; la présence et le passage des chèques PTR / FCrDNS, SPF, DKIM et DMARC; la validité des en-têtes et des données qu'ils contiennent, en particulier le synchronisme de l'horloge dans les dates et l'exactitude des fuseaux horaires.


(Le courrier d'inscription a rompu l'authentification en raison de l'adresse de messagerie gratuite utilisée)

La formation de certains paramètres, par exemple l'autorisation, la délivrabilité et le spam, est intégralement influencée par tous les composants, mais pour leur contrôle, il existe généralement des outils opérationnels distincts - rapports DMARC et FBL, API des services postmaster, outils de suivi des e-mails, statistiques de livraison. Les tests doivent tenir compte du niveau de mise en œuvre des outils de suivi opérationnel dans l'entreprise - par exemple, en l'absence de contrôle opérationnel des rapports DMARC, l'autorisation des e-mails doit être régulièrement testée, alors qu'en l'absence de contrôle opérationnel de la délivrabilité, où et comment les e-mails vont, même s'il n'y a pas de développement lié à l'envoi d'e-mails.

Pour tester l'infrastructure, vous pouvez utiliser des services spécialisés, par exemple, mail-tester.com, mxtoolbox.com. Les exigences d'infrastructure détaillées peuvent être trouvées dans cet article .


(un exemple de l'enregistrement SPF cassé)

Exigences d'authentification

La vérification du passage de SPF, DKIM, DMARC est généralement possible en utilisant l'en-tête Authentication-Results sur le serveur du destinataire.

Vérifiez la validité de l'enregistrement SPF pour la syntaxe, la limite pour les requêtes DNS (par exemple, en utilisant mxtoolbox.com). Lors de la création d'un SPF, toutes les sources d'envois doivent être prises en compte (n'oubliez pas les systèmes CRM, toutes les infrastructures de livraison actuellement utilisées, y compris celles à travers lesquelles des campagnes marketing ponctuelles sont menées). Il est recommandé de définir les serveurs autorisés pour le domaine via la liste des réseaux ('ip4' / 'ip6'). SPF est vérifié pour l'adresse de l'expéditeur à partir de l'enveloppe SMTP. Vérifiez que le domaine d'enveloppe SMTP (enveloppe-de) correspond au domaine de l'en-tête De. Les erreurs SPF courantes sont répertoriées dans cet article (https://medium.com/hackernoon/myths-and-legends-of-spf-d17919a9e817).

Vérifiez l'enregistrement DNS DKIM, la validité et la composition de la signature DKIM. Vérifiez que vous utilisez une clé DKIM d'au moins 1024 bits. Mode de hachage recommandé pour la signature DKIM: détendu / détendu. Assurez-vous que tous les en-têtes importants sont signés (De, À, Objet, Date, ID de message, Version MIME, Type de contenu), que les en-têtes de suivi (Reçu, Livré à, Chemin de retour) ne sont pas signés et DKIM est validé pour les services de messagerie de base. Configurer le transfert vers l'un des services de messagerie vers un autre; DKIM ne doit pas "battre" sur les e-mails transférés. Vérifiez que le domaine de signature DKIM correspond au domaine de l'expéditeur à partir de l'en-tête «De».

Vérifiez DMARC pour les services de messagerie de base. Recherchez les rapports DMARC, identifiez et dépannez SPF et DKIM pour toutes les adresses IP de votre infrastructure.

Vérifiez que les messages sont remis à des serveurs externes à l'aide du chiffrement (TLS). Vous pouvez parfois vérifier TLS par l'en-tête Received sur le serveur du destinataire: par exemple, en spécifiant le protocole ESMTPS ou en ayant des paramètres de la forme (version = TLS1_2 cipher = ECDHE-RSA-AES128-GCM-SHA256 bits = 128/128); indique la présence de TLS.

Vérification de l'application génératrice

Exigences d'adresse e-mail

Adresses d'enveloppe

Nous commençons la vérification de l'application génératrice avec les adresses dans l'enveloppe SMTP.
Les adresses d'enveloppe sont des adresses du niveau de l'infrastructure de messagerie. Ils ne sont pas visibles pour l'utilisateur, mais ils sont importants pour la livraison car l'adresse de l'enveloppe détermine dans quelle boîte aux lettres l'e-mail va.

L'adresse du destinataire dans l'enveloppe ( envelope-to , alias RCPT TO: est l'adresse à laquelle l'e-mail sera effectivement livré.

• pour tous les e-mails, à l'exception de l'inscription, l'adresse doit être légalement signée et validée pour l'envoi conformément aux exigences administratives.
  
• pour les newsletters, l'adresse doit être «en direct», les adresses auxquelles les e-mails ne peuvent pas être livrés régulièrement doivent être marquées comme inactives, aucun courrier ne doit leur être envoyé. Mais certaines catégories d'e-mails (par exemple, la récupération d'accès) peuvent également devoir être envoyées à des adresses précédemment marquées comme inactives.
  

Adresse de l'expéditeur dans une enveloppe SMTP (généralement appelée envelope-from , smtp.mailfrom , MAIL FROM: ou Return-Path ) - des messages seront livrés à cette adresse concernant l'impossibilité de livrer un e-mail et des réponses automatiques. Cette adresse n'est pas visible pour l'utilisateur. Cette adresse est également utilisée pour l'autorisation SPF. Nous vérifions que:

• L'adresse est disponible;
  
• Ce n'est pas l'adresse de l'employé et il n'est pas redirigé vers lui afin d'exclure les réponses automatiques, les messages d'inaccessibilité, etc.;
  
• Il est traité par un script qui marquera les adresses des utilisateurs inaccessibles comme inactives;
  
• L'adresse peut être générée automatiquement, c'est-à-dire unique pour chaque e-mail;
  
• Un e-mail à cette adresse ne doit pas entraîner la génération d'un e-mail de réponse, par exemple un message concernant un débordement de boîte aux lettres.
  

Adresses d'en-tête de messagerie

Ces adresses sont soit directement visibles par l'utilisateur, soit utilisées lors de la réponse à un e-mail.
Adresse de l'expéditeur (l'en-tête From: est l'adresse et le nom de l'expéditeur affichés dans la liste des e-mails et lors de la lecture d'un e-mail. Nous vérifions que:

• Il s'agit d'une adresse conviviale lisible par l'homme qui identifie l'entreprise.
  
• Il contient non seulement une adresse e-mail mais également le nom de l'expéditeur.
  
• Noreply @ est possible, mais seulement si nous voulons souligner que nous ne nous attendons pas à recevoir une réponse à l'e-mail et qu'elle ne sera pas lue. Il vaut mieux dupliquer cette idée dans le texte de l'email.
  
• En présence de caractères non ASCII (par exemple cyrillique), le nom de l'expéditeur doit être codé conformément à MIME, le domaine en présence de caractères non ASCII doit être codé en Punycode
  
• Les e-mails de la même catégorie doivent avoir la même adresse; l'utilisation d'adresses générées automatiquement doit être évitée. Cela est dû au fait que «De:» est le plus souvent utilisé par les gens pour trier les e-mails par dossiers à l'aide de filtres.
  
• L'adresse doit être différente (de préférence dans différents sous-domaines) pour les e-mails transactionnels, marketing et urgents (tels que les e-mails du service d'assistance). Cela est également dû au fait que l'utilisateur peut marquer les e-mails marketing comme spam ou les filtrer dans un dossier illisible.
  
• L'adresse From: et l'adresse d'enveloppe SMTP doivent être dans le même domaine ou dans des sous-domaines du même domaine d'organisation afin de passer le SPF dans le DMARC.
  
• L'adresse doit provenir du domaine de l'organisation. Il est inacceptable d'utiliser des services de messagerie gratuits et d'autres domaines de messagerie publique dans From: car ces mailings ne passeront pas l'authentification SPF et DKIM dans le cadre de DMARC.
  

L'adresse Reply-to - les réponses «manuelles» seront envoyées à cette adresse lorsqu'un utilisateur répond à un e-mail. C'est facultatif. S'il est absent, l'adresse de «De:» est utilisée pour la réponse. Vérifiez que «Répondre à»:

• Il peut être généré automatiquement, c'est-à-dire unique à l'e-mail (vous permet de savoir à quel e-mail la réponse est arrivée).
  
• Il ne doit pas tomber dans la boîte aux lettres de l'employé pour éviter la réponse automatique, mais devrait idéalement être «enveloppé» dans CRM.
  
• Il peut générer une réponse automatique CRM standard, mais il ne doit pas générer quoi que ce soit de superflu, par exemple un débordement de boîte aux lettres ou des messages "sur vocation". Lors de la génération de réponses automatiques, des mesures doivent être prises pour éviter le bouclage, elles sont répertoriées dans la RFC 3834.
  
• Il peut provenir de n'importe quel domaine qui ne coïncide pas nécessairement avec «De:», mais cela effraie parfois les utilisateurs lorsqu'ils répondent.
  
• Peut être absent, alors l'adresse From: remplit ses fonctions.
  
• En plus de l'adresse, le nom de l'expéditeur est indiqué.
  

L'adresse To:

• Doit contenir l'e-mail du destinataire (sinon cela effraie le destinataire du message et gêne l'anti-spam).
  
• Idéalement, il devrait contenir le nom du destinataire. Mais si le nom est inconnu ou douteux (par exemple, l'adresse n'a pas encore été confirmée), il est préférable de ne pas l'indiquer (quelqu'un peut entrer l'adresse de quelqu'un d'autre avec un mauvais nom et le destinataire peut être offensé).
  

Exigences de l'en-tête de l'e-mail

L'encodage réel du texte doit correspondre à celui indiqué dans l'en-tête. Il est conseillé d'utiliser un seul codage dans tous les en-têtes et parties de l'e-mail. Il est recommandé d'utiliser UTF-8 comme étant largement pris en charge. L'encodage est indiqué dans les en-têtes Content-Type et dans la balise de la partie HTML.

Les en-têtes From:, Message-ID: et Date: doivent être formés directement dans le script pour envoyer l'e-mail (et selon les normes - avec le texte de l'e-mail) et toujours dans le format correct. S'ils sont absents ou mal formés, l'un des serveurs de transit peut ajouter ces en-têtes, ce qui entraîne une violation de l'intégrité de la signature DKIM.

Les caractères de 8 bits dans les en-têtes, y compris la ligne d'objet (Objet) et les noms des fichiers joints (Content-Type et Content-Disposition), doivent être absents; Tous les caractères non ASCII, y compris cyrillique, doivent être codés en imprimable entre guillemets ou en base64.


(confirmation d'inscription dans un codage étrange)

Exigences relatives à la structure de l'e-mail

Pour la partie HTML de l'e-mail, il est souhaitable de former une partie alternative (texte brut). Il est également nécessaire de vérifier la conformité et la lisibilité de la partie en texte brut de l'e-mail (le cas échéant) et la structure générale de l'e-mail.

Selon la RFC 5322, la longueur d'une ligne dans un e-mail ne doit pas dépasser 998 caractères 8 bits. Veuillez noter qu'en UTF-8, un personnage peut occuper plusieurs octets. Le terminateur de lignes dans un e-mail est une paire de CRLF (ascii 13, ascii 10), qui prend 2 octets. Vous devez vérifier l'exactitude du terminateur de chaîne, car les e-mails sont souvent envoyés à l'aide d'un script Unix, et dans Unix, le terminateur de chaîne est un seul caractère - il s'agit d'une erreur pour le courrier électronique. Vous devez également vérifier si les terminateurs de chaîne rompent les caractères codés UTF-8: vous ne pouvez pas autoriser la présence d'un terminateur de chaîne entre deux octets du même caractère, par exemple, le symbole cyrillique. Pour éviter de telles situations, il est nécessaire de casser le texte avant de former l'e-mail ou de coder le texte en base64, base64 a généralement une longueur de ligne fixe.

Il est nécessaire de vérifier le marquage correct des pièces jointes et des inlines - c'est-à-dire l'exactitude de la formation des en-têtes "Content-Disposition: inline", s'il s'agit d'une image affichée à l'intérieur de l'e-mail, ou "Content-Disposition: attachment" si le fichier joint est destiné au téléchargement.

La structure de l'e-mail doit être aussi simple que possible: en particulier, il ne doit pas y avoir plus d'une partie en plusieurs parties de chaque type (mixte, alternative, liée), et en plusieurs parties / mixte est utilisé uniquement si l'e-mail contient des pièces jointes, en plusieurs parties / connexes - si HTML est fourni avec des images en ligne, en plusieurs parties / alternative - en présence de texte brut et de parties HTML. En général, la structure de l'e-mail, en l'absence de pièces jointes et d'images en ligne, devrait ressembler à ceci:

multipart / alternative
- texte / uni
- texte / html

L'ordre des parties est important, text / plain doit aller AVANT text / html ou multipart / related. Ceci est nécessaire pour que la partie HTML soit affichée par défaut, et seulement si son affichage n'est pas disponible pour une raison quelconque, la partie simple est affichée.

S'il y a des images en ligne dans l'e-mail, sa structure devrait ressembler à ceci:

multipart / alternative
- texte / uni
- multipart / apparenté
—— texte / html
—— image / ... (image en ligne)
—— image / ... (image en ligne)

Les images en ligne doivent avoir Content-Disposition: en ligne et être strictement à l'intérieur de la partie en plusieurs parties / associée.
Dans le cas le plus difficile, lorsqu'il y a à la fois des images en ligne et des fichiers joints, l'e-mail a la structure suivante:

multipart / mixte
- multipart / alternative
—— texte / clair
—— multipart / connexe
——— texte / html
——— image / png
——— image / png
...
- application / octet-string (content-disposition: attachment)
- application / octet-string (content-disposition: attachment)
...
les parties liées et multipart / alternatives doivent être fermées avant les pièces jointes, les pièces jointes appartiennent à la partie multipart / mixte externe)


(message d'enregistrement avec une structure de pièces incorrecte)

Exigences d'URI

Tous les URI (en src, attributs href, styles, etc.) doivent contenir le protocole et le nom d'hôte (https://example.com/somepath). Les erreurs typiques sont l'utilisation de liens relatifs (/ somepath) et l'absence de protocole (//example.com/somepath), ce qui est inacceptable pour les e-mails, car dans ceux-ci, le protocole par défaut peut être file:// .

• Tous les caractères de service et non ASCII (en particulier cyrillique) dans l'URI doivent être codés à l'aide d'un pourcentage de codage.
  
• Un lien inséré sous forme de texte (c'est-à-dire visible par l'utilisateur sous forme d'URL et non sous forme de texte) doit toujours être marqué avec la balise <> , sinon l'utilisateur ne pourra pas cliquer dessus. Certains webmails marquent ces liens par eux-mêmes, mais ce n'est pas un comportement standard. Dans ce cas, l'adresse href à l'intérieur de A doit correspondre au texte du lien, sinon le filtre de contenu peut réagir à un tel lien comme une tentative de tromper l'utilisateur. Cela vaut particulièrement la peine de faire attention lorsqu'il existe des "cliqueurs" qui suivent les transitions de l'utilisateur à partir de l'e-mail.
  
• Il vaut mieux se limiter à l'utilisation des protocoles http:// , https:// et mailto:
  
• Avec des exigences de haute sécurité, vous devez abandonner complètement l'utilisation de http:// au profit de https:// .
  
• Les ports non standard ne doivent pas être utilisés (par exemple, example.com : 8080 / somepath), car ils peuvent ne pas être accessibles à l'utilisateur.
  
• Le fait de cliquer sur le lien à l'intérieur de la partie HTML ne doit entraîner aucune modification de l'état de l'application (abonnement, désabonnement, annulation de la commande, etc.) sans confirmation supplémentaire de l'utilisateur sur la page, car certains systèmes de filtrage de contenu peuvent indépendamment vérifier la sécurité d'une telle transition en demandant une page par référence; l'application de messagerie peut afficher l'aperçu de la page par le lien en survol et les navigateurs modernes peuvent charger la page avant que l'utilisateur clique sur le lien pour réduire le temps de chargement (dans l'application Web, il n'est généralement pas recommandé d'effectuer des actions de modification sur le GET request, toutes les demandes de modification doivent passer par POST ou PUT).
  
• En revanche, cliquer sur le lien dans l'en-tête List-Unsubscribe ne devrait pas nécessiter d'actions supplémentaires de la part de l'utilisateur, car la désinscription par ce lien se fait généralement par programme de messagerie électronique ou webmail au nom de l'utilisateur. En outre, il y a un nouvel en-tête List-Unsubscribe-Post introduit par RFC 8058.
  
• Vous ne devez pas vous attendre à ce que l'utilisateur lise l'e-mail et suive le lien dans le même navigateur dans lequel il initie l'action conduisant à l'envoi de l'e-mail (par exemple, enregistre un compte). Le lien doit fonctionner dans tout autre navigateur ou appareil mobile. En particulier, l'utilisateur peut ouvrir le lien sans être autorisé ou autorisé dans un compte autre que celui auquel l'e-mail a été envoyé.
  
• Parce que la longueur de l'URI peut être limitée; vous ne devez pas utiliser d'URI de type 'data:' pour les gros objets. Pour la même raison, n'utilisez pas d'URI trop longs dans les hyperliens.
  
• Vous ne devez pas utiliser de raccourcisseurs de liens externes, cela affecte négativement la livraison des e-mails. Il est préférable que tous les liens pointent vers votre domaine, cela réduira l'impact négatif potentiel de la réputation d'une autre personne sur la livraison des e-mails.
  
• Ne placez pas d'images externes sur certains services publics ou d'hébergement gratuit, utilisez un service d'hébergement fiable ou un CDN avec de bonnes performances et une bonne réputation.
  

(image non valide et URI d'ancrage en raison d'une spécification de protocole manquante)

Exigences de mise en page des e-mails

Pourquoi est-il si difficile de créer des e-mails?

Les clients de messagerie d'une manière ou d'une autre affichent le contenu utilisateur dans leur interface. Potentiellement, cela peut entraîner divers problèmes de sécurité - scripts intersites (XSS, Crossite scripting), usurpation d'interface, DOM clobbering, désanonymisation des utilisateurs / fuite d'informations (par exemple, l'adresse IP de l'utilisateur ou les cookies via des requêtes externes), etc. Par conséquent, tout service de messagerie et toute application de messagerie ont une certaine forme de protection contre chaque classe d'attaques. Malheureusement, il n'y a pas d'approche unique pour organiser cette protection. Il peut être organisé à travers:

• cadres limités isolés,
  
• balises et / ou attributs de filtrage,
  
• restrictions de positionnement absolu,
  
• interdiction ou restriction de l'utilisation des styles de bloc (ce qui est essentiel pour une mise en page adaptative),
  
• l'interdiction d'éléments externes par défaut (ie le téléchargement d'images externes nécessite l'autorisation de l'utilisateur) ou l'utilisation d'un proxy pour y accéder,
  
• convertir des e-mails HTML en un autre format intermédiaire (par exemple, Microsoft Exchange / Outlook utilise RTF, ce qui peut rendre extrêmement difficile l'affichage correct des éléments dans Outlook à l'aide de méthodes conventionnelles),
  
• interdiction ou restriction de l'utilisation des formulaires ou de leurs éléments individuels.
  

Les e-mails utilisent également des éléments spécifiques, tels que des images en ligne et l'URI cid:// , dont la prise en charge peut être limitée. Par exemple, Mozilla Thunderbird ne prend pas en charge cid:// pour les images d'arrière-plan.

Même un e-mail correctement formé peut être affiché différemment dans différentes interfaces en raison des particularités de leur mise en œuvre et du filtrage du contenu de l'e-mail.

S'il y a des erreurs dans le format de l'e-mail, le comportement devient complètement imprévisible. Par exemple, les clients de messagerie peuvent avoir un comportement différent avec des URI incorrects ou ce formatage d'en-tête incorrect est géré différemment. En outre, la détection automatique de l'encodage de texte fonctionne différemment si elle n'est pas spécifiée ou si elle est spécifiée de manière incorrecte. Par conséquent, l'e-mail doit être affiché dans différentes interfaces: l'affichage correct de l'e-mail dans une interface ne signifie pas qu'il est composé correctement (en fait, même l'affichage correct de l'e-mail dans toutes les interfaces ne garantit pas qu'il n'y aura pas problèmes d'affichage à l'avenir).



Il est nécessaire de prêter attention aux points suivants:

• Vérifiez le texte de l'e-mail pour le contenu sémantique, l'affichage, l'absence de fautes de frappe, les erreurs de syntaxe, d'orthographe et lexicales.
  
• Vérifiez l'exactitude de la substitution des données d'application dans le modèle ou la présentation de l'e-mail.
  
• Vérifiez l'exactitude des montants, dates, numéros, articles de marchandise et autres informations, en tenant compte des conditions aux limites autorisées. Les dates doivent avoir un an (certains utilisateurs entrent très rarement dans la case). Un fuseau horaire doit être présent dans le temps. L'adresse doit contenir une ville, et dans certains cas, il est nécessaire d'indiquer le pays.
  
• Vérifiez l'état opérationnel de tous les liens dans l'e-mail, le cas échéant.
  
• Dans les courriels envoyés avant la confirmation de l'adresse, incl. e-mails avec un lien de confirmation, aucun texte ne doit être contrôlé de l'extérieur, même le nom d'utilisateur, sinon, ils peuvent être utilisés pour le spam (dans le champ affiché dans l'e-mail, par exemple, dans le nom, le texte du spam est inséré et l'adresse est l'adresse indiquée de la victime). Par exemple, si vous pouvez envoyer un texte obscène à l'adresse du développeur au nom de votre service, il y a un problème.
  
• Vérifiez l'absence d'images externes sur les services tiers. Cela peut affecter la livraison et la fuite d'informations sur vos clients.
  
• Vérifiez la disponibilité des compteurs pour l'envoi, la livraison, la lecture des e-mails, les transitions. Certains d'entre eux sont situés dans l'e-mail lui-même (par exemple, le contre-pixel de lecture de l'e-mail), certains sont suivis par l'expéditeur, mais, en règle générale, tous sont disponibles dans le panneau d'administration de l'expéditeur.
  
• Vérifiez l'exactitude de la catégorie d'abonnement et la désinscription de l'utilisateur pour cette catégorie via le lien dans l'e-mail.
  
• Vérifiez à quoi ressemble l'e-mail:
  
  • Versions Web populaires du courrier pour un pays ciblé: les "trois grands" pour la Russie sont Mail.Ru, Yandex, Gmail. Vous pouvez également ajouter Rambler et Outlook.com;
    
  • Applications mobiles des fournisseurs de messagerie ci-dessus;
    
  • Applications mobiles standard utilisant IMAP, en tenant compte des plates-formes mobiles populaires, au moins pour l'iPhone, Pixel (plate-forme de référence Android), Samsung (le plus courant pour Android), MIUI (prend la deuxième place en Russie pour les plates-formes Android);
    
  • Divers navigateurs de bureau: Chrome, Firefox, Edge, Internet Explorer, Opera, etc.;
    
  • Applications de bureau (programmes de messagerie), en particulier Thunderbird, Outlook et Apple Mail, éventuellement The Bat! et Opera Mail;
    
  • Solutions d'entreprise populaires avec une interface Web (Exchange, peut-être Roundcube, Communigate, Zimbra, SquirrelMail) - pour les solutions B2B;
    
  • N'oubliez pas de vérifier la disposition des moniteurs Retina et des moniteurs de résolution inférieure.
    
• Lors de la vérification dans chaque cas, vous devez faire attention à:
  
  • Passer les en-têtes d'autorisation, SPF / DKIM / DMARC.
    
  • Vitesse de téléchargement des e-mails: il devrait se charger rapidement et ne pas prendre son temps.
    
  • Affichage d'un e-mail dans la liste des e-mails: avatar, nom de l'expéditeur et sujet qui tombe dans l'extrait de message, si sa catégorie a été correctement définie (par exemple, si la commande ne tombe pas dans la catégorie "réseaux sociaux").
    
  • La mise en page de l'e-mail dans son ensemble: si la mise en page restait cohérente, y avait-il des sauts de mots incorrects, etc., y compris lors de la mise à l'échelle et du redimensionnement de la fenêtre.
    
  • Les polices ne doivent pas être petites ou difficiles à lire.
    
  • Images d'arrière-plan et couleurs d'arrière-plan.
    
  • Correspondant au livre de la marque.
    
  • Facilité d'exécution des actions impliquées par l'e-mail. Par exemple, si l'e-mail contient un code de confirmation ou d'autres informations qui peuvent avoir besoin d'être stockées quelque part, il ne doit pas seulement être bien lu, il doit également être pratique de le sélectionner et de le copier même dans l'interface mobile.
    
  
  
• Gardez une trace de la taille globale de l'e-mail (y compris les images externes) et qu'elle ne dépasse pas les valeurs raisonnables. Plus le temps de chargement est lourd, plus il est probable qu'une personne y réagira négativement.
  
• Même les courriels qui n'ont pas été modifiés devraient être vérifiés périodiquement, car des changements peuvent survenir du côté du service postal et, par exemple, «révéler» un problème auparavant invisible.
  
• Certains paramètres doivent être contrôlés dans tous les tests. Par exemple, les problèmes de réussite de l'authentification DKIM peuvent être dus à des problèmes dans l'infrastructure (problèmes avec DNS ou la formation d'une signature DKIM, erreurs de synchronisation horaire), dus à des erreurs dans le programme de génération (l'adresse de l'expéditeur est mal formée, des caractères incorrects dans les en-têtes sont manquants ou les en-têtes obligatoires De, Date ou Message-ID ont été dupliqués) et en raison d'erreurs de contenu (terminateurs de ligne incorrects, les lignes sont trop longues, adresses incorrectes). Dans le même temps, l'e-mail peut ne pas «battre» et le problème peut n'apparaître sur aucun service.
  

Réalisation de tests fractionnés

La recherche marketing dépasse le cadre de cet article, mais il convient de mentionner quelques points clés qui affectent considérablement la qualité des e-mails.

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