Amazon.de - Spam
Manchmal schaue ich in meinen Spam-Ordner einen privaten, nicht durch NoSpamProxy geschützten Postfachs und da ist mir eine Spam-Mail von Amazon.de aufgefallen. Eigentlich hätte die dort nie auftauchen sollen. Aber leider ist es so von Amazon gewollt.
Die Mail
Die Werbung, die angeblich von Amazon gekommen ist, ist nicht weiter spektakulär und sollte einen erfahrenen Anwender nicht überrumpeln. Aber nicht alle Empfänger sind "Antispam-Profis" und wer sagt mir, dass zukünftig nicht eine "bessere" Mail versendet wird. Diese Mail landete also in meine Quarantäne:
Der Header verrät aber schnell, dass sie nicht authentisch sein kann. Der einliefernde Mailserver verrät sich schon auf den ersten Blick
Ich bin sicher, dass Amazon nicht behauptet, sie wären "mac.com" und die IP-Adresse 103.161.133.36 ist eher Malaysia zugeordnet
Quelle:
https://ipinfo.io/AS132372/103.161.133.0/24
Hat Amazon kein SPF?
Ich hätte aber erwartet, dass der Mailserver (hier Kundenserver.de) die Mail direkt ablehnt, zumindest wenn Amazon einen passenden SPF-Eintrag hat. Ein kurzer Check mit NSLOOKUP auf die TXT-Records der Domain liefert auch jede menge Einträge:
PS C:\> Resolve-DnsName -Type TXT amazon.de | select strings
Strings
-------
{v=spf1 include:amazon.com -all}
{facebook-domain-verification=ek1qt04zvhemukcyfwbciyb8l0egku}
{adobe-idp-site-verification=b6bcd3e5aaffc63607c8bf75744d9a0d1febc50dd7f389428e2ae476c9ba8814}
{cisco-ci-domain-verification=1a12e4de3867a7eab0a7b39900090d22264028370b40cdcbef79e5736f2adf2a}
{cisco-ci-domain-verification=7e6f1891e567800c3b496ecaa79f7016bf76d271071851f03eedc893d2b9026a}
{spf2.0/pra include:amazon.com -all}
Amazon hat hier eigentlich alles richtig gemacht. Der klassische SPF-Record hat ein "-all" und sogar der SPF2.0-Eintrag endet mit einem "-all". Eigentlich hätte der Mailserver die Nachricht direkt abweisen müssen. Wobei das nicht ganz richtig ist, da SPF eigentlich nur den "MAIL FROM" im SMTP-Envelope prüft und nicht den "From" im Header der Mail. Der Anwender sieht nur den Header und nicht den "MAIL FROM". Eine Prüfung der für den Anwender sichtbaren "From:"-Zeile muss der Absender per DMARC vorgeben und der Empfänger auch auswerten.
DMARC überstimmt
Wenn die Mail nicht schon per SPF=FAIL abgewiesen wird, dann hat der Absender das Spoofing nur im Header und nicht im Envelope gemacht oder der Domaininhaber hat per DMARC etwas anderes vorgegeben.
PS C:\> Resolve-DnsName -Type TXT _dmarc.amazon.de
Name Type TTL Section NameHost
---- ---- --- ------- --------
_dmarc.amazon.de CNAME 116 Answer _dmarc.amazon.com
Name : _dmarc.amazon.com
QueryType : TXT
TTL : 116
Section : Answer
Strings : {v=DMARC1;, p=quarantine;, pct=100;, rua=mailto:report@dmarc.amazon.com;…}
Und hier sehen sie die Ursache: Der Eintrag "p=quarantine" sorgt dafür, dass die Mail auch mit einem SPF=FAIL dennoch angenommen aber dann in die Qurantäne gesteckt wird
Was lernen wir?
Auch große Versandhäuser schützen ihre Domains nicht gegen Missbrauch, wenn Sie zwar ein "-All" machen aber per DMARC dann kein "p=reject" machen sondern über "p=quarantine" dem Ziel sagen, er möge die Mail dennoch annehmen und im Junk-Mail-Ordner des Anwender ablegen.
Aus meiner Sicht ist das keine kundenfreundliche und sichere Kommunikation denn für mich bedeutet das zweierlei:
- Spam-Mail landen im Junk-E-Mail-Ordner
Wer heute einen Junk-E-Mail-Ordner betreibt, muss wohl laut Gesetz dort auch immer mal reinschauen, denn es könnte ja auch eine legitime Mail darin zu finden sein, zu der ein Absender sogar die Zustellung nachweisen kann. Der Absender bekommt keinen NDR und wenn er seine MTA-Logs lange aufbewahrt, dann kann er auch das "200 Accepted for delivery" ihres Servers nachweisen. - Benutzer könnten drauf reinfallen
Weniger versierte Anwender könnten aber die Mail irrtümlich als legitime Mail ansehen und drauf reinfallen. - Ionos/Kundenserver macht vermutlich
DMARC
Würde der Mailserver nur SPF auswerten, dürfte die Mail nicht angenommen werden. Dass die Mail dennoch angenommen und dann nach Junk-E-Mail gelegt wird, würde ich so interpretieren, dass DMARC ausgelesen und korrekt ausgewertet wird.
Aus meiner Sicht könnte es nur einen Grund geben, warum Amazon ihre SPF/DMARC-Einstellungen so vorgenommen hat, wie Sie am 3.4.2022 standen: Es könnte Mailserver beim Empfänger geben, die mit DMARC und SPF nicht immer sauber umgehen können und daher eine Ablehnung das Geschäftsmodell stören könnte. Heute kann Amazon sich immer darauf berufen, dass die Mail ja zugestellt wurde und leider der Empfänger es versäumt hat. regelmäßig in seine Quarantäne zu schauen.
Sie können selbst entscheiden, was sie von so einer Einstellung halten.
