Headerquiz

Sie kennen das Symptom ja schon von der Seite IONOS SMTPAUTH Fail, wenn ein Mailempfänger sich nicht um die Absenderprüfung kümmert und dann auch noch NDRs an den falschen Absender sendet.

NDR Flut

Jeder Mailserver, der E-Mail von einem Absender annimmt, der nicht gültig ist und dann auch noch NDRs versendet, macht was falsch, weil er als "Störer" (NDR-Backscatter) erscheint. Im Postfach des angeblichen Absenders sieht es dann schnell so aus.

in meinem Fall war es wieder eine "Spam-Mail" von mir an mich.

SPF/DMARC und Co

Natürlich muss ich als Absender etwas mithelfen, z.B.: indem ich SPF-Einträge und DMARC-Einträge entsprechend setze. Das ist aber der Fall:

C:\>nslookup -q=TXT carius.de 

carius.de text = "v=spf1 include:_spf.perfora.net include:_spf.kundenserver.de include:spf.protection.outlook.com -all" 

C:\>nslookup -q=TXT _dmarc.carius.de
_dmarc.carius.de        text = "v=DMARC1; p=reject; rua=mailto:....."

Sowohl der SPF-Eintrag endet mit einem "-all" als auch der DMARC-Eintrag ist mit einem "p=reject" auf streng gestellt. Jeder halbwegs gute Mailserver könnte daher diese Mail einfach verwerfen. Nicht aber IONOS. Sie haben die Mail angenommen und zugestellt. Eine von mir konfigurierte Weiterleitung an ein Zweipostfach hat dann nicht mehr funktioniert und die NDRs erstellt. Soweit war ich da auch etwas selbst verantwortlich. Aber so habe ich mir auch mal die Header angeschaut.

Zusteller

Ein Blick in die Header des empfangenden Server liefert den tatsächlichen Zusteller:

Ein schneller Blick auf 188.214.88.100 verweist nach Rumänien:


Quelle: https://ipinfo.io/AS33911/188.214.88.0/24

Da hat also wieder jemand einen virtuellen Server oder CMS-Instanz gekapert oder installiert und versendet damit seinen Müll. Es ist aber keiner meiner Server und die IP-Adresse ist natürlich nicht per SPF zugelassen. Unter der IP-Adresse meldet sich einfach ein Webhostingtemplate, dessen Kontaktformular eine Adresse in Kalifornien vorgibt aber die Rufnummer +81 zu Japan gehört:

Da passt schon mal gar nichts.

Header-Fälschungen

Interessant an der Mail war aber der Versuch, mit dem der Spammer wohl entweder die Analyse erschweren wollte oder auf verschiedene "Whitelist"-Effekte bei Spamfiltern hoffte, denn in dem Header hat fast gar nichts gestimmt.

Normalerweise addiert ein Server seien Received-Header über alle anderen Header, so dass es eine zeitliche Abfolge gibt.

  • Falscher HELO-Name
    Schon die oberste Zeile zeigt aber, dass der einliefernde Mailserver sich mit einem "HELO edition.cnn.com" meldet, was natürlich nicht stimmt. den Host gibt es zwar, aber die per DNS auflösbaren Adressen passen nicht auf die genutzte 188.214.88.10 und auch ein "ReverseDNS auf 188.214.88.10 liefert stattdessen einen aquaspicer.com.
    Schon hier hätte der empfangende Mailserver schon mal stoppen können.
  • Die DKIM-Signatur ist natürlich ebenso gefälscht, denn den aufgeführten Selector "smtp" mit der Domain 1und1.de gibt es nichtm wie ein "nslookup -q=TXT smtp._domainkey.1und1.de" schnell zeigt und die Mail ist ja grade erst bei 1und1 angekommen.
  • 2. Received-Header: unbekannt an sendgrid
    Ich bezweifle, dass Sendgrid die vorherige Station war, denn wie sollte die Mail von dort dann über "edititon.cnn.com" auf einem rumänischen Server bei 1und1 landen?
  • Weitere Received-header
    Das geht munter so weiter, dass es eine weitere Header gibt, die auch alle behaupten, dass das Übertragungsprotokoll "HTTP" gewesen sein soll.
  • Angeblich hat die Mail noch mal einen Weg über 127.0.0.1 bei "lomograpy.com" gemacht, der die Mails von Facebook erhalten haben soll
  • Datum.
    Das "Date" der Mail soll in 2106 liegen, während die erste Station die dann am 11. März 2022 bekommen und am 15. Sep 2022 weiter geleitet haben sollte. Vermutlich prüfen Spamfilter allein deswegen nicht den Zeitraum eines Systemdatums, weil auch Spammer dies nicht falsche machen.

Ich habe ja schon einiges an Headern gesehen aber so viel Unstimmigkeiten sind doch eher selten. Aber es geht noch weiter:

Hier fallen gleich mehrere Dinge auf:

  • Doppelter X-Mailer
    Normalerweise steht in diesem optionalen Feld die Software drin, die die Mail erstellt hat Hier war es angeblich "ZuckMail", was auf einen Versand aus Facebook (Zuckerberg) hindeutet. Aber es gibt noch ein zweites Feld "X-mailer", welches nach einer Base64-Decodierung den String "frank---frank@carius.de " enthält. Sehr seltsam
  • Facebook-Header
    Sie finden auch selbst noch sehr viele weitere Header, die eigentlich mit Mails von Facebook in Verbindung stehen sollen. Allerdings gibt es keinen einzigen Hinweis, dass hier Facebook der Absender gewesen wäre.
  • BIMI-Selector
    Über den Eintrag können Firmen beim kompatiblen Empfänger ein Logo einblenden lassen. Alledings wird man unter fb2021q2v1._bimi.carius.de sicher keinen DNS-Eintrag finden und selbst bei Facebook gibt es den Eintrag nicht.
  • IP und HTTP
    Die angebliche IPv6-Adresse "2401:db00:209c:3f09:face:0:1e9:0" verweist auf Singapur (http://ipaddress.is/2401:db00:209c:3f09:face:0:1e9:0) und wird wohl nicht einen italienischen Shop (lomography.com) per HTTP dazu bringen, die Mail anzunehmen und ihrerseits per HTTP dann zu SendGrind, SendinBlue und Mailchimp zu leiten

Die Header wirken einfach zusammengeschustert. Ich bin mir auch nicht sicher, welche Bedeutung die im Header hinterlegten SPF/DKIM/DMARC-Auswertungen haben sollen.

Angeblich hat "lomography.com" einen erfolgreichen SPF-Test gemacht und eine Domainkey- und DKIM-Signatur angebracht. Das kann der Server gar nicht, da er ja keinen Key für "carius.de" hat und der verwendete Selector "smtp._domainkey.lomography.com" löst nicht per DNS auf. Die DKIM-Signatur von 1und1.de könnte allerdings aufgrund der Weiterleitung passen, denn der "Sender" der Mail ist aus der 1und1de-Domain.

Unsinn?

Von dem umfangreichen Header bleiben neben dem Betreff, Sender, From, To, Date nur noch die erste Zeile übrig, die eine Zustellung von einem rumänischen Server direkt an IONOS belegt. Alles andere ist nur Füllmaterial um vielleicht eine Analyse zu erschweren.

Bislang kann ich mir noch keinen Reim daraus machen, warum sich ein Spammer so viele Mühe damit gibt, eine Mail mit so vielen gefälschten Headern zu versehen. Glaubt der reale Spammer wirklich, dass ein durchschnittlicher Anwender sich die Textwüste anschaut oder ein halbwegs versierter Spambekämpfer das nicht durchschaut und gezielt die fraglichen Stellen findet?

Die einzige Frage bleibt, warum 1und1 die Mails annimmt, obwohl der SPF-Check für den Absender in Verbindung mit der DMARC-Vorgabe definitiv ein "Reject" bewirken sollte. Dazu müsste man halt zumindest SPF für eingehende Mails auch machen.

Weitere Links