Wie untergräbt diese E-Mail SPF-Prüfungen?

Ich verwende einen Mail-Server, der anscheinend E-Mails mit aktiviertem SPF korrekt verarbeitet. Allerdings erhalte ich gefälschte E-Mails, die angeblich von einer Bank stammen. Als Absenderadresse wurde die Bank festgelegt, die aber definitiv nicht von der Bank stammt.

Die relevanten Header der E-Mail lauten wie folgt:

Received-SPF: none (www.tchile.com: No applicable sender policy available) receiver=mydomain.org; identity=mailfrom; envelope-from="apache@www.tchile.com"; helo=www.tchile.com; client-ip=200.6.122.202
Date: Thu, 13 Oct 2016 04:03:54 -0300
Message-Id: <201610130703.u9D73smu017280@www.tchile.com>
To: user@mydomain.com
Subject: CANCELLATION_PROCESS.
From: KIWI BANK <noreply@kiwibank.co.nz>
Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=029F3E3270D5187AA69203962BF830E3

Das Wichtigste dabei ist, dass kiwibank.co.nz eine legitime, seriöse Bank ist, von der ich komme, und eine SPF-Aufzeichnung hat, die lautet:

kiwibank.co.nz.     13594   IN  TXT "v=spf1 include:_spf.jadeworld.com ip4:202.174.115.25 ip4:202.126.81.240 ip4:202.12.250.165 ip4:202.12.254.165 ip4:66.231.88.80 include:spf.smtp2go.com include:spf.protection.outlook.com -all"

Nach einigem Lesen scheint das Envolope-From korrekt zu sein, aber das "From" wurde gefälscht. Kann ich das auf irgendeine Weise korrigieren / abmildern, ohne "allgemeine" E-Mails zu beschädigen? Ich stelle fest, dass ich Postfix, Spamassassin und policyd (postfix-policyd-spf-perl) verwende - und wenn es wirklich so einfach zu umgehen ist, worum geht es bei SPF?

postfix spf

— Davidgo
quelle

Antworten:

In diesem Fall sagten sie wahrscheinlich zu Ihrem Server:

EHLO www.tchile.com
MAIL FROM: apache@www.tchile.com 
RCPT TO: user@mydomain.com
DATA
Date: Thu, 13 Oct 2016 04:03:54 -0300
Message-Id: <201610130703.u9D73smu017280@www.tchile.com>
To: user@mydomain.com
Subject: CANCELLATION_PROCESS.
From: KIWI BANK <noreply@kiwibank.co.nz>
Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=029F3E3270D5187AA69203962BF830E3
X-Virus-Scanned: ClamAV using ClamSMTP

The contents of mail...
.

Die SMTP-Konversation (auch als "Umschlag" bezeichnet) kann ein anderes Von / Bis als E-Mail-Header haben. SPF überprüft den Header nicht, es ist jedoch immer der Header, der dem Endbenutzer tatsächlich angezeigt wird! Ja, SMTP ist so kaputt. Ja, SPF ist so kaputt.

Sie werden am besten bedient, indem Sie DMARC überprüfen, anstatt nur SPF zu überprüfen. DMARC überprüft standardmäßig SPF, überprüft jedoch auch die Ausrichtung des From-Headers mit SMTP MAIL FROM (Domänen müssen übereinstimmen - der Benutzername wird ignoriert). Als Bonus könnten Sie auch DKIM-Unterstützung erhalten, was eine sehr nützliche Ergänzung zu SPF ist.

Die DMARC hängt vom DNS-TXT-Datensatz ab, der unter _dmarc.kiwibank.co.nz festgelegt wurde. aber derzeit gibt es keine. Nach aktuellem Stand der Internetbestimmungen bedeutet das den Inhaber von kiwibank.co.nz. kümmert sich überhaupt nicht darum, vor solchen Parodien geschützt zu sein. In einigen Implementierungen können Sie jedoch DMARC für alle eingehenden E-Mails erzwingen.

— kubanczyk
quelle

SPF ist nicht kaputt. Mail selbst ist hier kaputt. Umschlag nach! = Header nach hat gute Gründe. Domainübergreifender Umschlag von! = Header von hat keine guten Gründe.

— Joshudson

@ Joshudson ja, das tut es. Wenn ich beispielsweise eine .forwardDatei (oder eine andere E-Mail-Weiterleitung) für die Weiterleitung von einem meiner Konten zu einem anderen eingerichtet habe, ist es sinnvoll, die Herkunft der Nachricht (From-Header) beizubehalten und sie als die Herkunft der Nachricht in der Liste anzuzeigen E-Mail-Client usw. Alle von dieser Weiterleitung (dem Umschlagsender) generierten Bounces sollten jedoch an mich gehen, nicht an die Person, die die Nachricht ursprünglich gesendet hat. Gleiches gilt für Mailinglisten.

— Derobert

@derobert Mailinglisten sind ein Rand. Mail-Clients warnen Benutzer nicht vor einer offensichtlichen Fälschung - es ist ein großes Problem, und keine .forwardVerwendung kann es rechtfertigen.

— Kubanczyk

Das ist einfach unglaublich.

— g33kz0r

Nach einigem Lesen scheint das Envolope-From korrekt zu sein, aber das "From" wurde gefälscht. Kann ich das auf irgendeine Weise korrigieren / abmildern, ohne "allgemeine" E-Mails zu beschädigen?

Wenn Sie den FromHeader überprüfen, werden die Mailinglisten beschädigt :

foo @ yourbank schickt eine Mail an cat-picture-sharing-list @ bar.
Die Mailingliste nimmt die Mail entgegen,
- Ersetzen Sie die Envelope-Fromdurch eine Art Cat-Picture-Sharing-List-Bounce @ Bar.
- Ändern Sie möglicherweise den Reply-To-Header und
- Senden Sie die E-Mail erneut an alle Empfänger (z. B. Sie).

Jetzt bekommt Ihr Mailserver eine Mail mit

Envelope-From: cat-picture-sharing-list-bounce@bar
From: foo@yourBank

gesendet von den Mailservern der Bar.

Ich stelle fest, dass ich Postfix, Spamassassin und policyd (postfix-policyd-spf-perl) verwende - und wenn es wirklich so einfach zu umgehen ist, worum geht es bei SPF?

Viele Spammer kümmern sich nicht darum, einen "richtigen" Umschlag-Absender zu versenden.
Ihre Bank wird den größten Teil der Rückstreuung für diese Spam-Mail nicht erhalten, da Unzustellbarkeitsberichte an die Umschlag-Absender-Adresse gesendet werden (oder sollten).
Die auf Envelope-From basierende Bewertung wird zuverlässiger. Wenn Sie (oder ein vertrauenswürdiger Scoring-Anbieter) allen E-Mails mit Envelope-From = ... @ yourbank einen äußerst negativen Spam-Score zuweisen, können Spammer diesen nicht missbrauchen.

— Heinzi
quelle