💾 Archived View for data.konfusator.de › 2023-07-04_smtp_schmerzen.gmi captured on 2023-11-14 at 07:42:53. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

SMTP Schmerzen

SMTP ist ein wirkliches Urgestein des Internets - es war schon alt, als ich das erste Mal im Internet unterwegs war. Damals (Anfang der Neunziger) war noch RFC 821¹ aktuell, der tatsächlich aus dem November 1981 stammt. Es gibt mittlerweile zwei neue RFCs (2821² und 5321³), wobei selbst RFC 5321 bald seinen 15. Geburtstag feiert. Die größeren Fortschritte beim Thema Email sind eher im Bereich der Verwaltung und Abholung der zugestellten Mails beim Empfänger passiert – meine ersten Mails lagen noch im Spool-Verzeichnis der empfangenden Ultrix Maschine; dann folgten POP und IMAP für Mail-Clients und schließlich Web-Clients.

Das Grundprinzip bei SMTP blieb immer gleich: Eine Mail wird beim Server des Versenders eingeliefert, der stellt anhand der Adresse fest, an welchen Server gesendet werden soll und liefert die am zuständigen Server ab. Das ist ein wesentlicher Unterschied zum Web und zu den gängigen Instant-Messengern: Dort ist nur ein Server beteiligt, mit dem sich gegebenenfalls mehre Clients verbinden – eine Kommunikation zwischen Servern ist nicht vorgesehen (wenn man von der internen Abläufen des Anbieters absieht). Für den Anbieter ist das gut – er hat die komplette Kommunikation in der Hand. Für den Kunden ist das zwiespältig: Einerseits ist es einfacher, weil es nur einen Ansprechpartner gibt, anderereseits ist er für den entsprechenden Dienst vom Anbieter abhängig.

Bei SMTP kommt ein wohlbekanntes Ärgernis hinzu: Spam und Phishing. Weil jeder Server aufsetzen kann auch jeder Mails einliefern, was in einer vernünftigen Welt ein guter Gedanke wäre. Leider leben wir nicht in der besten aller Welten (sorry, Leibnitz), so dass bei einem offenen und kostenlosen System Leute auftauchen, die es zu ihrem Vorteil oder aus Zerstörungslust missbrauchen wollen. Sie liefern über offene Relays (gibt es seit Jahren praktisch nicht mehr), nachlässige Dienstleister (sendgrid zum Beispiel), gehackte Accounts oder eigene Mailserver nervige bis gefährliche Mails ein. Der SMTP-Standard bietet dagegen wenig Schutz, und letztlich gibt es in einem verteilten System auch wenig Schutz. Mit Verfahren wie DKIM kann man beweisen, dass Mails wirklich von der angegebenen Domain stammen, mit DMARC kann man sogar sagen, dass unsignierte Mails verworfen werden sollen. Das bringt nur nichts, wenn man zum Beispiel eine DHL-Phishing-Kamnpagne auf dh1.pe laufen lässt (die eins erkannt? Unter bmi.bund.pe wurden munter falsche Meldungen zum Ukrainekrieg verbreitet – mit 1:1 geklautem Design von bmi.bund.de⁴) und DMARC und DKIM ordentlich einrichtet. Technisch ist dann alles sauber. Auch gegen gehackte Accounts helfen weder SPF noch DKIM oder DMARC.

Damit landen wir beim wirklich unerquicklichen: Google und die domain reputation. Wenn Google der Überzeugung ist, dass die Reputation der absendenden Domain schlecht ist, dann weisen sie ab. Warum die Domain böse ist? Wird nicht verraten. Was man dagegen tun kann? Ein Formular ausfüllen. »Please allow at least 2 weeks between submission for the changes, if any, to propagate«. Also praktisch nichts.

Was wirklich unangenehm ist: Das gilt dann nicht mehr nur für Gmail, sondern auch für alle Google Workspace Kunden mit eigener Domain, womit man echte Probleme hat – Google hat als Mailprovider einen geschätzten Anteil von knapp 20%; Microsoft kommt auf knapp 15%. Das ist für ein verteiltes System ein enorm hoher Anteil, was eine beachtliche Marktmacht ist. Es fühlt sich so an als würde diese Marktmacht genutzt um sie weiter zu erhöhen – als Google Kunde wäre meine Reputation bei Google sicher höher.

Links

¹RFC 821

²RFC 2821

³RFC 5321

⁴Correctiv zu Fake Domains im Umfeld des Ukraine-Krieges – „bmi.bund.pe“

════════════════════════

2023-07-04T19:19+02:00

🏡