Wie man E-Mails erstellt und nicht durcheinander bringt: Praktische Tipps

Ein Entwickler, der zum ersten Mal E-Mails generiert hat, hat fast keine Chance, eine Anwendung zu schreiben, die dies korrekt ausführt. Rund 40% der von Unternehmensanwendungen generierten E-Mails verstoßen gegen einen Standard. Aus diesem Grund treten Probleme bei der Zustellung und Anzeige auf. Dafür gibt es Gründe: E-Mails sind technisch schwieriger als das Internet, und der Betrieb von E-Mails wird durch einige hundert Standards sowie eine unzählige Anzahl allgemein anerkannter (und weniger) Praktiken geregelt, während die E-Mail-Clients vielfältiger sind und unvorhersehbar als Browser. Das Testen kann die Situation erheblich verbessern, aber Materialien, die zum Testen des E-Mail-Systems bestimmt sind, sind praktisch nicht vorhanden.

Mail.ru interagiert regelmäßig per E-Mail mit seinen Benutzern. In unseren Projekten unterliegen alle Komponenten, die für die Generierung von E-Mails und sogar einzelne Mailings verantwortlich sind, obligatorischen Tests. In diesem Artikel werden wir unsere Erfahrungen teilen (aus unseren Fehlern lernen).

• Welche Art von E-Mails gibt es?
  
• Wer ist am Test- und Kontrollprozess beteiligt?
  
• Versand und Posttransport
  
• Die Schnittstelle der E-Mail-Infrastruktur und die Grenzen der getesteten Anwendung
  
• Definition von Testparametern
  
• Typische Struktur einer generierenden Anwendung
  
• Was und wann zu testen
  
  • Lieferinfrastruktur
    
  • Anwendung generieren
    
  • Strukturelle und setzende E-Mail-Vorlagen
    
• Grundvoraussetzungen für die Überprüfung der Infrastruktur
  
• Authentifizierungsanforderungen
  
• Überprüfung der generierenden Anwendung
  
  • Anforderungen an E-Mail-Adressen
    
    • Umschlagadressen
      
    • E-Mail-Header-Adressen
      
  • Anforderungen an Header
    
  • Anforderungen an die Struktur der E-Mail
    
  • URI-Anforderungen
    
  • Anforderungen an das E-Mail-Layout
    
• Split-Tests durchführen
  

Welche Art von E-Mails gibt es?

Die Anwendung kann verschiedene Arten von E-Mails generieren. Sie können in mehrere Kategorien eingeteilt werden. Durch die Methode der Auswahl der Empfänger - persönlich / ausgelöst - selektive Gruppe. Nach Vereinbarung: Transaktions- Marketing-Service. Sie können unterschiedliche Anforderungen für verschiedene E-Mail-Typen festlegen und verschiedene Testszenarien anwenden.

Ausgelöste persönliche E-Mails werden als Reaktion auf Ereignisse generiert, z. B. Benutzeraktionen oder Statusänderungen von Systemobjekten. Sie werden von der Anwendung generiert und sind daher im Hinblick auf das Testen am interessantesten. Ausgelöste E-Mails können Transaktions-, Marketing- und Service-E-Mails sein. Selektive E-Mails werden an eine dynamische Auswahl von Benutzern gesendet, die bestimmte Kriterien erfüllen. Gruppen-E-Mails werden an eine permanente Gruppe von Empfängern gesendet, z. B. an alle Benutzer oder Partner. Selektive und Gruppen-E-Mails werden häufig für Marketingzwecke verwendet, und das Senden solcher E-Mails wird manuell oder nach einem Zeitplan gestartet.

Transaktions-E-Mails werden generiert, wenn ein Benutzer eine Aktion ausführt. Solche E-Mails umfassen beispielsweise Rechnungen, Tickets oder Lieferstatusbenachrichtigungen. Transaktions-E-Mails werden immer ausgelöst und sollen wichtige Informationen enthalten. Sie sollten so einfach und kompatibel wie möglich sein, und sie sollten auf einer großen Anzahl von E-Mail-Clients getestet werden.

Marketing-E-Mails ermutigen den Benutzer, Maßnahmen zu ergreifen. Dies kann beispielsweise ein Angebot für einen persönlichen Rabatt sein, der auf früheren Einkäufen basiert. Transaktionsdaten können in diesen E-Mails verwendet werden, und sie können E-Mails oder Massen-, periodische oder einmalige E-Mails ausgelöst werden. Für diese E-Mails ist die Effizienz wichtiger, und die Ergebnisse des Split-Tests bestimmen dies normalerweise. Einige Aspekte der Kompatibilität können für die Effizienz geopfert werden.

Gruppenmarketing-E-Mails, z. B. Nachrichten zu saisonalen Angeboten, Werbeaktionen und Verkäufen, werden häufig manuell gesendet und sind nicht Teil Ihrer Anwendung. Sie können (und sollten) jedoch auch allgemeine Testprinzipien auf diese anwenden.

Es können auch Service-E-Mails vorhanden sein: Benachrichtigungen, die für die Mitarbeiter generiert wurden, für automatisierte CRM-Systeme, Journaling, Auditing oder DWH. Solche E-Mails sind normalerweise ausgelöste E-Mails, dh sie sind auch Teil der Anwendung und müssen getestet werden.

Wer ist am Test- und Kontrollprozess beteiligt?

1. QS-Ingenieur - nimmt an allen Phasen des Prozesses teil.
   
2. Netzwerktechniker - verantwortlich für die Konfiguration der Netzwerkinfrastruktur und der Infrastruktur für die Nachrichtenübermittlung. Der Netzwerktechniker sollte in die Planung und das Testen der Infrastruktur einbezogen werden.
   
3. Zustellungsspezialist - Person, die die Zustellbarkeit von E-Mails überwacht, die auch an der Überwachung der technischen und administrativen Parameter aller gesendeten E-Mails beteiligt ist und den Fortschritt des Versandprozesses überwacht. Er ist dafür verantwortlich, dass die gesendeten E-Mails den höchsten Prozentsatz der Benutzer erreichen und nicht in Spam geraten. Zu diesem Zweck muss der Spezialist über spezifische Kenntnisse und Kontakte verfügen. Wenn es Probleme mit der Zustellung von E-Mails gibt, muss er die wahrscheinliche Ursache verstehen und beseitigen. entweder durch Beseitigung technischer Hindernisse; oder etwas im Inhalt der E-Mails ändern; oder versuchen Sie, das Problem mit dem Support-Service des Mail-Anbieters zu lösen, den die E-Mails nicht erreichen. Ein solcher Spezialist (falls vorhanden) sollte auch an der Erstellung der Checkliste und dem Testen der Infrastruktur zur Erstellung von Anwendungen und E-Mails beteiligt sein. Der Testprozess selbst sollte jedoch unter der Kontrolle des QS-Dienstes stehen.
   
4. E-Mail-Vermarkter - bestimmt die Wirksamkeit von Marketing-Newslettern. Unter seiner Kontrolle findet der Split-Test für die Verteilung des Marketings an 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 engagierten Mitarbeiter ausgeführt. Die Rolle des Vermarkters kann von einem der Produktmanager übernommen werden, und die Rolle des Lieferspezialisten kann beispielsweise von einem Support-Mitarbeiter oder einem Netzwerktechniker übernommen werden. In Start-up-Unternehmen ist es sehr wahrscheinlich, dass all dies von einer Person erledigt werden muss, und sie können sich als Qualitätsspezialist herausstellen.

Versand und Posttransport

Die E-Mail-Struktur ähnelt einem massiven Eisberg und besteht aus zwei Ebenen. Es gibt mehr als hundert verschiedene Standards für E-Mails, aber fast alle gehören zu einer dieser beiden Ebenen:

Der Unterwasserteil eines Eisberg- Netzwerkdienstes, dessen Basisprotokoll das in RFC 5321 definierte SMTP-Anwendungsprotokoll ist. Es ist für die Zustellung von E-Mails verantwortlich. Für die Zustellung der E-Mail 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 der E-Mail verantwortlich. Die Hauptkomponente der Netzwerkinfrastruktur ist der Mail Transfer Agent (MTA). Der MTA ist dafür verantwortlich, die Nachrichtenübermittlungswarteschlange und den Übermittlungsprozess selbst an die Empfängerserver zu übergeben. MTA-Beispiele sind Postfix, Sendmail, Exim und Microsoft SMTP.

In diesem Unterwasserteil des Eisbergs, der die MTA-, DNS-Parameter und andere Netzwerkparameter enthält, werden wir die E-Mail-Infrastruktur oder die Nachrichtenübermittlungsinfrastruktur nennen.

Die Spitze des Eisbergs - die E-Mail selbst. Die Grundstruktur der E-Mail wird durch den Standard-RFC 5322 definiert. Die E-Mail besteht aus Service-Headern und einem oder mehreren Datenteilen. Die Daten können in einem Nur-Text-Format und / oder HTML oder sogar AMP mit Inline-Bildern oder Anhängen fast aller Art vorliegen.

Die Schnittstelle der E-Mail-Infrastruktur und die Grenzen der getesteten Anwendung

Die E-Mail-Infrastruktur verfügt in der Regel über eine oder mehrere Schnittstellen, über die eine E-Mail gesendet wird (wenn sie in die MTA-Zustellwarteschlange eingeht). Zum Beispiel der SMTP-Übermittlungsdienst, die Funktion mail() in PHP, die Datenübertragung an eine externe Mail- oder Sendmail-Anwendung, die API für den internen oder externen Dienst (wie GetResponse, SendPulse oder Amazon SES). Wir werden diese Schnittstellen als Teil der Infrastruktur betrachten. Es kommt häufig vor, dass Anwendung A Daten für eine E-Mail und eine Liste von Empfängern vorbereitet und diese dann über ihre API an Anwendung B sendet (für die Vermarktung von Massenmailings kann dies manuell über die Benutzeroberfläche erfolgen) und Anwendung B generiert eine E-Mail-Nachricht in RFC 5322 und übermittelt sie an den MTA. Für Anwendung A (und beim Testen) ist Anwendung B Teil der E-Mail-Infrastruktur. Die API oder Benutzeroberfläche von Anwendung B ist für die Schnittstelle von Anwendung A der E-Mail-Infrastruktur vorgesehen. Obwohl für Anwendung B die Situation anders sein wird und die E-Mail-Infrastruktur dafür Netzwerkanwendungen oder -protokolle niedrigerer Ebene sein wird.

Definition von Testparametern

Beim Testen jeder Anwendung ist es wichtig, alle von ihr verwendeten Mail-Infrastrukturen auszuwählen (es können mehrere vorhanden sein) und für jede Infrastruktur die verwendeten Schnittstellen herauszusuchen (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, z. B. E-Mail-Text in TEXT / HTML, E-Mail-Text in TEXT / PLAIN, E-Mail-Betreff, Empfängername, Empfängeradresse, Absendername, Absenderadresse (RFC5321.From), die Adresse des Absenders des SMTP-Konvektors (RFC5322.mailfrom). Als nächstes wird eine Reihe von Anforderungen für jeden Parameter entwickelt (Darstellungen, Codierungen, Grenzwerte usw.), Methoden zur Überwachung jedes Parameters werden bestimmt (wie das tatsächliche Ergebnis mit dem erwarteten verglichen wird).

Typische Struktur einer generierenden Anwendung

In der Regel ist dasselbe Produkt, das wir testen, für die Generierung von E-Mails und Daten verantwortlich. Dies ist normalerweise eine Serveranwendung (manchmal aber auch eine Clientanwendung). Es definiert die Struktur der E-Mail, einen Teil der Service-Header, Datenkapselungsformate, Zeichenfolgendarstellungen und Textcodierung. Ein einfaches Beispiel für eine solche Anwendung ist das Skript, das die E- mail() bildet und die Funktion mail() aufruft. Die Hauptelemente der Anwendung, die gesteuert werden müssen, sind:

• den Code, der für die Generierung von Headern und / oder E-Mail-Strukturen verantwortlich ist, wenn die E-Mail-Struktur dynamisch generiert wird, und / oder statische E-Mail-Vorlagen, die ihre Struktur beschreiben;
  
• HTML-Layout der E-Mail (im Idealfall handelt es sich um eine separate Entität oder einen Teil der E-Mail-Vorlage / des E-Mail-Layouts, kann jedoch in den Anwendungscode eingebettet werden);
  
• Ersetzen von Anwendungsdaten in eine E-Mail (oder in eine E-Mail-Vorlage);
  
• Integration der Anwendung in die E-Mail-Zustellungsinfrastruktur, die Richtigkeit der an die Infrastrukturschnittstelle übergebenen Parameter.
  

Was und wann zu testen

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

Lieferinfrastruktur

Der Schwerpunkt der Tests sollte auf folgenden Punkten liegen: Zustellbarkeit von E-Mails; korrekte DNS-Einträge, einschließlich PTR / FCrDNS-, MX- und A-Einträge; SMTP-Protokollparameter (HELO, TLS verwenden); E-Mail-Autorisierung (SPF / DKIM / DMARC); SMTP-Umschlagadressen (wenn die Anwendung sie nicht verwaltet); Richtigkeit der Verarbeitung der Eingabeparameter der Infrastrukturschnittstelle; Verfolgung, Aufzeichnung und Verarbeitung von nicht zugestellten E-Mails.

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 einer E-Mail vorgenommen werden. Verwenden einer neuen Domäne, eines neuen Netzwerks oder einer neuen API; Zusätzliche Tests sind erforderlich, wenn sich die Eigenschaften der gesendeten E-Mails wie Sprache, Größe oder Anzahl erheblich ändern. Erfahrungsgemäß ändert sich die Infrastruktur "von selbst", daher sollten regelmäßig grundlegende Tests durchgeführt werden, auch wenn keine Informationen über Änderungen vorliegen.

Es ist möglich und notwendig, den Netzwerktechniker und den Zustellbarkeitsspezialisten in die Erstellung des Plans und der Checklisten zum Testen der Infrastruktur einzubeziehen.

Anwendung generieren

Die Adressen des SMTP-Umschlags sollten überwacht werden (wenn die Anwendung sie steuert, dh sie werden an die Schnittstelle übertragen - Umschlag von, Umschlag an), die Werte der Service-Header der E-Mail (Datum, Nachricht) -ID, List-Unsubscribe, Auto-Submitted usw.). Klausel), E-Mail-Autorisierung (DKIM / DMARC), MIME-Codierung (base64, zitiert-druckbar), allgemeine Korrektheit des E-Mail-Formats, z. B. das Fehlen von Nicht-ASCII-Zeichen in den Headern, die Zusammensetzung der injizierten Daten , das korrekte Auslösen von Triggern, das Abbestellen von Mechanismen, das Schreiben und Sammeln von Statistiken durch Verfolgungsmechanismen (Postmaster-Header, z. B. Feedback-ID oder X-Mailru-Msgtype, sowie das Verfolgen von Pixeln).

Es ist erforderlich, eine Anwendung während ihrer Entwicklung zu testen, wenn sich alle zugehörigen Komponenten, die für das Generieren und Speichern von Daten verantwortlich sind, ändern, wobei sich die E-Mail-Vorlagen erheblich ändern, wenn die verwendete Infrastruktur oder Schnittstelle zu ihr geändert wird, sowie im Rahmen von allgemeine Regressionen.

Strukturelle und setzende E-Mail-Vorlagen (können Teil einer generierenden Anwendung sein oder werden separat entwickelt)

Die Struktur der E-Mail wird überprüft (Inhaltstyp, Inhaltsdisposition, Verschachtelung von mehrteiligen Teilen der E-Mail, Textcodierung, Zeichenfolgenparameter), der Wert des Ziels und die angezeigten Überschriften (Von, Bis, Antwort an, Betreff) ), die Art und Weise, wie E-Mails in der Liste der E-Mails angezeigt werden, und beim Lesen 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, sowie separat, z. B. in Situationen, in denen E-Mails in die Anwendung gelangen, bevor der Serverteil bereit ist.

Es wird empfohlen, einen E-Mail-Marketing-Spezialisten und einen Zustellbarkeitsspezialisten hinzuzuziehen, um eine Checkliste zum Testen einer E-Mail-Vorlage zu erstellen.

Grundvoraussetzungen für die Überprüfung der Infrastruktur

Die für den Mailserver ausgewählte IP-Adresse sollte so nah wie möglich an der IP-Adresse des Mailservers liegen. Es wird empfohlen, dies mit dem Dienstprogramm whois zu überprüfen. Insbesondere sollte die Absenderadresse nicht zum Netzwerk gehören, was als dynamisch empfunden werden kann. Das ausgewählte Netzwerk muss über aktive Kontakte verfügen, an die Beschwerden gesendet werden können. Das Netzwerk muss verwendet werden (in RIPE den Status ASSIGNED haben). Die IP-Adresse muss über einen ordnungsgemäß konfigurierten PTR-Eintrag verfügen. Sie kann unabhängig über das Hosting-Control-Panel oder mithilfe des Dienstanbieters konfiguriert werden. Ein PTR-Datensatz muss auf den tatsächlichen Hostnamen verweisen und dennoch aussagekräftig sein, auf dieselbe IP-Adresse zurückgeführt werden (sogenannte FCrDNS-Prüfung), den Namen des dynamischen Hosts nicht erinnern und darf keine große Gruppe von Zahlen oder Zeichen enthalten. Ein gutes Beispiel ist mailserver.example.com.

Jede Domain, die in Umschlagadressen oder E-Mail-Headern verwendet wird, muss einen gültigen MX-Datensatz haben, der auf einen Host-A-Datensatz verweist, der mindestens unzustellbare Nachrichten verarbeiten kann. MX darf nicht direkt auf eine IP-Adresse verweisen.

Kontrollieren Sie den Durchgang von SPF, DKIM, DMARC. Mit SPF kann der Domäneninhaber in den TXT-Datensätzen eine Liste von Servern angeben, die zum Senden von E-Mails mit Absenderadressen in dieser Domäne berechtigt sind. Es ist für die Adresse konfiguriert, die im Umschlag von (SMTP-Umschlag) im Abschnitt Verwalten von DNS-Zonen der Domäne verwendet wird. DKIM bietet eine Überprüfung der Urheberschaft einer Nachricht oder ihres Absenders für eine bestimmte Domäne mithilfe digitaler Signaturtechnologien, die der E-Mail 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 E-Mails fest, die die SPF- oder DKIM-Authentifizierung nicht bestehen. Bei dem Versuch, gegen diese Richtlinie zu verstoßen, enthält ein strukturierter Bericht Informationen zu einem solchen Versuch. DMARC sowie SPF werden als TXT-Eintrag in der Domänenzone veröffentlicht.

Überprüfen Sie die Zustellbarkeit von E-Mails an die wichtigsten Postdienste - für Russia Mail.Ru, Yandex, Gmail, Microsoft (Hotmail / Outlook.com / Office365), Rambler, nic.ru. In den eingetroffenen E-Mails müssen Sie die Richtigkeit von HELO überprüfen. das Vorhandensein und Bestehen von Schecks PTR / FCrDNS, SPF, DKIM und DMARC; die Gültigkeit der Header und Daten in ihnen, insbesondere die Synchronität der Uhr in den Daten und die Richtigkeit der Zeitzonen.


(Die Registrierungsmail hat die Authentifizierung aufgrund der verwendeten Freemail-Adresse unterbrochen.)

Die Bildung einiger Parameter, z. B. Autorisierung, Zustellbarkeit und Spam, wird von allen Komponenten ganzheitlich beeinflusst. Zu ihrer Kontrolle gibt es jedoch normalerweise separate Betriebstools - DMARC- und FBL-Berichte, Postmaster-Service-API, E-Mail-Tracking-Tools, Zustellungsstatistiken. Bei den Tests sollte der Grad der Implementierung von Tools zur Betriebsüberwachung im Unternehmen berücksichtigt werden. Wenn beispielsweise keine operative Kontrolle über DMARC-Berichte vorliegt, sollte die Autorisierung von E-Mails regelmäßig getestet werden, während in Ermangelung einer operativen Kontrolle der Zustellbarkeit, wo und wie die E-Mails verlaufen, auch wenn es keine Entwicklung im Zusammenhang mit dem Senden von E-Mails gibt.

Zum Testen der Infrastruktur können Sie spezielle Dienste verwenden, z. B. mail-tester.com, mxtoolbox.com. Detaillierte Anforderungen an die Infrastruktur finden Sie in diesem Artikel .


(ein Beispiel für den kaputten SPF-Rekord)

Authentifizierungsanforderungen

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 Mailingquellen berücksichtigt werden (CRM-Systeme, alle derzeit genutzten Bereitstellungsinfrastrukturen, einschließlich derer, über die einmalige Marketingkampagnen durchgeführt werden, nicht vergessen). 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 (https://medium.com/hackernoon/myths-and-legends-of-spf-d17919a9e817).

Ü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ückweg) nicht signiert sind und DKIM ist für grundlegende Mail-Dienste validiert. Richten Sie die Weiterleitung an einen der Mail-Dienste an einen anderen ein. DKIM sollte weitergeleitete E-Mails nicht "schlagen". Stellen Sie sicher, dass die DKIM-Signaturdomäne mit der Absenderdomäne aus dem 'Von'-Header übereinstimmt.

Überprüfen Sie DMARC auf grundlegende E-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. Sie können manchmal anhand des empfangenen Headers auf dem Server des Empfängers nach TLS suchen: Geben Sie beispielsweise das ESMTPS-Protokoll an oder haben Sie Parameter der Form (Version = TLS1_2-Chiffre = ECDHE-RSA-AES128-GCM-SHA256-Bits = 128/128). zeigt das Vorhandensein von TLS an.

Überprüfung der generierenden Anwendung

Anforderungen an die E-Mail-Adresse

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 die Adresse des Umschlags bestimmt, in welches Postfach die E-Mail geht.

Die Empfängeradresse im Umschlag ( envelope-to , auch bekannt als RCPT TO: ist die Adresse, an die die E-Mail tatsächlich zugestellt wird.

• Für alle E-Mails mit Ausnahme der Registrierung muss die Adresse gemäß den administrativen Anforderungen gesetzlich signiert und für den Versand validiert sein.
  
• Für Newsletter muss die Adresse "live" sein. Adressen, an die E-Mails nicht regelmäßig zugestellt werden können, sollten als inaktiv markiert werden. Mailings an sie sollten nicht erfolgen. Einige Kategorien von E-Mails (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 , MAIL FROM: oder Return-Path ) - An diese Adresse werden Nachrichten über die Unfähigkeit, eine E-Mail 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:

• Die 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 generiert werden, dh für jede E-Mail eindeutig.
  
• Eine E-Mail an diese Adresse sollte nicht zur Generierung einer Antwort-E-Mail führen, z. B. einer Nachricht über einen Postfachüberlauf.
  

E-Mail-Header-Adressen

Diese Adressen sind entweder für den Benutzer direkt sichtbar oder werden beim Beantworten einer E-Mail verwendet.
Absenderadresse (der Header From: ist die Adresse und der Absendername, die in der Liste der E-Mails und beim Lesen einer E-Mail angezeigt werden. Wir überprüfen Folgendes:

• Dies ist eine lesbare, freundliche Adresse, die das Unternehmen identifiziert.
  
• Es enthält nicht nur eine E-Mail-Adresse, sondern auch den Namen des Absenders.
  
• Noreply @ ist möglich, aber nur, wenn wir betonen möchten, dass wir keine Antwort auf die E-Mail erwarten und diese nicht gelesen wird. Es ist besser, diese Idee im Text der E-Mail 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
  
• E-Mails derselben Kategorie sollten dieselbe Adresse haben. Die Verwendung von automatisch generierten Adressen sollte vermieden werden. Dies liegt an der Tatsache, dass "Von:" am häufigsten von Personen verwendet wird, um E-Mails mithilfe von Filtern nach Ordnern zu sortieren.
  
• Die Adresse sollte für Transaktions-, Marketing- und dringende E-Mails (z. B. E-Mails vom 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 Adresse From: und die SMTP-Umschlagadresse müssen sich in derselben Domäne oder in Subdomä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: da solche Mailings die SPF- und DKIM-Authentifizierung im Rahmen von DMARC nicht bestehen.
  

Die Adresse Reply-to - 'manuelle' Antworten werden an diese Adresse gesendet, wenn ein Benutzer eine E-Mail beantwortet. Es ist optional. Wenn es nicht vorhanden ist, wird die Adresse von 'From:' für die Antwort verwendet. Überprüfen Sie, ob 'Antwort an':

• Es kann automatisch generiert werden, dh nur für die E-Mail (ermöglicht es Ihnen herauszufinden, auf welche E-Mail die Antwort eingegangen ist).
  
• Es sollte nicht in das Postfach des Mitarbeiters fallen, um eine automatische Antwort zu vermeiden, sondern sollte idealerweise in CRM "verpackt" werden.
  
• Es kann eine standardmäßige automatische CRM-Antwort generieren, sollte jedoch nichts Überflüssiges generieren, z. B. Postfachüberlauf oder "On Vocation" -Nachrichten. 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.
  

Die Adresse To:

• Muss die E-Mail des Empfängers enthalten (andernfalls macht es dem Empfänger der Nachricht Angst und stört 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 kann beleidigt sein).
  

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 Kopfzeilen und Teilen der E-Mail eine Codierung zu verwenden. Es wird empfohlen, UTF-8 als weit verbreitetes zu verwenden. Die Codierung wird in den Content-Type-Headern und im Tag des HTML-Teils angegeben.

Die Überschriften From :, Message-ID: und Date: sollten direkt im Skript zum Senden der E-Mail (und standardmäßig - zusammen mit dem Text der E-Mail) und immer im richtigen Format erstellt 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.


(Registrierungsbestätigung in seltsamer Codierung)

Anforderungen an die Struktur der E-Mail

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

Gemäß RFC 5322 sollte die Länge einer Zeile in einer E-Mail 998 8-Bit-Zeichen nicht überschreiten. Bitte beachten Sie, dass in UTF-8 ein Zeichen mehrere Oktette belegen kann. Der Terminator von Zeilen in einer E-Mail ist ein Paar CRLF (ASCII 13, ASCII 10), das 2 Oktette benötigt. Sie müssen die Richtigkeit des String-Terminators überprüfen, da E-Mails häufig mit einem Unix-Skript gesendet werden. Unter Unix besteht der String-Terminator aus einem einzelnen 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. dem kyrillischen Symbol, nicht zulassen. Um solche Situationen zu vermeiden, muss der Text vor dem Erstellen der E-Mail unterbrochen oder der Text in base64 codiert werden. Base64 hat normalerweise eine feste Zeilenlänge.

Es ist notwendig, die korrekte Kennzeichnung von Anhängen und Inlines zu überprüfen, dh die Richtigkeit der Bildung der Überschriften "Inhaltsdisposition: Inline", wenn es sich um ein in der E-Mail angezeigtes Bild handelt, oder "Inhaltsdisposition: Anhang". Wenn die angehängte Datei zum Download vorgesehen ist.

Die Struktur der E-Mail sollte so einfach wie möglich sein: Insbesondere sollte es nicht mehr als einen mehrteiligen Teil jedes Typs geben (gemischt, alternativ, verwandt), und mehrteilig / gemischt wird nur verwendet, wenn die E-Mail Dateianhänge enthält, mehrteilig / related - Wenn HTML mit Inline-Bildern geliefert wird, mehrteilig / alternativ - bei Vorhandensein von Klartext und HTML-Teilen. Im Allgemeinen sollte die Struktur der E-Mail ohne Anhänge und Inline-Bilder folgendermaßen aussehen:

mehrteilig / alternativ
- Text / Klartext
- Text / HTML

Die Reihenfolge der Teile ist wichtig. Text / Plain muss VOR Text / HTML oder Multipart / Related stehen. Dies ist erforderlich, damit der HTML-Teil standardmäßig angezeigt wird. Nur wenn seine Anzeige aus irgendeinem Grund nicht verfügbar ist, wird der einfache Teil angezeigt.

Wenn die E-Mail Inline-Bilder enthält, sollte ihre Struktur folgendermaßen aussehen:

mehrteilig / alternativ
- Text / Klartext
- mehrteilig / verwandt
—— Text / HTML
—— Bild / ... (Inline-Bild)
—— Bild / ... (Inline-Bild)

Inline-Bilder müssen Content-Disposition: Inline haben und sich ausschließlich innerhalb des mehrteiligen / verwandten Teils befinden.
Im schwierigsten Fall, wenn sowohl Inline-Bilder als auch angehängte Dateien vorhanden sind, hat die E-Mail die folgende Struktur:

mehrteilig / gemischt
- mehrteilig / alternativ
—— Text / Klartext
—— mehrteilig / verwandt
——— Text / HTML
——— image / png
——— image / png
...
- application / octet-string (Inhaltsdisposition: Anhang)
- application / octet-string (Inhaltsdisposition: Anhang)
...
mehrteilige verwandte und mehrteilige / alternative Teile müssen vor Anhängen geschlossen werden, Anhänge gehören zum externen mehrteiligen / gemischten Teil)


(Registrierungsmeldung mit falscher Teilestruktur)

URI-Anforderungen

Alle URIs (in src, href-Attributen, Stilen usw.) müssen das Protokoll und den Hostnamen (https://example.com/somepath) enthalten. Typische Fehler sind die Verwendung relativer Links (/ somepath) und das Fehlen eines Protokolls (//example.com/somepath), was für E-Mails nicht akzeptabel ist, da in diesen das Standardprotokoll möglicherweise file:// lautet.

• Alle Dienst- und Nicht-ASCII-Zeichen (insbesondere kyrillisch) in der URI müssen mit Prozentcodierung codiert werden.
  
• Ein als Text eingefügter Link (dh für den Benutzer als URL und nicht als Text sichtbar) sollte weiterhin mit dem Tag <> , da der Benutzer sonst nicht darauf klicken kann. Einige Webmails markieren solche Links selbst, dies ist jedoch kein Standardverhalten. In diesem Fall muss die href-Adresse in A mit dem Linktext übereinstimmen. Andernfalls reagiert der Inhaltsfilter möglicherweise auf einen solchen Link, um den Benutzer zu täuschen. Dies ist besonders dann zu beachten, wenn es "Clicker" gibt, die die Übergänge des Benutzers von der E-Mail verfolgen.
  
• Es ist besser, sich auf die Verwendung der Protokolle http:// , https:// und mailto:
  
• Bei hohen Sicherheitsanforderungen sollten Sie die Verwendung von http:// zugunsten von https:// vollständig aufgeben.
  
• Nicht standardmäßige Ports sollten nicht verwendet werden (z. B. example.com : 8080 / somepath), da sie für den Benutzer möglicherweise nicht zugänglich sind.
  
• Das Klicken auf den Link im HTML-Teil sollte ohne zusätzliche Bestätigung durch den Benutzer auf der Seite nicht zu Änderungen des Status der Anwendung (Abonnement, Abbestellen, Stornierung der Bestellung usw.) führen, da einige Inhaltsfiltersysteme dies unabhängig voneinander tun können Überprüfen Sie die Sicherheit eines solchen Übergangs, indem Sie eine Referenzseite anfordern. Die E-Mail-Anwendung kann die Vorschau der Seite über den Link beim Hover anzeigen, und moderne Browser können die Seite laden, bevor der Benutzer auf den Link klickt, um die Ladezeit zu verkürzen (in der Webanwendung wird im Allgemeinen nicht empfohlen, Änderungsaktionen für die Seite durchzuführen GET-Anforderung, alle Änderungsanforderungen müssen POST oder PUT durchlaufen.
  
• Das Klicken auf den Link im Header "List-Unsubscribe" sollte im Gegensatz dazu keine zusätzlichen Aktionen des Benutzers erfordern, da das Abbestellen über diesen Link normalerweise per E-Mail-Programm oder Webmail im Namen des Benutzers erfolgt. Außerdem gibt es einen neuen Header List-Unsubscribe-Post, der von RFC 8058 eingeführt wurde.
  
• Sie sollten nicht erwarten, dass der Benutzer die E-Mail liest und dem Link in demselben Browser folgt, in dem er die Aktion initiiert, die zum Senden der E-Mail führt (z. B. ein Konto registriert). Der Link sollte in jedem anderen Browser oder Mobilgerät funktionieren. Insbesondere kann der Benutzer den Link öffnen, ohne autorisiert zu sein oder in einem anderen Konto als dem, an das die E-Mail gesendet wurde.
  
• Weil die Länge des URI begrenzt werden kann; Sie sollten für große Objekte keine URIs vom Typ 'data:' verwenden. Verwenden Sie aus demselben Grund keine URIs, die in Hyperlinks zu lang sind.
  
• Sie dürfen keine externen Link-Shortener verwenden. Dies wirkt sich negativ auf die Zustellung von E-Mails aus. Es ist besser, wenn alle Links auf Ihre Domain verweisen. Dadurch werden die potenziellen negativen Auswirkungen des Rufs einer anderen Person auf die Zustellung von E-Mails verringert.
  
• Platzieren Sie keine externen Bilder auf öffentlichen Diensten oder kostenlosem Hosting, verwenden Sie keinen zuverlässigen Hosting-Service oder CDN mit guter Leistung und gutem Ruf.
  

(ungültiger Bild- und Anker-URI aufgrund fehlender Protokollspezifikation)

Anforderungen an das E-Mail-Layout

Warum ist es so schwierig, E-Mails zu erstellen?

E-Mail-Clients zeigen auf die eine oder andere Weise Benutzerinhalte in ihrer Benutzeroberfläche an. Dies kann möglicherweise zu verschiedenen Sicherheitsproblemen führen - Cross-Site-Scripting (XSS, Crossite-Scripting), Schnittstellen-Spoofing, DOM-Clobbering, Benutzer-Deanonymisierung / Informationsverlust (z. B. IP-Adresse des Benutzers oder Cookies durch externe Anforderungen) usw. Daher hat jeder Mail-Dienst und jede Mail-Anwendung einen gewissen Schutz gegen jede Angriffsklasse. Leider gibt es keinen einheitlichen Ansatz für die Organisation dieses Schutzes. Es kann organisiert werden durch:

• isolierte begrenzte Rahmen,
  
• Filtern von Tags und / oder Attributen,
  
• Einschränkungen der absoluten Positionierung,
  
• Verbot oder Einschränkung der Verwendung von Blockstilen (was für das adaptive Layout von entscheidender Bedeutung ist),
  
• Das standardmäßige Sperren externer Elemente (dh das Herunterladen externer Bilder erfordert eine Benutzererlaubnis) oder das Verwenden eines Proxys, um auf sie zuzugreifen.
  
• Konvertieren von HTML-E-Mails in ein anderes Zwischenformat (z. B. verwendet Microsoft Exchange / Outlook RTF, was es äußerst schwierig machen kann, Elemente in Outlook mit herkömmlichen Methoden ordnungsgemäß anzuzeigen).
  
• Verbot oder Einschränkung der Verwendung von Formularen oder deren einzelnen Elementen.
  

Die E-Mails verwenden auch bestimmte Elemente wie Inline-Bilder und URI cid:// , deren Unterstützung möglicherweise eingeschränkt ist. Beispielsweise unterstützt Mozilla Thunderbird cid:// für Hintergrundbilder nicht.

Sogar eine korrekt geformte E-Mail kann aufgrund der Besonderheiten ihrer Implementierung und Filterung des Inhalts der E-Mail in verschiedenen Benutzeroberflächen unterschiedlich angezeigt werden.

Wenn das E-Mail-Format fehlerhaft ist, ist das Verhalten völlig unvorhersehbar. Beispielsweise können E-Mail-Clients ein anderes Verhalten mit falschen URIs aufweisen oder die falsche Header-Formatierung wird anders behandelt. Die automatische Erkennung der Textcodierung funktioniert auch anders, wenn sie nicht oder falsch angegeben ist. Daher muss die E-Mail in verschiedenen Benutzeroberflächen angezeigt werden: Die korrekte Anzeige der E-Mail in einer Benutzeroberfläche bedeutet nicht, dass sie korrekt zusammengesetzt ist (selbst die korrekte Anzeige der E-Mail in allen Benutzeroberflächen garantiert nicht, dass keine vorhanden ist Probleme mit der Anzeige in der Zukunft).



Folgende Punkte sind zu beachten:

• Überprüfen Sie den Text der E-Mail auf semantischen Inhalt, Anzeige, Fehlen von Tippfehlern, syntaktischen, Rechtschreib- und lexikalischen Fehlern.
  
• Überprüfen Sie die Richtigkeit der Ersetzung der Anwendungsdaten in der Vorlage oder im Layout der E-Mail.
  
• Überprüfen Sie die Richtigkeit der Mengen, Daten, Zahlen, Waren und sonstigen Angaben unter Berücksichtigung der zulässigen Randbedingungen. Die Daten sollten ein Jahr haben (einige Benutzer geben das Feld sehr selten ein). Eine Zeitzone muss rechtzeitig vorhanden sein. Die Adresse muss eine Stadt enthalten, und in einigen Fällen muss das Land angegeben werden.
  
• Überprüfen Sie gegebenenfalls den Betriebsstatus aller Links in der E-Mail.
  
• In E-Mails, die vor Bestätigung der Adresse verschickt wurden, inkl. E-Mails mit einem Bestätigungslink, es sollte kein von außen kontrollierter Text vorhanden sein, auch nicht der Benutzername. Andernfalls können sie für Spam verwendet werden (in dem in der E-Mail angezeigten Feld, z. B. im Namen, wird Spam-Text eingefügt und Die Adresse ist die angegebene Adresse des Opfers. Wenn Sie beispielsweise im Namen Ihres Dienstes einen obszönen Text an die Adresse des Entwicklers senden können, liegt ein Problem vor.
  
• Überprüfen Sie, ob externe Dienste in Diensten von Drittanbietern fehlen. Dies kann sich auf die Lieferung auswirken und Informationen über Ihre Kunden preisgeben.
  
• Überprüfen Sie die Verfügbarkeit von Zählern zum Senden, Zustellen, Lesen von E-Mails und Übergängen. Einige von ihnen befinden sich in der E-Mail selbst (z. B. das Gegenpixel zum Lesen der E-Mail), andere werden vom Mailer verfolgt, aber in der Regel sind alle im Admin-Bereich des Mailers verfügbar.
  
• Überprüfen Sie die Richtigkeit der Abonnementkategorie und die Abmeldung des Benutzers für diese Kategorie über den Link in der E-Mail.
  
• Überprüfen Sie, wie die E-Mail aussieht:
  
  • Beliebte Webversionen von E-Mails für ein Zielland: Die "großen Drei" für Russland sind Mail.Ru, Yandex, Gmail. Sie können auch Rambler und Outlook.com hinzufügen.
    
  • Mobile Anwendungen der oben genannten E-Mail-Anbieter;
    
  • Standardmäßige mobile Anwendungen mit IMAP unter Berücksichtigung beliebter mobiler Plattformen für mindestens iPhone, Pixel (Android-Referenzplattform), Samsung (am häufigsten für Android) und MIUI (belegt in Russland den zweiten Platz für Android-Plattformen);
    
  • Verschiedene Desktop-Browser: Chrome, Firefox, Edge, Internet Explorer, Opera usw.;
    
  • Desktop-Anwendungen (E-Mail-Programme), insbesondere Thunderbird, Outlook und Apple Mail, optional The Bat! und Opera Mail;
    
  • Beliebte Unternehmenslösungen mit einer Weboberfläche (Exchange, möglicherweise Roundcube, Communigate, Zimbra, SquirrelMail) - für B2B-Lösungen;
    
  • Vergessen Sie nicht, das Layout sowohl auf Retina-Monitoren als auch auf Monitoren mit niedrigerer Auflösung zu überprüfen.
    
• Bei der Prüfung müssen Sie jeweils Folgendes beachten:
  
  • Übergeben der Berechtigungsheader SPF / DKIM / DMARC.
    
  • E-Mail-Download-Geschwindigkeit: Es sollte schnell geladen werden und nicht seine Zeit in Anspruch nehmen.
    
  • Anzeigen einer E-Mail in der Liste der E-Mails: Avatar, Name des Absenders und Betreff, der in das Snippet der Nachricht fällt, ob die Kategorie korrekt definiert wurde (z. B. wenn die Reihenfolge nicht in die Kategorie "Soziale Netzwerke" fällt).
    
  • Das Layout der E-Mail als Ganzes: Wenn das Layout konsistent blieb, gab es falsche Wortumbrüche usw., auch beim Skalieren und Ändern der Fenstergröße.
    
  • Schriftarten sollten nicht klein oder schwer lesbar sein.
    
  • Hintergrundbilder und Hintergrundfarben.
    
  • Passend zum Markenbuch.
    
  • Einfache Ausführung der in der E-Mail implizierten Aktionen. Wenn die E-Mail beispielsweise einen Bestätigungscode oder andere Informationen enthält, die möglicherweise irgendwo gespeichert werden müssen, sollte sie nicht nur gut gelesen, sondern auch bequem in der mobilen Oberfläche ausgewählt und kopiert werden können.
    
  
  
• Behalten Sie die Gesamtgröße der E-Mail (einschließlich externer Bilder) im Auge und achten Sie darauf, dass sie vernünftige Werte nicht überschreitet. Je länger die Ladezeit ist, desto wahrscheinlicher ist es, dass eine Person negativ darauf reagiert.
  
• Sogar E-Mails, die nicht geändert wurden, sollten regelmäßig überprüft werden, da Änderungen auf der Seite des Postdienstes auftreten können und beispielsweise ein zuvor unsichtbares Problem "aufdecken".
  
• Einige Parameter müssen in allen Tests kontrolliert werden. Beispielsweise können Probleme beim Übergeben der DKIM-Authentifizierung auf Probleme in der Infrastruktur (Probleme mit DNS oder die Bildung einer DKIM-Signatur, Zeitsynchronisationsfehler) sowie auf Fehler im Generierungsprogramm zurückzuführen sein (Absenderadresse ist falsch gebildet, falsche Zeichen in Die Header fehlen oder sind obligatorisch. Von-, Datums- oder Nachrichten-ID-Header wurden dupliziert.) und aufgrund von Inhaltsfehlern (falsche Zeilenabschlusszeichen, zu lange Zeilen, falsche Adressen). Gleichzeitig wird die E-Mail möglicherweise nicht "geschlagen", und das Problem tritt möglicherweise bei keinem Dienst auf.
  

Split-Tests durchführen

Marktforschung geht über den Rahmen dieses Artikels hinaus, es sollten jedoch einige wichtige Punkte erwähnt werden, die die Qualität von E-Mails erheblich beeinflussen.

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