¿Cómo está este correo electrónico subvirtiendo los cheques SPF?

Ejecuto un servidor de correo que parece manejar correctamente los correos electrónicos con SPF configurado; sin embargo, he comenzado a recibir correos electrónicos falsos que pretenden ser de un banco, con la dirección De establecida como banco, pero que definitivamente no se originan en el banco.

Los encabezados relevantes del correo electrónico son los siguientes:

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 clave aquí es que kiwibank.co.nz es un banco legítimo y de buena reputación de donde soy, y tengo un registro SPF que dice:

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"

Entonces, después de leer un poco, parece que el Envolope-From es correcto, pero el "From" ha sido falsificado. ¿Hay alguna forma de corregir / mitigar esto sin romper el correo electrónico "general"? Observo que uso Postfix, Spamassassin y policyd (postfix-policyd-spf-perl), y si es realmente tan fácil de evitar, ¿cuál es el objetivo de SPF?

postfix spf

— davidgo
fuente

Respuestas:

En este caso, probablemente le dijeron a su servidor algo como esto:

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 conversación SMTP (también conocida como "el sobre") puede tener diferentes de / a encabezados de correo electrónico. ¡SPF no verifica el encabezado, sin embargo, siempre es el encabezado el que realmente se muestra al usuario final! Sí, SMTP es que rota. Sí, SPF está así de roto.

Será mejor que revises DMARC en lugar de solo revisar SPF. DMARC por defecto verifica SPF pero también verifica la alineación del encabezado From con SMTP MAIL FROM (los dominios deben coincidir, ignora la parte del nombre de usuario). Como beneficio adicional, también puede obtener soporte DKIM, que es un apéndice muy útil para SPF.

El DMARC dependería del registro DNS TXT establecido en _dmarc.kiwibank.co.nz. pero actualmente no hay ninguno. Según el estado actual de las reglamentaciones de Internet, significa el propietario de kiwibank.co.nz. no le importa en absoluto estar protegido contra tales parodias. Pero en algunas implementaciones podría aplicar DMARC para todos los correos electrónicos entrantes.

— kubanczyk
fuente

SPF no está roto. El correo en sí está roto aquí. Envelope to! = Header to tiene buenas razones. El sobre del dominio cruzado de! = Encabezado de no tiene buenas razones.

— joshudson

@joshudson sí lo hace. Por ejemplo, si configuro un .forwardarchivo (u otro reenvío de correo electrónico) para reenviarlo desde una de mis cuentas a otra, tiene sentido preservar de quién es el mensaje (del encabezado) y mostrarlo de quién es en el cliente de correo electrónico, etc. Pero cualquier rebote generado por ese reenvío (el remitente del sobre) debe ir a mí, no a la persona que originalmente envió el mensaje. Lo mismo se aplica a las listas de correo.

— derobert

@derobert Las listas de correo son marginales. Los clientes de correo no advierten a los usuarios sobre una falsificación obvia: es un gran problema y su .forwarduso no puede justificarlo.

— kubanczyk

Esto es simplemente increible.

— g33kz0r

Entonces, después de leer un poco, parece que el Envolope-From es correcto, pero el "From" ha sido falsificado. ¿Hay alguna forma de corregir / mitigar esto sin romper el correo electrónico "general"?

Verificación de la Fromcabecera va a romper listas de correo:

foo @ yourbank envía un correo a cat-picture-sharing-list @ bar.
La lista de correo tomará el correo,
- reemplace el Envelope-Fromcon algo similar a cat-picture-sharing-list-bounce @ bar,
- posiblemente modifique el encabezado Reply-To y
- reenviar el correo a todos los destinatarios (por ejemplo, usted).

Ahora su servidor de correo recibe un correo con

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

enviado desde los servidores de correo del bar.

Observo que uso Postfix, Spamassassin y policyd (postfix-policyd-spf-perl), y si es realmente tan fácil de evitar, ¿cuál es el objetivo de SPF?

Muchos spammers no se molestan en enviar un sobre "correcto".
Su banco no recibirá (la mayor parte) de la retrodifusión para este correo no deseado, ya que los NDR se envían (o: deberían) a la dirección Envelope-From.
La puntuación basada en Envelope-From se vuelve más confiable. Si usted (o algún proveedor de puntuación en el que confíe) asigna a todos los correos con Envelope-From = ... @ yourbank una puntuación de spam altamente negativa, los spammers no pueden abusar de eso.

— Heinzi
fuente