2.7.2024 – was ist eigentlich mit E-Mails los?

#tagebuchbloggen

Letzte Woche am Telefon: „Ach, Sie haben ja um zehn einen Akupunktur-Termin – wenn Sie dann jetzt noch einen kurzen Besprechungstermin brauchen – wollen Sie nicht einfach um viertel vor zehn schon kommen?“ fragte die kluge MFA am Telefon und ich wollte. Warum ich dann heute Morgen trotzdem erst um viertel vor zwölf aus der Praxis kam – ich weiß es nicht genau. Warum die Wartezeit hauptsächlich zwischen Besprechung und nadeln lag, erst recht nicht. An mir lags aber nicht.
Und bevor ich sie im Besprechungstermin fragen konnte, warum sie denn diesen blöden Fehler auf der letzten Überweisung gemacht hatte, der mir eine wirklich unangenehme halbe Stunde beim Facharzt beschert hatte, fragte sie mich, warum sie das denn gemacht habe und alles hinterließ ein etwas unbefriedigtes Gefühl und ich muss dann wohl noch mehr aufpassen demnächst.

Der Rest des Tages war bis auf eine Kleinigkeit auch Warten und weil die Kleinigkeit zufällig bestens mit einer Frage aus dem Wunsch-Doc korrespondiert, ist heute Wunsch-Doc-Tag!

Sie fragen, Christian antwortet

Können Sie mir erklären, warum ich seit kurzem so viele eMails mit einer Fehlermeldung zurückbekomme? Oder ist das gar nicht Ihr Fachgebiet?

Nein, das ist streng genommen nicht mein Fachgebiet – aber im Alltag hab ich im Moment eh dauernd damit zu tun, also frohgemut los!

Ich muss etwas ausholen – Sie wissen ja, ich kann nicht kurz: E-Mail wurde Anfang der 70er erfunden – also deutlich vor dem www – und damals waren die Zeiten in vieler Hinsicht andere. Zum Beispiel hatte niemand über einen möglichen Missbrauch der neuen Technik nachgedacht und deswegen ist E-Mail ziemlich unsicher – und alle Sicherungsmaßnahmen sind irgendwie nachträglich dran gebaut. Meist mit viel Gaffa.

Eine Mail nimmt – nur ganz leicht verkürzt – folgenden Weg mit vier Schritten: Jemand verfasst eine E-Mail und benutzt seinen Server, um die Nachricht auf den Weg zu schicken; sie kommt am Server des Empfängers an und der ruft die Mail dann vom Server ab und liest sie.
Also so:
1) Paul schreibt eine Mail an Paula.
2) Er benutzt seinen Anbieter mit der Domain hmbl.blog als Absender-Server. Dieser Server übermittelt die Mail
3) an den Empfangs-Server gmx.de, wo Paula ihre E-Mail-Adresse hat.
4) Paula ruft ihr Postfach ab und liest.
Unser heutiges Problem geschieht nur in den Schritten 2 und 3.

Für Adobe Firefly sieht dieser Ablauf übrigens so aus. Naja.

Vorweg: Wenn Sie Ihre E-Mails über einen E-Mail-Anbieter wie GMX oder GMAIL versenden, dann müssen Sie sich um all das nicht kümmern. Erst wenn Sie eine Domain besitzen und eine E-Mail-Adresse wie name@ihre-domain.de benutzen, sollten Sie oder ein Fachmann – und deswegen hab ich damit zu tun – zumindest mal nachsehen, ob Ihr Domainanbieter – also Strato, 1und1, domainfactory, … – das alles gut erledigt hat.

Zurück: Als das alles erfunden wurde, da kannten sich alle 17 Menschen mit E-Mail-Adresse persönlich und es war zB nicht einmal nötig abzusichern von welchem der beiden existierenden Versand-Server eine Mail verschickt wurde. Man brauchte nicht mal Login-Daten, um einen Versand-Server dazu zu bewegen, eine Mail zu versenden – diese Absicherung kam auch erst einiges später.
Außerdem steht es jedem von uns vollkommen frei, im E-Mail-Programm als Absenderadresse einzutragen was wir wollen – auch da gab es zuerst keine Prüfung – und ich kann Ihnen noch heute eine Mail schicken, bei der zumindest Ihr Mailprogramm mit hoher Wahrscheinlichkeit behauptet, sie käme von obama@whitehouse.gov. Oder von pope@holychair.va.

Heute sind geschätzt die Hälfte der täglichen 330 Milliarden Mails Spam und ca Anfang des Jahres haben relativ spontan Google und Yahoo beschlossen, endlich mal was zu tun. Sie wenden dazu drei schon länger existierende Sicherheitsmechanismen endlich mal ernsthaft an und damit hatten wir den Kladderadatsch.

Alle drei Sicherheitsmechanismen greifen in dem Moment, wo Paulas Empfangs-Server von pauls Absender-Server die Anfrage bekommt, doch bitte eine E-Mail anzunehmen.

1) SPF
Pauls Mail kommt bei Paulas Server an und der sagt: „Ach guck, eine Mail. Würdest Du, lieber Absender-Server bitte erst kurz Dein Zettelchen mit Pauls Liste der erlaubten Versand-Sever zeigen? Ah prima, Du stehst drauf, die Mail nehm ich.
Paul bzw Pauls Serveradministrator müssen also so ein Liste anlegen.

2) DKIM
Pauls Mail kommt bei Paulas Server an und der sagt: „Ach guck, eine Mail. Zusammen mit der Mail kam eine verschlüsselter Textzeile zu der Du ein passendes gegenstück haben solltest – zeigst Du, lieber Absender-Server mir bitte das passende Gegestück? Ah prima, die passen zueinander, die Mail nehm ich
Paul bzw Pauls Serveradministrator müssen also diese Schlüssel anlegen.

3) DMARC
DMARC ist eine Ergänzung zu den ersten beiden Mechanismen, die festlegt, was passieren soll, wenn SPF und DKIM nicht greifen. Deswegen beschließen aktuell viele Administratoren, dass DMARC nicht wichtig ist, wenn sie doch SPF und DKIM eingerichtet haben.

Falls Sie einen winzigen Schritt tiefer einsteigen wollen: Hier sind diese drei Techniken exakt genauso launig, aber technisch wenigstens etwas präziser erklärt.

So, das klingt doch alles vernünftig, warum also Kladderadatsch?
Zum einen, weil Google wirklich überraschend plötzlich diesen Schritt gegangen ist. Die großen E-Mail-Anbieter konnten recht schnell reagieren, aber eben nicht jede, die ihre eigene Domain hat. Außerdem wird das ganze komplizierter, wenn Sie zB einen Newsletter bertreiben – denn dann muss der Server des Newsletter-Anbieters auch auf die Listen und die Anbieter waren oft nicht schnell genug und stellten die notwendigen Infos nicht bereit. Oder die Webhoster hatten die Möglichkeit für solche externen Dienstleister nicht mitgedacht.
Das hat sich allerdings schon fast komplett wieder eingespielt.

Aktuell ist das Hauptproblem: Größere und auch schon kleinere Firmen betreiben gerne ihren eigenen Mailserver. Zum einen müssen also viele tausende IT-Admins in Firmen sich plötzlich in die Materie einlesen und die entsprechenden Einstellungen beim Versand-Server vornehmen, um noch Mails verschicken zu können.
Und zweitens – und das beobachte ich häufig – richten sie dann auch gleich auf dem eigenen Empfangs-Server die gleichen Sicherheitsmaßnahmen ein. Oder das, was sie dafür halten und dann sind ihre Server auf einmal etwas übervorsichtig.
Jedenfalls habe ich noch nie so oft wie im letzten halben Jahr die Anfragen bekommen: „Herr Fischer, ich versuche Mails zu verschicken / verschicke wie immer meinen Newsletter, aber ich krieg ganz viele Fehlermeldungen zurück
Nahezu immer ist die Lösung dann, dass die IT des Mail-Empfängers ihre Empfangsserver viel zu streng eingstellt hat – d.h. sie haben das, was sie glauben, dass Google und Co es tun, auf ihre eigenen Server übernommen, schieben die Schuld aber zum Absender. Der bekommt dann eine Fehlermeldung, fühlt sich ebenso schuldig wie ahnungslos und ruft mich an.
FunFact am Rande: Diese Fehlerlmeldungen sind nicht irgendwie genormt – ich kann also nicht mal googeln, was der Admin mir sagen will.

Was am Ende bleibt: Viele unzufriedene Anfragen, weil man pünktlich zur neuen eigenen Website oder zum frisch eingerichteten Newsletter auf einmal keine Mails mehr an die Firmenkunden schicken kann.

Ja, so ist das und jetzt wissen Sie, warum ihre Newsletter nicht mehr problemlos rausgehen und auch, womit ich mich so rumschlage, obwohl ich doch eigentlich nur Pixel schieben und ein bisschen Code schreiben wollte.

Sie mögen das, wenn ich auch mal aus dem täglichen Alltags-Einerlei ausbreche und über Gott und die Welt nachdenke und möchten diese Arbeit unterstützen? Hier steht eine virtuelle Kaffeekasse!
Oder – wenn Ihnen Geld zu unpersönlich ist – hier ist meine Wishlist.

Die Website setzt 1 notwendiges Cookie. Ich nutze Matomo, um zu sehen, welche Artikel Sie interessieren. Matomo ist lokal installiert es werden keine Cookies gesetzt, so dass Sie dort vollkommen anonym bleiben. Externe Dienste werden erst auf Ihre Anforderung genutzt.