Hast Du schon einmal ein Mail an eine Gmail Adresse geschickt und das Mail wurde mit folgender Fehlermeldung abgewiesen?
Reason: 4.3.2 – Not accepting messages at this time (‚421‘, This message does not have authentication information or fails to pass authentication checks. To best protect our users from spam, the message has been blocked. Please visit https://support.google.com/mail/answer/81126#authentication for more information.
Und nach ein paar weiteren Versuchen des Mailservers dann:
Reason: 5.4.7 – Delivery expired (message too old) [Outgoing] (‚421‘, This message does not have authentication information or fails to pass authentication checks. To best protect our users from spam, the message has been blocked. Please visit https://support.google.com/mail/answer/81126#authentication for more information
Oder noch besser, das Mail wurde von Gmail angenommen, aber klammheimlich in den Spam-Folder einsortiert, auch wenn es sich um eine ganz normale persönliche Mitteilung handelt, weder Spam noch sonstiges Massenmail?
Das Verhalten von Google ist für Aussenstehende völlig intransparent: Manche Mails werden abgewiesen, manche gelöscht, manche werden problemlos zugestellt. Es scheint, dass die Mailzustellung per IPv6 restriktiver eingeschränkt wird als per IPv4. Was genau aber Google an den Mails zu kritisieren hat, wird aber leider nicht bekanntgegeben.
Laut der Fehlermeldung und den Angaben unter obigem Link möchte Google also, dass unsere Mails authentisiert sind. Abgesehen davon, dass man die Authentizität von Mails besser durch eine S/MIME Signatur sicherstellen würde: Zur hier gemeinten Authentisierung von Mails gibt es aktuell zweieinhalb Verfahren: SPF, DKIM und DMARC. Weil diese entgegen der obigen Aussage von Google nichts mit der Vermeidung von Spam zu tun haben, möchte ich diese Verfahren hier und den folgenden Artikeln (etwas vereinfacht) erklären.
SPF
- Ziel: Verhinderung von Mail Spoofing: Kein Fremder soll Mails in meinem Namen verschicken können.
- Wie: In einem DNS TXT Record wird hinterlegt, welche Server Mails mit einer bestimmten Absenderdomain schicken dürfen und welche nicht.
- Der empfangende Mailserver
- überprüft den Hostnamen im EHLO/HELO und vergleicht ihn mit dem SPF Record.
- überprüft die Domain im Envelope MAIL FROM und vergleicht sie mit dem SPF Record.
Beispiel
dig avantec.ch txt +short
„v=spf1 MX -all“
Dies bedeutet, dass nur die im MX DNS Record hinterlegten Mailgateways Mails mit der Absenderadresse «avantec.ch» verschicken dürfen. Dies wären also folgende 4 IP Adressen:
$ dig avantec.ch mx +short
20 mail2.avantec.ch.
10 mail.avantec.ch.
$ dig mail.avantec.ch a mail.avantec.ch aaaa +short
194.191.40.74
2001:67c:1300:141::74
$ dig mail2.avantec.ch a mail2.avantec.ch aaaa +short
194.191.40.94
2001:67c:1300:141::94
Probleme
Somit dürfen nur noch unsere eigenen Mailgateways Mails in unserem Namen verschicken. Dies war in diesem Fall ja einfach!
Als Mail-Admin in einem Firmenumfeld aber herauszufinden, wer alles (berechtigterweise) seine Maildomäne benutzt, ist gar nicht so einfach. Werden gewisse Dienste bei AWS oder Azure betrieben und verschicken Statusmails? Wird ein Webserver irgendwo extern gehostet? Verschickt die Marketing-Abteilung Newsletter via einen externen Dienstleister? Verwendet das HR eine Recruitment Plattform, welche Mails verschickt? All diese Quellen müssen in den SPF DNS Record aufgenommen werden, sonst werden diese potentiell von den Empfängern abgelehnt.
Angenommen, auch diese Hürde ist genommen und alle berechtigten Mailsender sind identifiziert: Sind damit nun alle meine Mailprobleme gelöst? Keineswegs! Zwar nimmt jetzt Google (wenn ich Glück habe) meine Mails an, dafür habe ich mir ein anderes Problem eingehandelt: Hat einer meiner Mailempfänger eine Mailweiterleitung eingerichtet (bei der nicht ein neues Envelope MAIL FROM gesetzt wird), so werden meine Mails nicht beim Ziel ankommen. Denn der weiterleitende Server ist natürlich nicht im SPF Record als berechtigter Sender hinterlegt.
«Damit kann ich leben, dafür kann jetzt niemand mehr Mails spoofen und sich als mich ausgeben!» Leider nein, denn SPF stützt sich nur auf den sogenannten Envelope. Ich erkläre dies an einem normalen Brief in einem Couvert: Auf dem Couvert steht die Absender- und Empfänger-Adresse. Diese werden von der Post zur Briefzustellung verwendet. Entsprechend verwendet ein Mailserver (MTA) den Envelope zur Mailzustellung. Dieser Envelope wird durch SPF geschützt. Die Person, welche den Brief erhält, schaut aber primär auf den Kopf des eigentlichen Briefes. Entsprechend zeigt ein Mailclient wie Outlook nicht den Envelope, sondern den Absender aus dem Mailheader.
Ein Phisher, welcher sich als Absender meiner Maildomäne ausgeben will, fälscht also nicht den Envelope, sondern den Mailheader und wird in seinem Vorhaben durch SPF keineswegs eingeschränkt!
Zusammenfassung
- SPF hilft nicht gegen Spam.
- Google und andere grosse Mailempfänger zwingen uns unter dem Vorwand der Spam-Verhinderung SPF einzuführen.
- SPF hilft nur beschränkt gegen Spoofing und Phishing.
- SPF macht Probleme mit Mailweiterleitungen.
- Es ist schwierig herauszufinden, welche Absender in den SPF Record eingetragen werden müssen.
Zugegeben, das Mail Protokoll SMTP stammt aus den Anfangszeiten des Internets und ist tatsächlich nicht mehr ganz zeitgemäss. Andererseits ist es – wie es schon der Name sagt – simpel, zuverlässig, dezentral und funktioniert. Ergänzungen wie SPF erhöhen die Komplexität, sorgen dafür, dass Mails nicht mehr zuverlässig zugestellt werden können und lösen Probleme, welche gar nicht bestehen. Aus diesen Gründen bin ich kein grosser Fan von SPF. Trotzdem nötigen uns die paar wenigen grossen Mailboxbetreiber, diese Technologien umzusetzen.
Ob die weiteren Mail Authentisierungs-Erweiterungen DKIM und DMARC besser abschneiden und wie man diese am besten implementiert, werde ich in einem der folgenden Artikel erläutern.
Links:
Alles über E-Mail Security: https://www.avantec.ch/themen/e-mail-security/
Der Beitrag SPF/DKIM/DMARC oder warum Google meine Mails nicht mag erschien zuerst auf Tec-Bite.