👩🏿‍🎨 👨🏽‍⚕️ 🧓🏽 Wie man E-Mails macht und nicht durcheinander bringt: praktische Tipps 🙋🏼 🈳 ♥️

Der Entwickler, der zum ersten Mal auf die Generierung von E-Mails gestoßen ist, hat praktisch keine Chance, eine Anwendung zu schreiben, die dies korrekt ausführt. Ungefähr 40% der von Unternehmensanwendungen generierten E-Mails weisen einen Verstoß gegen Standards und damit Zustellungs- und Anzeigeprobleme auf. Dafür gibt es Gründe: E-Mails sind technisch viel komplizierter als das Internet, E-Mails werden durch mehrere hundert Standards und eine unzählige Anzahl allgemein akzeptierter (und nicht so) Praktiken geregelt, und E-Mail-Clients sind vielfältig und unvorhersehbar. Das Testen kann die Situation erheblich verbessern, aber es gibt praktisch keine Materialien zum Testen von Post.

Mail.Ru Mail interagiert regelmäßig mit seinen Benutzern über E-Mails. In unserem Projekt werden alle Komponenten, die für die Generierung von E-Mails und sogar für einzelne Mailings verantwortlich sind, obligatorisch getestet. In diesem Artikel werden wir unsere Erfahrungen (und voller Unebenheiten) teilen.

Was sind E-Mails?

Die Anwendung kann verschiedene Arten von Buchstaben erzeugen. Sie können in mehrere Kategorien eingeteilt werden. Durch die Methode der Auswahl der Empfänger: Trigger - Selektiv - Gruppe. Nach Vereinbarung: Transaktions - Marketing - Service. Unterschiedliche Arten von Buchstaben können unterschiedliche Anforderungen haben und unterschiedliche Testskripte anwenden.

Trigger-E-Mails werden als Reaktion auf Ereignisse generiert, z. B. Benutzeraktionen oder Änderungen des Status von Systemobjekten. Sie werden von der Anwendung generiert und sind daher hinsichtlich des Testens am interessantesten. Trigger-E-Mails können sowohl Transaktions- als auch Marketing-E-Mails sein.

Benutzerdefinierte Briefe werden an eine dynamische Auswahl von Benutzern gesendet, die beliebigen Kriterien entsprechen.

Gruppennachrichten werden an eine bekannte Gruppe von Empfängern gesendet, beispielsweise an alle Benutzer oder Partner. Selektiv- und Gruppenbriefe werden meistens vermarktet. Das Versenden solcher Briefe wird manuell oder nach einem Zeitplan eingeleitet.

Transaktionsbuchstaben werden generiert, wenn ein Benutzer eine Aktion ausführt. Solche Briefe umfassen beispielsweise Rechnungen, Tickets oder Benachrichtigungen über den Lieferstatus, Briefe mit einem Zugangswiederherstellungscode usw. Transaktions-E-Mails werden immer ausgelöst. Maximale Kompatibilität ist für sie wichtig, was bedeutet, dass sie so einfach wie möglich sein sollten und an einer großen Anzahl von Kunden getestet werden müssen.

Marketingbriefe ermutigen den Benutzer, Maßnahmen zu ergreifen. Dies kann beispielsweise ein Angebot für individuelle Rabatte sein, die auf früheren Einkäufen basieren. In diesen Briefen können Transaktionsdaten verwendet werden, sie können sowohl Trigger als auch Masse sein - periodisch oder einmalig. Für diese Buchstaben ist die Effizienz wichtiger, normalerweise wird sie durch die Ergebnisse eines Split-Tests bestimmt. Einige Aspekte der Kompatibilität können für die Effizienz geopfert werden.

Gruppenmarketingbriefe, z. B. Nachrichten zu saisonalen Angeboten, Werbeaktionen und Verkäufen, werden häufig „manuell“ gesendet und sind nicht Teil Ihrer Bewerbung. Sie können (und sollten) jedoch allgemeine Testprinzipien auf diese anwenden.

Darüber hinaus kann es von Mitarbeitern erstellte Servicebriefe für automatisierte oder automatisierte CRM-, Journaling-, Auditing- oder DWH-Systeme geben. Solche Buchstaben sind Trigger, was bedeutet, dass sie auch Teil der Anwendung sind und getestet werden müssen.

Wer ist am Test- und Kontrollprozess beteiligt?

QS-Ingenieur - nimmt an allen Phasen des Prozesses teil.
Network Engineer - Verantwortlich für die Konfiguration der Netzwerk- und Messaging-Infrastruktur. Ein Netzwerktechniker sollte an der Planung von Infrastrukturtests beteiligt sein.
Ein Zustellbarkeitsspezialist ist eine Person, die die Zustellung von Briefen überwacht, die auch an der Überwachung der technischen und administrativen Parameter aller gesendeten Nachrichten teilnimmt und den Fortschritt des Versandprozesses überwacht. Er ist dafür verantwortlich, dass die gesendeten Briefe den maximal möglichen Prozentsatz der Benutzer erreichen und nicht in Spam geraten. Dafür muss der Spezialist über bestimmte Kenntnisse und Kontakte verfügen. Wenn Probleme bei der Zustellung von Briefen auftreten, muss er die wahrscheinliche Ursache verstehen und beseitigen: entweder durch Beseitigung technischer Hindernisse; oder etwas im Inhalt der Briefe ändern; oder Lösen des Problems mit dem Support-Service des Mail-Providers, an den keine Briefe gelangen. Ein solcher Spezialist (falls vorhanden) sollte auch an der Erstellung einer Checkliste und dem Testen der Infrastruktur beteiligt sein, die Anträge und Briefe generiert. Der Testprozess selbst muss jedoch unter der Kontrolle des QS-Dienstes stehen.
E-Mail-Vermarkter - Bestimmt die Effektivität von Marketingkampagnen. Unter seiner Kontrolle finden die für Marketing-Mailings erforderlichen Split-Tests für das Publikum statt. Der E-Mail-Vermarkter steuert auch die Segmentierung der Benutzerbasis, die Zusammensetzung und Häufigkeit der gesendeten E-Mails sowie die visuelle „Präsentation“ der E-Mail für den Benutzer.

Alle diese Rollen werden nicht unbedingt von einem separaten Mitarbeiter ausgeführt: Die Rolle eines Vermarkters kann von einem der Produktmanager gespielt werden, und die Rolle eines Zustellbarkeitsspezialisten kann beispielsweise von einem Support-Mitarbeiter oder einem Netzwerktechniker übernommen werden. Und bei Startups mit hoher Wahrscheinlichkeit muss dies alles von einer Person erledigt werden, und sie können sich als Qualitätsspezialist herausstellen.

Post- und Posttransport

Die Poststruktur ähnelt einem riesigen Eisberg und hat zwei Ebenen. Es gibt mehr als hundert verschiedene Standards für Post, aber fast alle gehören zu einer dieser beiden Ebenen:

Der Unterwasserteil des Eisbergs ist ein Netzwerkdienst, dessen Basisprotokoll das durch RFC 5321 definierte SMTP-Anwendungsprotokoll ist. Es ist für die Zustellung von Briefen verantwortlich. Zur Zustellung des Briefes wird ein sogenannter SMTP-Umschlag gebildet, der die Adressen des Absenders und Empfängers der SMTP-Ebene enthält. Andere Netzwerkdienste wie DNS sind ebenfalls für die Zustellung des Briefes verantwortlich. Die Hauptkomponente der Netzwerkinfrastruktur ist der Mail Transfer Agent, oder die Abkürzung MTA wird häufiger verwendet. MTA ist für die Abwicklung der Nachrichtenübermittlungswarteschlange und des Übermittlungsprozesses an die Empfängerserver verantwortlich. Beispiele für MTA sind Postfix, Sendmail, Exim und Microsoft SMTP.

Diesen Unterwasserteil des Eisbergs, der die MTA-, DNS-Parameter und andere Netzwerkparameter enthält, werden wir als Mail-Infrastruktur oder Nachrichtenübermittlungsinfrastruktur bezeichnen.

Die Oberfläche des Eisbergs ist der Buchstabe selbst. Die Grundstruktur des Briefes ist in RFC 5322 definiert. Der Brief besteht aus Service-Headern und einem oder mehreren Teilen mit Daten. Die Daten können Text in Klartext und / oder HTML, Inline-Bilder oder Anhänge fast aller Art enthalten.

Die Schnittstelle der Mail-Infrastruktur und die Grenzen der zu testenden Anwendung

Die Mail-Infrastruktur verfügt in der Regel über eine oder mehrere Schnittstellen, über die ein Brief gesendet wird (sie wird in die MTA-Zustellwarteschlange gestellt). Zum Beispiel der SMTP-Übermittlungsdienst, die Funktion mail() in PHP, die Datenübertragung an eine externe Mail- oder sendmail-Anwendung, die API interner oder externer Dienste (z. B. GetResponse, SendPulse oder Amazon SES). Wir werden diese Schnittstellen als Teil der Infrastruktur betrachten. Sehr oft gibt es eine Situation, in der Anwendung A Daten für einen Brief und eine Liste von Empfängern vorbereitet und diese dann über ihre API an Anwendung B überträgt (für Massenmailing-Marketing kann dies manuell über die Benutzeroberfläche (UI) erfolgen) und Anwendung B bereits eine E-Mail-Nachricht generiert RFC 5322-Format und stellt es irgendwie in die Warteschlange für die MTA-Zustellung. Aus Sicht von Anwendung A (und beim Testen) wird Anwendung B Teil der Mail-Infrastruktur sein. Die API oder Benutzeroberfläche der Anwendung B ist die Mail-Infrastruktur-Schnittstelle für Anwendung A. Obwohl aus Sicht von Anwendung B die Situation anders sein wird und die Mail-Infrastruktur dafür Netzwerkanwendungen oder -protokolle niedrigerer Ebene sein wird.

Definition der getesteten Parameter

Beim Testen jeder Anwendung ist es wichtig, alle von ihr verwendeten E-Mail-Infrastrukturen hervorzuheben (es können mehrere vorhanden sein) und für jede Infrastruktur die verwendeten Schnittstellen auszuwählen (es können auch mehrere für jede Infrastruktur vorhanden sein). Für jede Schnittstelle wird die Zusammensetzung und das Format der an sie übertragenen Daten so genau wie möglich bestimmt, zum Beispiel: Nachrichtentext in TEXT / HTML, Nachrichtentext in TEXT / PLAIN, Betreff der Nachricht, Empfängername, Empfängeradresse, Absendername, Absenderadresse des Briefes (RFC5321.From ), die Adresse des Absenders des SMTP-Leiters (RFC5322.mailfrom). Als nächstes wird eine Reihe von Anforderungen für jeden Parameter entwickelt (Darstellungen, Codierungen, Grenzwerte usw.), Steuerungsmethoden für jeden der Parameter werden bestimmt (auf welche Weise kann das tatsächliche Ergebnis mit dem erwarteten verglichen werden).

Typische Struktur einer generierenden Anwendung

In der Regel ist das Produkt, das wir testen, für die Erstellung des Briefes und der darin enthaltenen Daten verantwortlich. Dies ist normalerweise eine Serveranwendung (manchmal aber auch eine Clientanwendung). Es definiert die Struktur des Buchstabens, einen Teil der Service-Header, Formate für die Datenkapselung, die Darstellung von Zeichenfolgen und die Textcodierung. Ein einfaches Beispiel für eine solche Anwendung ist ein Skript, das einen Buchstaben bildet und die Funktion mail() aufruft.

Die Hauptelemente der Anwendung, die gesteuert werden müssen:

Code, der für die Erzeugung von Kopfzeilen und / oder Buchstabenstrukturen verantwortlich ist, wenn die Buchstabenstruktur dynamisch erzeugt wird, und / oder eine statische Buchstabenvorlage, die ihre Struktur beschreibt;
Layout des HTML-Teils des Briefes (idealerweise ist dies eine separate Entität oder ein Teil der Vorlage / des Layouts des Briefes, kann aber in den Anwendungscode eingenäht werden);
Ersetzung von Bewerbungsdaten in einem Brief (oder in einer Briefvorlage);
Anwendungsintegration in die Briefzustellungsinfrastruktur, die Richtigkeit der an die Infrastrukturschnittstelle übertragenen Parameter.

Was und wann zu testen

Ob es uns gefällt oder nicht, der gesamte Eisberg muss getestet werden. Es gibt mehrere Hauptkomponenten, die getestet werden müssen:

1. Lieferinfrastruktur

Der Schwerpunkt beim Testen sollte liegen auf: Zustellbarkeit von Briefen; die Richtigkeit von DNS-Einträgen, einschließlich PTR / FCrDNS-, MX- und A-Einträgen; SMTP-Protokolleinstellungen (HELO, unter Verwendung von TLS); Briefautorisierung (SPF / DKIM / DMARC); SMTP-Umschlagadressen (wenn sie nicht von der Anwendung verwaltet werden); korrekte Verarbeitung der Eingabeparameter der Infrastrukturschnittstelle; Verfolgung, Abrechnung und Verarbeitung von nicht zugestellten Briefen.

Es ist erforderlich, die Infrastruktur während der Erstimplementierung und jedes Mal zu testen, wenn Änderungen an der Infrastruktur selbst (der Konfiguration des MTA, DNS oder Netzwerkänderungen) oder der Schnittstelle zum Senden von Briefen vorgenommen werden. Verwenden einer neuen Domäne, eines neuen Netzwerks oder einer neuen API Ändern Sie die Eigenschaften der gesendeten E-Mails wie Sprache, Größe oder Menge erheblich. Erfahrungsgemäß ändert sich die Infrastruktur tendenziell, ohne den Krieg zu erklären. Daher sollten regelmäßig grundlegende Tests durchgeführt werden, auch wenn keine Informationen über Änderungen vorliegen.

Ein Netzwerktechniker und Zustellbarkeitsspezialist kann und sollte an der Erstellung des Plans und der Checklisten für Infrastrukturtests beteiligt sein.

2. Die generierende Anwendung

Sie sollten die Adressen des SMTP-Umschlags (wenn sie von der Anwendung gesteuert werden, d. H. An die Schnittstelle übertragen werden - Umschlag von, Umschlag an), die Werte der Kopfzeilen der Servicemeldungen (Datum, Nachrichten-ID, Abmelden der Liste, automatische Übermittlung usw.) steuern. S.), Briefautorisierung (DKIM / DMARC), MIME-Codierungen (base64, zitiert-druckbar), die allgemeine Korrektheit des Briefformats, z. B. das Fehlen von Nicht-ASCII-Zeichen in den Kopfzeilen, die Zusammensetzung der ersetzten Daten, das korrekte Auslösen der Auslöser, Abmeldemechanismen, Verfolgungsmechanismen Sammlung von Briefen und Statistiken (Postmaster-Header, z. B. Feedback-ID oder X-Mailru-Msgtype, sowie Tracking-Pixel) .

Sie müssen die Anwendung während ihrer Entwicklung testen, wenn Sie alle zugehörigen Komponenten ändern, die für die Generierung und Speicherung von Daten verantwortlich sind, und wesentliche Änderungen an den Briefvorlagen vornehmen, wenn Sie die verwendete Infrastruktur oder ihre Schnittstelle sowie im Rahmen allgemeiner Regressionen ändern.

3. Struktur- und Layout-Briefvorlagen (können Teil einer generierenden Anwendung sein oder werden separat entwickelt)

Die Struktur der Nachricht wird überprüft (Inhaltstyp, Inhaltsdisposition, Verschachtelung der mehrteiligen Teile des Buchstabens, Textcodierung, Zeichenfolgenparameter), der Wert des Ziels und der angezeigten Überschriften (Von, Bis, Antwort an, Betreff). Die Nachricht wird in der Liste der Buchstaben und beim Lesen angezeigt in verschiedenen Schnittstellen Mikroformate (z. B. dass ein Kalenderereignis als Kalenderereignis oder ein Flugticket als Flugticket erkannt wird), Branding.

E-Mail-Vorlagen sollten jedes Mal getestet werden, wenn Sie mindestens die geringsten Änderungen vornehmen, und auch separat, z. B. in einer Situation, in der Briefe in die Anwendung gelangen, bevor der Serverteil fertig ist.

Es wird empfohlen, dass Sie einen E-Mail-Vermarkter und Zustellbarkeitsspezialisten verwenden, um eine Checkliste zum Testen einer Briefvorlage zu erstellen.

Grundvoraussetzungen für die Überprüfung der Infrastruktur

Die für den Mailserver ausgewählte IP-Adresse sollte der IP-Adresse des Mailservers so ähnlich wie möglich sein. Es wird empfohlen, dies mit dem Dienstprogramm whois zu überprüfen. Insbesondere sollte die Absenderadresse nicht zu einem Netzwerk gehören, das als dynamisch wahrgenommen werden kann. Das ausgewählte Netzwerk muss über gültige Kontakte verfügen, an die Sie Beschwerden senden können. Das Netzwerk muss verwendet werden (Status ASSIGNED in RIPE). Die IP-Adresse muss einen korrekt konfigurierten PTR-Eintrag haben. Sie kann unabhängig über das Hosting-Control-Panel oder über den Support-Service des Anbieters konfiguriert werden. Der PTR-Datensatz muss auf den tatsächlichen Hostnamen verweisen und gleichzeitig aussagekräftig sein, sich auf dieselbe IP-Adresse zurücklösen (sogenannte FCrDNS-Prüfung), den Namen des dynamischen Hosts nicht erinnern und keine große Gruppe von Zahlen oder Zeichen enthalten. Ein gutes Beispiel ist mailserver.example.com.

Jede Domäne, die in Umschlagadressen oder Nachrichtenkopfzeilen verwendet wird, muss einen gültigen MX-Datensatz haben, der auf einen A-Datensatz des Hosts verweist, der mindestens Nachrichten über Zustellungsfehler verarbeiten kann. Bei MX ist es nicht zulässig, direkt auf eine IP-Adresse zu verweisen.

Kontrollieren Sie den Durchgang von SPF, DKIM, DMARC. Mit SPF kann der Domänenbesitzer im TXT-Datensatz eine Liste von Servern angeben, die das Recht haben, E-Mail-Nachrichten mit Absenderadressen in dieser Domäne zu senden. Es ist für die Adresse konfiguriert, die in Envelope-from (SMTP-Envelope) im Abschnitt DNS-Zonenverwaltung der Domäne verwendet wird. DKIM bietet eine Überprüfung der Urheberschaft einer Nachricht oder der Zugehörigkeit eines Absenders zu einer bestimmten Domäne mithilfe digitaler Signaturtechnologien, die der Nachricht selbst hinzugefügt werden (in ihrem DKIM-Signatur-Header). In der Regel wird eine DKIM-Signatur auf MTA-Ebene (Infrastruktur) konfiguriert. DMARC legt die Richtlinie zum Überprüfen eingehender E-Mails in einer bestimmten Domäne und von Aktionen für Briefe fest, die die SPF- oder DKIM-Authentifizierung nicht bestehen. Wenn Sie versuchen, gegen diese Richtlinie zu verstoßen, wird ein strukturierter Bericht mit Informationen zu einem solchen Versuch angezeigt. DMARC sowie SPF werden als TXT-Eintrag in der Domänenzone veröffentlicht.

Überprüfen Sie die Zustellung von Briefen an die wichtigsten Postdienste - für Russland, Mail.Ru, Yandex, GMail, Microsoft (Hotmail / Outlook.com / Office365), Rambler, nic.ru. In den Briefen müssen Sie die Richtigkeit von HELO überprüfen; Verfügbarkeit und Bestehen von Schecks PTR / FCrDNS, SPF, DKIM und DMARC; die Gültigkeit der Überschriften und der darin enthaltenen Daten, insbesondere die Synchronisation der Stunden in Datumsangaben und die Richtigkeit der Zeitzonen.

Die Bildung bestimmter Parameter, z. B. Autorisierung, Zustellbarkeit und Spam, wird von allen Komponenten ganzheitlich beeinflusst. In der Regel gibt es jedoch separate Betriebstools für deren Steuerung - DMARC- und FBL-Berichte, Postmaster-Service-APIs, E-Mail-Tracking-Tools und Zustellungsstatistiken. Beim Testen sollte der Grad der Implementierung von Tools zur Betriebsüberwachung im Unternehmen berücksichtigt werden. Wenn beispielsweise keine Betriebsüberwachung von DMARC-Berichten vorliegt, sollten Sie regelmäßig die E-Mail-Autorisierung testen, wenn keine operative Überwachung der Zustellbarkeit vorliegt. Überprüfen Sie regelmäßig, wie und wo Briefe eingehen, auch wenn keine Entwicklung im Zusammenhang mit dem Versenden von Briefen vorliegt nicht durchgeführt.

Um die Infrastruktur zu überprüfen, können Sie spezielle Dienste verwenden, z. B. mail-tester.com , mxtoolbox.com . Detaillierte Anforderungen an die Infrastruktur finden Sie in diesem Artikel .

Autorisierungsanforderungen

Das Überprüfen des Durchgangs von SPF, DKIM, DMARC ist normalerweise mithilfe des Headers Authentication-Results auf dem Server des Empfängers möglich.

Überprüfen Sie die Gültigkeit des SPF-Eintrags auf Syntax, das Limit für DNS-Abfragen (z. B. mithilfe von mxtoolbox.com). Bei der Bildung eines SPF sollten alle Mailing-Quellen berücksichtigt werden (vergessen Sie nicht die CRM-Systeme, alle verwendeten Bereitstellungsinfrastrukturen, einschließlich derer, über die einmalige Marketingkampagnen durchgeführt werden). Es wird empfohlen, zulässige Server für die Domäne über die Liste der Netzwerke ('ip4' / 'ip6') festzulegen. SPF wird aus dem SMTP-Umschlag auf die Absenderadresse überprüft. Stellen Sie sicher, dass die SMTP-Umschlagdomäne (Envelope-from) mit der Domäne aus dem From-Header übereinstimmt. Häufige SPF-Fehler sind in diesem Artikel aufgeführt .

Überprüfen Sie den DKIM-DNS-Eintrag, die Gültigkeit und Zusammensetzung der DKIM-Signatur. Stellen Sie sicher, dass Sie einen DKIM-Schlüssel mit mindestens 1024 Bit verwenden. Empfohlener Hash-Modus der DKIM-Signatur: entspannt / entspannt. Stellen Sie sicher, dass alle wichtigen Header signiert sind (Von, Bis, Betreff, Datum, Nachrichten-ID, MIME-Version, Inhaltstyp), dass Tracking-Header (Empfangen, Geliefert an, Rückgabepfad) nicht signiert sind und DKIM für validiert ist grundlegende Postdienste. Richten Sie die Weiterleitung an einen der Mail-Dienste an einen anderen ein. DKIM sollte weitergeleitete Briefe nicht "schlagen". Stellen Sie sicher, dass die DKIM-Signaturdomäne mit der Absenderdomäne aus dem From-Header übereinstimmt.

Überprüfen Sie DMARC auf grundlegende Mail-Dienste. Suchen Sie nach DMARC-Berichten, identifizieren Sie SPF und DKIM und beheben Sie Fehler für alle IP-Adressen Ihrer Infrastruktur.

Stellen Sie sicher, dass Nachrichten mithilfe von Verschlüsselung (TLS) an externe Server übermittelt werden. Manchmal können Sie anhand des empfangenen Headers auf dem Server des Empfängers nach TLS suchen: Geben Sie beispielsweise das ESMTPS-Protokoll oder das Vorhandensein von Parametern des Formulars an (Version = TLS1_2-Verschlüsselung = ECDHE-RSA-AES128-GCM-SHA256-Bits = 128/128). zeigt das Vorhandensein von TLS an.

Überprüfung der generierenden Anwendung

Anforderungen an die Postanschrift

Umschlagadressen
Wir beginnen die Überprüfung der generierenden Anwendung mit den Adressen im SMTP-Umschlag.

Umschlagadressen sind Adressen auf der Ebene der E-Mail-Infrastruktur. Sie sind für den Benutzer nicht sichtbar, aber für die Zustellung wichtig, da der Brief, in den der Brief gelangt, genau durch die Adresse des Umschlags bestimmt wird.

Die Adresse des Empfängers in einem Umschlag (Envelope-to, auch bekannt als RCPT TO :) ist die Adresse, an die der Brief tatsächlich zugestellt wird.

Für alle Briefe mit Ausnahme der Registrierung muss die Adresse gemäß den administrativen Anforderungen gesetzlich unterschrieben und für den Versand validiert sein.
Für Newsletter muss die Adresse "live" sein, Adressen, an die Briefe nicht regelmäßig zugestellt werden können, sollten als inaktiv markiert werden, Mailings an sie sollten nicht erfolgen. Einige Kategorien von Briefen (z. B. Zugriffswiederherstellung) müssen jedoch möglicherweise auch an Adressen gesendet werden, die zuvor als inaktiv markiert wurden.

Absenderadresse in einem SMTP-Umschlag (normalerweise als Envelope-from, smtp.mailfrom oder Return-Path bezeichnet) - An diese Adresse werden Nachrichten über die Unfähigkeit, einen Brief zu senden, und automatische Antworten gesendet. Diese Adresse ist für den Benutzer nicht sichtbar. Diese Adresse wird auch für die SPF-Autorisierung verwendet. Wir überprüfen Folgendes:

Adresse ist verfügbar;
Es ist nicht die Adresse des Mitarbeiters und wird nicht an ihn weitergeleitet, um automatische Antworten, Nachrichten über Unzugänglichkeit usw. auszuschließen.
Es wird von einem Skript verarbeitet, das Adressen unzugänglicher Benutzer als inaktiv markiert.
die Adresse kann automatisch erzeugt werden, d.h. einzigartig für jeden Buchstaben;
Ein Brief an diese Adresse sollte nicht zur Erzeugung eines Antwortschreibens führen, z. B. einer Nachricht über einen Boxüberlauf.

E-Mail-Header-Adressen

Diese Adressen sind entweder für den Benutzer direkt sichtbar oder werden bei der Beantwortung eines Briefes verwendet.

Absenderadresse (Von :) Überschrift ist die Adresse und der Absendername, die in der Liste der Buchstaben und beim Lesen eines Briefes angezeigt werden. Wir überprüfen Folgendes:

Dies ist eine "von Menschen lesbare" freundliche Adresse, die das Unternehmen identifiziert.
Es enthält nicht nur E-Mail, sondern auch den Namen des Absenders.
noreply @ ist möglich, aber nur, wenn wir betonen möchten, dass wir keine Antwort auf den Brief erwarten und er nicht gelesen wird. Es ist besser, diese Idee im Text des Briefes zu duplizieren.
Bei Vorhandensein von Nicht-ASCII-Zeichen (z. B. kyrillisch) muss der Absendername gemäß MIME codiert werden, die Domäne bei Vorhandensein von Nicht-ASCII-Zeichen muss in Punycode codiert werden.
Briefe derselben Kategorie sollten dieselbe Adresse haben, die Verwendung automatisch generierter Adressen ist nicht zulässig. Dies liegt an der Tatsache, dass From: am häufigsten von Personen verwendet wird, um Buchstaben mithilfe von Filtern in Ordner zu sortieren.
Die Adresse sollte für Transaktions-, Marketing- und Dringlichkeitsbriefe (z. B. Briefe des Support-Service) unterschiedlich sein (vorzugsweise in verschiedenen Subdomains). Dies liegt auch daran, dass der Benutzer Marketing-E-Mails als Spam markieren oder in einem unlesbaren Ordner filtern kann.
Die Absenderadresse und die SMTP-Umschlagadresse müssen sich in derselben Domäne oder in Unterdomänen derselben Organisationsdomäne befinden, damit der SPF innerhalb des DMARC übergeben werden kann.
Die Adresse muss aus der Domäne der Organisation stammen. Es ist nicht akzeptabel, kostenlose Mail-Dienste und andere öffentliche Mail-Domänen in From zu verwenden, da solche Mailings die SPF- und DKIM-Authentifizierung im Rahmen von DMARC nicht bestehen.

Antwortadresse - "Manuelle" Antworten werden an diese Adresse gesendet, wenn der Benutzer auf den Brief antwortet. Es ist optional: Wenn es nicht vorhanden ist, wird die Adresse von Von für die Antwort verwendet. Überprüfen Sie die Antwort auf:

Es kann automatisch erzeugt werden, d.h. einzigartig für den Brief (ermöglicht es Ihnen herauszufinden, auf welchen Brief die Antwort kam).
Es sollte nicht in die Box des Mitarbeiters fallen, um das Beantworten von Anrufen zu vermeiden, sondern sollte idealerweise in CRM „verpackt“ sein.
Es kann eine automatische Standardantwort für CRM generieren, sollte jedoch nichts Überflüssiges generieren, z. B. Nachrichten über einen Boxüberlauf. Bei der Generierung von automatischen Antworten müssen Maßnahmen ergriffen werden, um Schleifen zu vermeiden. Diese sind in RFC 3834 aufgeführt.
Es kann von jeder Domain stammen, die nicht unbedingt mit From übereinstimmt, aber manchmal macht dies den Benutzern bei der Beantwortung Angst.
Kann fehlen, dann führt die From-Adresse ihre Funktionen aus.
Zusätzlich zur Adresse wird der Name des Absenders angegeben.

Anzusprechen:

Es sollte die E-Mail des Empfängers enthalten (andernfalls macht es dem Empfänger der Nachricht Angst und schützt den Anti-Spam).
Idealerweise sollte es den Namen des Empfängers enthalten. Wenn der Name jedoch unbekannt oder zweifelhaft ist (z. B. wurde die Adresse noch nicht bestätigt), ist es besser, ihn nicht anzugeben (jemand kann die Adresse eines anderen mit einem schlechten Namen eingeben und der Empfänger wird möglicherweise von Ihnen beleidigt).

Anforderungen an den E-Mail-Header

Die tatsächliche Codierung des Textes sollte mit der in der Kopfzeile angegebenen übereinstimmen. Es wird empfohlen, in allen Überschriften und Teilen des Briefes eine Codierung zu verwenden. Es wird empfohlen, UTF-8 als weit verbreitetes zu verwenden. Die Codierung wird in den Content-Type-Headern und im <META> -Tag des HTML-Teils angegeben.

Die Überschriften From :, Message-ID: und Date: müssen direkt im Skript zum Senden des Briefes (und standardmäßig - zusammen mit dem Text des Briefes) und immer im richtigen Format gebildet werden. Wenn sie fehlen oder falsch gebildet sind, kann einer der Transitserver diese Header hinzufügen, was zu einer Verletzung der Integrität der DKIM-Signatur führt.

8-Bit-Zeichen in den Kopfzeilen, einschließlich der Betreffzeile (Betreff) und der Namen der angehängten Dateien (Inhaltstyp und Inhaltsdisposition), sollten fehlen. Alle Nicht-ASCII-Zeichen, einschließlich Kyrillisch, müssen in Anführungszeichen oder Base64 codiert werden.

Anforderungen an die Struktur des Briefes

Für den HTML-Teil des Briefes ist es wünschenswert, einen alternativen Text (einfachen) Teil zu bilden. Es ist auch erforderlich, die Konformität und Lesbarkeit des Klartextteils des Briefes (falls vorhanden) und die allgemeine Struktur des Briefes zu überprüfen.

Gemäß RFC 5322 sollte die Zeilenlänge in einem Buchstaben 998 8-Bit-Zeichen nicht überschreiten. Bitte beachten Sie, dass in UTF-8 ein Zeichen mehrere Oktette belegen kann. Der Terminator der Zeilen in der E-Mail ist ein Paar CRLF (<cr> ascii 13, lf> ascii 10), das 2 Oktette belegt. Sie müssen die Richtigkeit des Zeichenfolgenterminators überprüfen, da Briefe häufig mit einem Unix-Skript gesendet werden. Unter Unix besteht der Zeilenabschluss aus einem einzelnen lf-Zeichen. Dies ist ein Fehler für E-Mails. Sie sollten auch überprüfen, ob die Zeichenfolgenterminatoren UTF-8-codierte Zeichen unterbrechen: Sie können das Vorhandensein eines Zeichenfolgenterminators zwischen zwei Oktetten desselben Zeichens, z. B. Kyrillisch, nicht zulassen. , 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, , - , .. .
, , , (, ). . , , , , , .
Weil 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 .

Wie man E-Mails macht und nicht durcheinander bringt: praktische Tipps