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

Le développeur, qui a rencontré pour la première fois la génération d'e-mails, n'a pratiquement aucune chance d'écrire une application qui le fera correctement. Environ 40% des e-mails générés par les applications d'entreprise ont une sorte de violation des normes et, par conséquent, des problèmes de livraison et d'affichage. Il y a des raisons à cela: le courrier électronique est techniquement beaucoup plus compliqué que le Web, le courrier est réglementé par plusieurs centaines de normes et un nombre incalculable de pratiques généralement acceptées (et pas ainsi), et les clients de messagerie sont divers et imprévisibles. Les tests peuvent améliorer considérablement la situation, mais il n'y a pratiquement aucun matériel consacré au test du courrier.

Mail.Ru mail interagit régulièrement avec ses utilisateurs via des e-mails. Dans notre projet, tous les composants qui sont responsables de la génération des e-mails, et même des envois uniques, subissent des tests obligatoires. Dans cet article, nous partagerons notre expérience (et plein de bosses).

• Que sont les e-mails
• Qui est impliqué dans le processus de test et de contrôle
• Courrier et transport postal
• L'interface de l'infrastructure de messagerie et les limites de l'application testée
• Définition des paramètres testés
• Structure typique d'une application génératrice
• Quoi et quand tester
  
  1. Infrastructure de livraison
  2. Génération d'une application
  3. Modèles de lettres structurelles et de mise en page
• Exigences de base pour vérifier l'infrastructure
• Conditions d'autorisation
• Vérification de l'application génératrice
  
  • Exigences d'adresse postale
  • Exigences de l'en-tête de l'e-mail
  • Conditions requises pour la structure de la lettre
  • Exigences d'URI
  • Exigences de mise en page
• Réalisation de tests fractionnés

Que sont les e-mails

L'application peut générer différents types de lettres. Ils peuvent être classés en plusieurs catégories. Par la méthode de sélection des destinataires: déclencheur - sélectif - groupe. Sur rendez-vous: transactionnel - marketing - service. Différents types de lettres peuvent avoir des exigences différentes et appliquer différents scripts de test.

Les e-mails de déclenchement sont générés en réponse à tout événement, par exemple, les actions de l'utilisateur ou les modifications de l'état des objets système. Ils sont générés par l'application, et donc les plus intéressants en termes de tests. Les e-mails de déclenchement peuvent être à la fois transactionnels et marketing.

Des lettres personnalisées sont envoyées à une sélection dynamique d'utilisateurs correspondant à tous les critères.

Les messages de groupe sont envoyés à un groupe connu de destinataires, par exemple, à tous les utilisateurs ou partenaires. Les lettres sélectives et de groupe sont le plus souvent du marketing, l'envoi de ces lettres est initié manuellement ou selon un calendrier.

Des lettres transactionnelles sont générées lorsqu'un utilisateur effectue une action. Ces lettres comprennent, par exemple, des factures, des tickets ou des notifications d'état de livraison, des lettres avec un code de récupération d'accès, etc. Les e-mails transactionnels sont toujours déclenchés. Une compatibilité maximale est importante pour eux, ce qui signifie qu'ils doivent être aussi simples que possible et qu'ils doivent être testés sur un grand nombre de clients.

Les lettres marketing encouragent l'utilisateur à entreprendre n'importe quelle action, par exemple, il peut s'agir d'une offre de remises individuelles basée sur des achats antérieurs. Dans ces lettres, des données transactionnelles peuvent être utilisées, elles peuvent être à la fois déclenchées et massives - périodiques ou ponctuelles. Pour ces lettres, l'efficacité est plus importante, elle est généralement déterminée par les résultats d'un test fractionné. Certains aspects de la compatibilité peuvent être sacrifiés pour l'efficacité.

Les lettres de marketing de groupe, par exemple, les messages sur les offres saisonnières, les promotions et les ventes, sont souvent envoyées «manuellement» et ne font pas partie de votre application, mais vous pouvez (et devez) leur appliquer des principes de test généraux.

De plus, il peut y avoir des lettres de service générées par les employés pour les systèmes CRM, journalisation, audit ou DWH automatisés ou automatisés. Ces lettres sont déclenchées, ce qui signifie qu'elles font également partie de l'application et doivent être testées.

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 du réseau et de l'infrastructure de messagerie. Un ingénieur réseau doit être impliqué dans la planification des tests d'infrastructure.
3. Un spécialiste de la délivrabilité est une personne qui surveille la livraison des lettres, qui participe également à la surveillance des paramètres techniques et administratifs de tous les messages envoyés et surveille l'avancement du processus d'envoi. Il est responsable de s'assurer que les lettres envoyées atteignent le pourcentage maximum possible d'utilisateurs et ne tombent pas dans le spam, et pour cela le spécialiste doit avoir certaines connaissances et contacts. Si des problèmes surviennent avec la remise des lettres, 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 lettres; ou résoudre le problème avec le service d'assistance du fournisseur de messagerie, auquel les lettres ne parviennent pas. Un tel spécialiste (le cas échéant) devrait également être impliqué dans la préparation d'une liste de contrôle et le test de l'infrastructure qui génère les applications et les lettres. Cependant, le processus de test lui-même doit être sous le contrôle du service QA.
4. Marketing par e-mail - détermine l'efficacité des campagnes marketing. Sous son contrôle, le fractionnement des tests pour le public nécessaire aux mailings marketing a lieu. 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 et la «présentation» visuelle de l'e-mail à l'utilisateur.

Tous ces rôles ne sont pas nécessairement assumés par un employé distinct: le rôle d'un responsable marketing peut être joué par l'un des chefs de produit, et le rôle d'un spécialiste de la délivrabilité peut être joué, par exemple, par un employé de support ou un ingénieur réseau. Et dans les startups avec un degré de probabilité élevé, tout cela devra être fait par une seule personne, et elles peuvent se révéler être un spécialiste de la qualité.

Courrier et transport postal

La structure du courrier est similaire à un énorme iceberg, et elle a deux niveaux. Il existe plus d'une centaine de normes différentes régissant le courrier, mais presque toutes appartiennent à l'un de ces deux niveaux:

La partie sous-marine de l'iceberg est un service réseau dont le protocole de base est le protocole d'application SMTP, défini par la RFC 5321. Il est responsable de la livraison des lettres. Pour remettre la lettre, une enveloppe dite SMTP est formée, qui comprend les adresses de l'expéditeur et du récepteur du niveau SMTP. D'autres services réseau tels que DNS sont également responsables de la remise de la lettre. Le composant principal de l'infrastructure réseau est l'agent de transfert de courrier, ou l'abréviation MTA est utilisée plus souvent. MTA est responsable de la gestion de la file d'attente de remise des messages et du processus de remise aux serveurs destinataires. Les exemples de MTA sont Postfix, Sendmail, Exim, Microsoft SMTP service.

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

La surface de l'iceberg est la lettre elle-même. La structure de base de la lettre est définie dans la RFC 5322. La lettre se compose d'en-têtes de service et d'une ou plusieurs parties avec des données. Les données peuvent contenir du texte en texte brut et / ou HTML, 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 avec lesquelles une lettre est envoyée (elle entre dans la file d'attente de remise du 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, l'API de services internes ou externes (par exemple, GetResponse, SendPulse ou Amazon SES). Nous considérerons ces interfaces comme faisant partie de l'infrastructure. Très souvent, il y a une situation où l'application A prépare des données pour une lettre et une liste de destinataires, puis les transfère à l'application B via son API (pour le marketing de masse, cela peut être fait manuellement via l'interface utilisateur - UI), et déjà l'application B génère un message électronique dans Format RFC 5322 et le met en file d'attente pour la livraison MTA. Du point de vue de 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 l'interface de l'infrastructure de messagerie pour l'application A. Bien que du point de vue de l'application B, la situation sera différente et l'infrastructure de messagerie pour celle-ci sera constituée d'applications ou de protocoles réseau de niveau inférieur.

Définition des paramètres testés

Lors du test de chaque application, il est important de mettre en évidence toutes les infrastructures de messagerie utilisées par celle-ci (il peut y en avoir plusieurs), et pour chaque infrastructure, de sélectionner 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 y sont transférées sont déterminés aussi précisément que possible, par exemple: texte de message en TEXT / HTML, texte de message en TEXT / PLAIN, sujet du message, nom du destinataire, adresse du destinataire, nom de l'expéditeur, adresse de l'expéditeur de la lettre (RFC5321.From ), l'adresse de l'expéditeur du conducteur 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 contrôle pour chacun des paramètres sont déterminées (de quelle manière le résultat réel peut-il être comparé au résultat attendu).

Structure typique d'une application génératrice

En règle générale, le produit que nous testons est responsable de la génération de la lettre et des données qu'elle contient. Il s'agit généralement d'une application serveur (mais parfois cliente). Il définit la structure de la lettre, une partie des en-têtes de service, les formats d'encapsulation des données, la présentation des chaînes et l'encodage du texte. Un exemple simple d'une telle application est un script qui forme une lettre et appelle la fonction mail() .

Les principaux éléments de l'application à maîtriser:

• code responsable de la génération des en-têtes et / ou de la structure des lettres si la structure des lettres est générée dynamiquement et / ou un modèle de lettre statique décrivant sa structure;
• disposition de la partie HTML de la lettre (idéalement, il s'agit d'une entité distincte ou d'une partie du modèle / de la disposition de la lettre, mais qui peut être cousue dans le code d'application);
• Substitution des données d'application dans une lettre (ou dans un modèle de lettre);
• intégration de l'application avec l'infrastructure de distribution de lettres, la justesse des paramètres transféré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:

1. Infrastructure de livraison

Les tests devraient mettre l'accent sur: la délivrabilité des lettres; l'exactitude des enregistrements DNS, y compris les enregistrements PTR / FCrDNS, MX et A; Paramètres du protocole SMTP (HELO, utilisant TLS); autorisation de lettre (SPF / DKIM / DMARC); Adresses d'enveloppe SMTP (si elles ne sont pas gérées par l'application); traitement correct des paramètres d'entrée de l'interface de l'infrastructure; suivi, comptabilité et traitement des lettres non remises.

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 de l'interface d'envoi de lettres; Utilisation d'un nouveau domaine, réseau ou API Modifiez considérablement les caractéristiques des e-mails envoyés, comme leur langue, leur taille ou leur quantité. Selon l'expérience, l'infrastructure a tendance à changer sans déclarer la guerre, donc des tests de base devraient être effectués périodiquement, même s'il n'y a aucune information sur des changements.

Un ingénieur réseau et un spécialiste de la délivrabilité peuvent et doivent être impliqués dans la préparation du plan et des listes de contrôle des tests d'infrastructure.

2. L'application génératrice

Vous devez contrôler les adresses de l'enveloppe SMTP (si elles sont contrôlées par l'application, c'est-à-dire transférées à l'interface - enveloppe-de, enveloppe-à), les valeurs des en-têtes de message de service (Date, Message-ID, Liste-Désabonnement, Soumission automatique, etc.) p.), autorisation de lettres (DKIM / DMARC), encodages MIME (base64, quoted-printable), l'exactitude générale du format de lettre, par exemple, l'absence de caractères non ASCII dans les en-têtes, la composition des données substituées, le déclenchement correct des déclencheurs, les mécanismes de désabonnement, les mécanismes de suivi collecte de lettres et de statistiques (en-têtes de postmaster, par exemple, Feedback-ID ou X-Mailru-Msgtype, ainsi que le suivi des pixels) .

Vous devez tester l'application au cours de son développement, lors du changement de tous ses composants associés responsables de la génération et du stockage des données, avec des modifications importantes des modèles de lettres, lors du changement de l'infrastructure utilisée ou de son interface, ainsi que dans le cadre de régressions générales.

3. Modèles de lettres structurelles et de mise en page (peuvent faire partie d'une application génératrice ou sont développés séparément)

La structure du message est vérifiée (Content-Type, Content-Disposition, imbrication des parties multiparties de la lettre, encodage de texte, paramètres de chaîne), la valeur de la cible et les en-têtes affichés (De, À, Répondre à, Objet), le message est affiché dans la liste des lettres et lors de la lecture dans diverses interfaces, 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-mail doivent être testés chaque fois que vous effectuez au moins les moindres modifications, et également séparément, par exemple, dans une situation où des lettres pénètrent dans l'application avant que la partie serveur ne soit prête.

Il est recommandé d'utiliser un spécialiste du marketing par courrier électronique et de la délivrabilité pour rédiger une liste de contrôle pour tester un modèle de lettre.

Exigences de base pour vérifier l'infrastructure

L'adresse IP sélectionnée pour le serveur de messagerie doit être aussi similaire que possible à 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 à un réseau pouvant être perçu comme dynamique; Le réseau sélectionné doit avoir des contacts valides auxquels vous pouvez envoyer des réclamations; 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 en utilisant le service d'assistance du fournisseur. L'enregistrement PTR doit pointer vers le véritable nom d'hôte et en même temps être significatif, se résoudre à la même adresse IP (la 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 message doit avoir un enregistrement MX valide pointant vers un enregistrement A de l'hôte, qui, au minimum, peut traiter les messages concernant l'échec de la remise. Pour MX, il n'est pas permis de 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 l'enregistrement 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 de la zone DNS du domaine. DKIM permet de vérifier la paternité d'un message ou l'appartenance de son expéditeur à un domaine spécifique à l'aide de technologies de signature numérique, qui sont ajoutées au message 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 les actions sur les lettres qui ne passent pas l'authentification SPF ou DKIM. Lorsque vous essayez de violer cette politique, un rapport structuré arrive avec des informations sur une telle tentative. DMARC, ainsi que SPF, est publié en tant qu'enregistrement TXT dans la zone de domaine.

Vérifiez la livraison des lettres aux principaux services postaux - pour la Russie, Mail.Ru, Yandex, GMail, Microsoft (Hotmail / Outlook.com / Office365), Rambler, nic.ru. Dans les lettres, vous devez vérifier l'exactitude de HELO; disponibilité et 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 des heures dans les dates et l'exactitude des fuseaux horaires.



La formation de certains paramètres, par exemple l'autorisation, la délivrabilité et le spam, est influencée intégralement par tous les composants, mais il existe généralement des outils opérationnels distincts pour les contrôler - rapports DMARC et FBL, API de service postmaster, outils de suivi des e-mails et statistiques de livraison. Les tests doivent prendre en compte le niveau de mise en œuvre des outils de suivi opérationnel dans l'entreprise - par exemple, en l'absence de suivi opérationnel des rapports DMARC, vous devez tester régulièrement l'autorisation de courrier, en l'absence de suivi opérationnel de la délivrabilité - vérifier régulièrement comment et où les lettres arrivent, même s'il n'y a pas de développement lié à l'envoi de lettres pas effectué.

Pour vérifier 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 .

Conditions d'autorisation

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 constitution d'un SPF, toutes les sources de mailing doivent être prises en compte (n'oubliez pas les systèmes CRM, toutes les infrastructures de livraison 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 .

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 que DKIM est validé pour services postaux de base. Configurez le transfert vers l'un des services de messagerie vers un autre; DKIM ne doit pas "battre" sur les lettres transférées. Vérifiez que le domaine de signature DKIM correspond au domaine de l'expéditeur à partir de l'en-tête From.

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). Parfois, vous pouvez vérifier TLS par l'en-tête Received sur le serveur du destinataire: par exemple, en spécifiant le protocole ESMTPS ou la présence de paramètres du formulaire (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 postale

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 importants pour la livraison, car dans quelle boîte aux lettres la lettre est envoyée, elle est déterminée précisément par l'adresse de l'enveloppe.

L'adresse du destinataire dans une enveloppe (enveloppe-à, alias RCPT TO :) est l'adresse à laquelle la lettre sera effectivement livrée.

• pour toutes les lettres à 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 lettres ne peuvent pas être livrées régulièrement doivent être marquées comme inactives, aucun courrier ne doit leur être envoyé. Mais certaines catégories de lettres (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 enveloppe-de, smtp.mailfrom ou Return-Path) - des messages seront livrés à cette adresse concernant l'impossibilité de remettre une lettre 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 pour 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 à chaque lettre;
• Une lettre à cette adresse ne doit pas conduire à la génération d'une lettre de réponse, par exemple un message concernant un débordement de boîte.

Adresses d'en-tête de messagerie

Ces adresses sont soit directement visibles par l'utilisateur, soit utilisées lors de la réponse à une lettre.

Adresse de l'expéditeur (à partir de :) L'en-tête est l'adresse et le nom de l'expéditeur affichés dans la liste des lettres et lors de la lecture d'une lettre. Nous vérifions que:

• Il s'agit d'une adresse conviviale «lisible par l'homme» qui identifie l'entreprise.
• Il contient non seulement le courrier électronique, mais également le nom de l'expéditeur.
• n @ply est possible, mais seulement si nous voulons souligner que nous ne nous attendons pas à recevoir une réponse à la lettre et qu'elle ne sera pas lue. Il vaut mieux reproduire cette idée dans le texte de la lettre.
• 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 lettres de la même catégorie doivent avoir la même adresse; l'utilisation d'adresses générées automatiquement n'est pas autorisée. Cela est dû au fait que From: est le plus souvent utilisé par les gens pour trier les lettres dans des dossiers à l'aide de filtres.
• L'adresse doit être différente (de préférence dans des sous-domaines différents) pour les lettres transactionnelles, marketing et urgentes (telles que les lettres 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 de provenance 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 De, car ces mailings ne passeront pas l'authentification SPF et DKIM dans le cadre de DMARC.

Adresse de réponse - les réponses «manuelles» seront envoyées à cette adresse lorsque l'utilisateur répond à la lettre. Elle est facultative: si elle est absente, l'adresse de From est utilisée pour la réponse. Vérifiez que Répondre à:

• Il peut être généré automatiquement, c'est-à-dire unique à la lettre (permet de savoir à quelle lettre la réponse est arrivée).
• Il ne doit pas tomber dans la boîte de l'employé pour éviter de répondre aux appels, 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, des messages sur un débordement de boîte. 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 From, mais cela effraie parfois les utilisateurs lorsqu'ils répondent.
• Peut être absent, alors l'adresse De remplit ses fonctions.
• En plus de l'adresse, le nom de l'expéditeur est indiqué.

Pour adresser:

• Il doit contenir l'e-mail du destinataire (sinon il effraie le destinataire du message et protège 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é par vous).

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 la lettre. 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 <META> de la partie HTML.

Les en-têtes From:, Message-ID: et Date: doivent être formés directement dans le script pour l'envoi de la lettre (et selon les normes - avec le texte de la lettre) 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.

Conditions requises pour la structure de la lettre

Pour la partie HTML de la lettre, 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 la lettre (le cas échéant) et la structure générale de la lettre.

Selon la RFC 5322, la longueur de ligne dans une lettre ne doit pas dépasser 998 caractères 8 bits. Veuillez noter qu'en UTF-8, un personnage peut occuper plusieurs octets. Le terminateur des lignes dans l'e-mail est une paire de CRLF (<cr> ascii 13, lf> ascii 10), qui occupe 2 octets. Vous devez vérifier l'exactitude du terminateur de chaîne, car les lettres sont souvent envoyées à l'aide d'un script Unix, et dans Unix, le terminateur de ligne est un caractère lf unique - 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 cyrillique. , 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, , - , .. .
• , , , (, ). . , , , , , .
• Parce que 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 .