In che modo questa email sovverte i controlli SPF?

Gestisco un server di posta che sembra gestire correttamente le e-mail con il set SPF - tuttavia ho iniziato a ricevere e-mail false che pretendono di provenire da una banca - con l'indirizzo Da impostato come banca - ma che sicuramente non provengono dalla banca.

Le intestazioni pertinenti dell'email sono le seguenti:

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

La cosa chiave qui è che kiwibank.co.nz è una banca legittima e rispettabile da dove vengo, e ha un record SPF che recita:

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"

Quindi, dopo alcune letture, sembra che Envolope-From sia corretto, ma "From" è stato simulato. Esiste un modo per correggere / mitigare questo problema senza interrompere la posta "generale"? Noto che uso Postfix, Spamassassin e Polydyd (Postfix-Polydyd-spf-perl) - e se è davvero così facile da bypassare, qual è il punto di SPF?

postfix spf

— davidgo
fonte

Risposte:

In questo caso probabilmente hanno detto al tuo server qualcosa del genere:

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 conversazione SMTP (nota anche come "la busta") può avere da / a intestazioni diverse rispetto alle intestazioni e-mail. SPF non controlla l'intestazione, tuttavia è sempre l'intestazione che viene effettivamente mostrata all'utente finale! Sì, SMTP è così rotto. Sì, SPF è così rotto.

Sarai servito meglio controllando DMARC invece di controllare solo SPF. DMARC controlla per impostazione predefinita SPF ma controlla anche l'allineamento dell'intestazione From con SMTP MAIL FROM (i domini devono corrispondere - ignora la parte del nome utente). Come bonus potresti anche ottenere il supporto DKIM, che è un addendum molto utile a SPF.

Il DMARC dipende dal record DNS TXT impostato su _dmarc.kiwibank.co.nz. ma attualmente non ce n'è. Secondo lo stato attuale delle normative Internet, ciò significa che il proprietario di kiwibank.co.nz. non gliene frega niente di essere protetto da simili parodia. Ma in alcune implementazioni potresti applicare DMARC per tutte le email in arrivo.

— kubanczyk
fonte

SPF non è rotto. La posta stessa è rotta qui. Envelope to! = Header to ha buone ragioni. La busta tra domini da! = Header from non ha buone ragioni.

— joshudson,

@joshudson sì. Ad esempio, se imposto un .forwardfile (o altro inoltro di posta elettronica) per l'inoltro da uno dei miei account a un altro, ha senso preservare da chi proviene il messaggio (dall'intestazione) e visualizzarlo come da chi proviene nel client di posta elettronica, ecc. Ma qualsiasi rimbalzo generato da tale inoltro (il mittente della busta) dovrebbe essere indirizzato a me, non alla persona che ha originariamente inviato il messaggio. Lo stesso vale per le mailing list.

— derobert,

@derobert Le mailing list sono un limite. I client di posta non avvisano gli utenti di un falso evidente: è un grosso problema e nessun .forwardutilizzo può giustificarlo.

— Kubanczyk,

Questo è semplicemente incredibile.

— g33kz0r,

Quindi, dopo alcune letture, sembra che Envolope-From sia corretto, ma "From" è stato simulato. Esiste un modo per correggere / mitigare questo problema senza interrompere la posta "generale"?

Verifica l' Fromintestazione si romperà mailing list:

foo @ yourbank invia una mail a cat-picture-sharing-list @ bar.
La mailing list prenderà la posta,
- sostituisci Envelope-Fromcon qualcosa di simile a cat-picture-sharing-list-bounce @ bar,
- eventualmente modificare l'intestazione Reply-To e
- rinvia la posta a tutti i destinatari (ad es. tu).

Ora il tuo server di posta riceve una mail con

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

inviato dai server di posta della barra.

Noto che uso Postfix, Spamassassin e Polydyd (Postfix-Polydyd-spf-perl) - e se è davvero così facile da bypassare, qual è il punto di SPF?

Molti spammer non si preoccupano di inviare una busta "corretta".
La tua banca non riceverà (la maggior parte) del backscatter per questa posta spam, poiché i rapporti di mancato recapito vengono (o: dovrebbero essere) inviati all'indirizzo Envelope-From.
Il punteggio basato su Envelope-From diventa più affidabile. Se tu (o qualche fornitore di punteggio di cui ti fidi) assegni a tutte le mail con Envelope-From = ... @ yourbank un punteggio spam altamente negativo, gli spammer non possono abusarne.

— Heinzi
fonte