Comment cet e-mail subvertit-il les chèques SPF?

Je gère un serveur de messagerie qui semble gérer correctement les e-mails avec un ensemble SPF - mais j'ai commencé à recevoir de faux e-mails censés provenir d'une banque - avec l'adresse De définie comme banque - mais qui ne proviennent certainement pas de la banque.

Les en-têtes pertinents de l'e-mail sont les suivants:

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

L'essentiel ici est que kiwibank.co.nz est une banque légitime et réputée d'où je viens, et possède un enregistrement SPF qui se lit comme suit:

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"

Donc, après quelques lectures - il semble que l'Envolope-From soit correct, mais le "From" a été truqué. Existe-t-il un moyen de corriger / atténuer cela sans rompre les e-mails "généraux"? Je note que j'utilise Postfix, Spamassassin et policyd (postfix-policyd-spf-perl) - et si c'est vraiment si facile à contourner, quel est l'intérêt de SPF?

postfix spf

— davidgo
source

Réponses:

Dans ce cas, ils ont probablement dit à votre serveur quelque chose comme ceci:

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...
.

La conversation SMTP (alias "l'enveloppe") peut avoir des en-têtes From / To différents de ceux des e-mails. SPF ne vérifie pas l'en-tête, mais c'est toujours l'en-tête qui est réellement affiché pour l'utilisateur final! Oui, SMTP est que cassé. Oui, SPF est si cassé.

Vous serez mieux servi en vérifiant DMARC au lieu de ne vérifier que SPF. DMARC vérifie par défaut SPF mais il vérifie également l'alignement de l'en-tête From avec SMTP MAIL FROM (les domaines doivent correspondre - il ignore la partie du nom d'utilisateur). En prime, vous pouvez également obtenir le support DKIM, qui est un complément très utile au SPF.

Le DMARC dépendrait du jeu d'enregistrements TXT DNS sur _dmarc.kiwibank.co.nz. mais actuellement il n'y en a pas. Selon l'état actuel des réglementations Internet, cela signifie que le propriétaire de kiwibank.co.nz. ne se soucie pas du tout d'être protégé contre de telles parodies. Mais vous pourriez dans certaines implémentations appliquer DMARC pour tous les e-mails entrants.

— kubanczyk
source

SPF n'est pas cassé. Le courrier lui-même est cassé ici. L'enveloppe à! = En-tête à a de bonnes raisons. L'enveloppe interdomaine de! = L'en-tête de n'a pas de bonnes raisons.

— joshudson

@joshudson oui c'est le cas. Par exemple, si je configure un .forwardfichier (ou un autre transfert de courrier électronique) à transférer d'un de mes comptes à un autre, il est judicieux de préserver la provenance du message (de l'en-tête) et de l'afficher comme de qui il provient dans le client de courrier électronique, etc. Il en va de même pour les listes de diffusion.

— derobert

Les listes de diffusion @derobert sont marginales. Les clients de messagerie n'informent pas les utilisateurs d'un faux évident - c'est un énorme problème, et aucune .forwardutilisation ne peut le justifier.

— kubanczyk

C'est tout simplement incroyable.

— g33kz0r

Donc, après quelques lectures - il semble que l'Envolope-From soit correct, mais le "From" a été truqué. Existe-t-il un moyen de corriger / atténuer cela sans rompre le courrier électronique "général"?

Vérification de l' en- Fromtête se briser les listes de diffusion:

foo @ yourbank envoie un mail à cat-picture-sharing-list @ bar.
La liste de diffusion prendra le courrier,
- remplacez le Envelope-Frompar quelque chose qui s'apparente à la barre de chat-partage d'image-liste-rebond @ bar,
- éventuellement modifier l'en-tête Reply-To et
- renvoyez le courrier à tous les destinataires (par exemple vous).

Maintenant, votre serveur de messagerie reçoit un courrier avec

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

envoyé depuis les serveurs de messagerie de bar.

Je note que j'utilise Postfix, Spamassassin et policyd (postfix-policyd-spf-perl) - et si c'est vraiment si facile à contourner, quel est l'intérêt de SPF?

Beaucoup de spammeurs ne prennent pas la peine d'envoyer une enveloppe «correcte».
Votre banque n'obtiendra pas (la plupart du temps) la rétrodiffusion de ce courrier indésirable, car les rapports de non-remise sont (ou doivent être) envoyés à l'adresse Envelope-From.
La notation basée sur Enveloppe-De devient plus fiable. Si vous (ou un fournisseur de notation en qui vous avez confiance) attribuez à tous les e-mails avec Envelope-From = ... @ yourbank un score de spam très négatif, les spammeurs ne peuvent pas en abuser.

— Heinzi
source