Desde el diseño original de SPF se sabe que solo podía proporcionar información adicional para determinar si algo es spam o algo. De hecho, hay muchas circunstancias comunes que pueden llevar a un falso error.
El reenvío rompe el SPF y causa fallas falsas
Por ejemplo, supongamos que tengo una dirección de correo electrónico que no uso, por ejemplo, [email protected] , y la configuro para reenviar todo el correo a mi dirección real, [email protected] . Ahora bien, si Wilma me envía un correo electrónico desde su sistema, foo.example y eso es válido en términos de SPF, aún será recibido en el servidor de correo domain.example desde el servidor de correo de example.tld . El servidor de correo de example.tld no va a ser autorizado por SPF para el correo de foo.example aunque no haya falsificación o correo no deseado.
Ahora hay un par de cosas que las personas pueden hacer para tratar de aclarar casos como este. Por ejemplo, domain.example puede incluir en la lista blanca example.tld . Alternativamente, se pueden configurar diferentes mecanismos de reenvío. Pero ninguno de estos es ideal, confiable o incluso está disponible para todas las configuraciones.
No bloquear cuando sepa que fallas falsas son posibles
Teniendo en cuenta lo anterior (y algunas otras formas de obtener sistemáticamente fallas falsas de SPF), es importante sopesar la información que una falla de SPF le da en lugar de rechazar automáticamente todas las fallas de SPF. Afortunadamente, incluso más tiempo que el SPF, los mecanismos antispam han usado filtros bayesianos. Esto es más que solo dar una puntuación a cada factor, es una forma de combinar todos los pequeños hechos que el sistema sabe sobre lo que es y no es el spam y equilibrar todo eso en un juicio que sesgará hacia falsos negativos (dejar que algo de spam a través de) en lugar de falsos positivos (rechazando cosas que no deberían ser rechazadas).
SPF es terrible, pero era necesario
Participé en algunas de las primeras discusiones que llevaron a SPF. Todos los involucrados saben que es profundamente defectuoso. Pero estábamos desesperados por cualquier cosa que ayudara a controlar la inundación de spam en los servidores de correo que estábamos ejecutando. (Claro, los usuarios individuales odian el spam en sus bandejas de entrada, pero las personas que ejecutan sistemas de correo tienen que pagar por hardware real y ancho de banda para gestionar todo el correo entrante, incluso si la mayoría se filtra antes de que llegue a su buzón).
DKIM reemplaza en gran medida a SPF. He estado fuera del negocio de la administración del correo electrónico por un tiempo, por lo que no estoy completamente seguro de cuál es el estado actual de pensamiento sobre por qué el SPF persiste ahora que DKIM está más disponible. Puedo ver casos donde SPF es posible y DKIM no lo es. Por ejemplo, con SPF puede autorizar un dominio o una red como remitente sin tener que darle a ese dominio de envío su clave privada DKIM. SPF y DKIM establecen diferentes requisitos en los dominios de envío legítimos para coordinar su actividad.
Pero aún así, me sorprende ver que SPF todavía existe. En el momento en que se presentó, pensé que era una medida temporal desesperada que sería reemplazada por mecanismos algo más coherentes. Pero parece que todavía tiene un papel que desempeñar.