¿Es una buena idea agregar a la lista blanca el correo electrónico entrante usando un Hash en la dirección? (Similar a BATV, pero con DKIM)

Question

¿Es una buena idea agregar a la lista blanca el correo electrónico entrante usando un Hash en la dirección? (Similar a BATV, pero con DKIM)

#1 de Ángel (2 votos)
#2 de Thomas Pornin (1 votos)

3

Declaración de problema

Estoy buscando formas de garantizar que los socios comerciales o los correos electrónicos de remitentes de confianza nunca se pongan en cuarentena. .... en otras palabras, evita que " ham se vea como spam". Idealmente, esto garantizaría la entrega incluso si el remitente estuviera marcado como spammer ( ... vea la lista de agujero negro ).

Dado que la mayoría de los correos electrónicos se envían a través de proveedores de correo electrónico en la nube / de varios inquilinos / compartidos que comparten el mismo espacio de IP, es probable que la reputación de muchas empresas diferentes se afecten entre sí para bien o para mal. Es decir, los spammers pueden beneficiarse de la ubicación conjunta de inquilinos "buenos" y, a la inversa, los inquilinos "buenos" pueden estar en la lista negra si el spammer obtiene el espacio de IP en la lista.

Las soluciones de listas blancas de correo electrónico actuales requieren una acción especial por parte del destinatario, y esa base de datos se debe mantener en un MTA. Pero hay muchos casos en los que esto no es factible o la solución correcta, como cuando está desconectado, en una feria comercial, o donde el receptor desea garantizar la entrega de un mensaje enviado sin iniciar sesión en un portal web o actualizar la configuración del correo no deseado de Outlook .

Diseño propuesto

Si modificamos la dirección de correo electrónico de TO, pero añadimos un valor especial, como un hash, ( similar a cómo funciona BATV ), el motor de MTA / SPAM podría ignorar el mensaje y aceptarlo como está. Aquí es cómo se vería un mensaje:

// The sig below will only guarantee delivery 
// for a sender of [email protected]
// to the account [email protected]
[email protected] 

// The sig below will only guarantee delivery 
// for a sender of [email protected]
// to the account [email protected]
[email protected]

El hash (definido como HMAC) trust sería los primeros 80 bits de la función:

(SHA256(Key + Lowercase From + Lowercase To))

Cuando el MTA que recibe recibe el mensaje con la dirección especial, podrá validar el HMAC rápidamente y evitar cualquier lista gris u otras técnicas antispam que puedan aplicarse.

Suponga que a cada usuario se le asigna la sal por su propia capacidad para distribuir hash, y hay una copia de cada hash disponible para el MTA con fines de verificación.

Haciéndolo seguro / libre de fallas

Dado que cualquiera podría suplantar la tupla de las direcciones "DE" y "A" de arriba, creo que es un buen dado combinar esta función con medidas contra la suplantación de identidad como DKIM o SPF, que se define mejor en la estándar DMARC

Usuario

Para una lista de usuarios en línea, sin conexión

Esta idea es más adecuada para los momentos en que te encuentras con alguien en una conferencia comercial, un bar o si quieres asegurarte de recibir los mensajes de esa persona. No desea que ninguna solución Anti Spam se interponga en el camino de recibir su correo electrónico. Ingresaría su dirección de correo electrónico en su generador para crear la siguiente dirección [email protected]

EsteprocesodedospasosparagenerarladirecciónsepuedeautomatizarenunavariedaddeaplicacionescomoFacebook,LinkedIno Bump para iPhone.

Para listas de correo electrónico en línea

Además de configurar el encabezado Reply-To: , el MUA (cliente de correo electrónico) podría insertar un encabezado X especial

X-WhitelistReplyAddress = [email protected]

Pregunta

¿Es razonable el objetivo "general" de esta idea? (listas blancas fuera de línea, entrega garantizada por MTA, traslado de la ubicación de la lista blanca del servidor de correo centralizado a los remitentes reales)
¿Existe alguna RFC propuesta similar que exista y que incluya en la lista blanca de remitentes y destinatarios de confianza para este correo electrónico?
¿Qué otras técnicas existen para incluir en la lista blanca los pares de remitentes y receptores en el correo electrónico?
¿Qué componentes criptográficos son apropiados para esta solución? ¿El hash es el camino correcto?

email spam cloud-computing whitelist multi-tenancy

pregunta random65537 21.08.2013 - 19:26

fuente

2 respuestas

1

El hash no es la herramienta criptográfica correcta; lo que quieres es un MAC .

Su punto es que desea que algunos correos electrónicos pasen por filtros antispam, pero como no desea que los spammers utilicen la misma ruta (obviamente), está listo para aplicar el uso de un campo adicional en el correo electrónico, lo que contienen algún valor de autenticación que, con suerte, los spammers no pueden falsificar. Para hacerlo más fácil, codifica ese campo adicional en la dirección de correo electrónico del destinatario, porque ese es un campo que el remitente completa de todos modos. Esto requiere un MAC y eso es lo que intenta utilizar en su fórmula:

SHA256(Salt + Lowercase From + Lowercase To)

Llame a "Salt" con una clave , y tiene un MAC homebrew (uno pobre, en realidad), que podría reemplazarse por > HMAC .

Debes cuidar el paradero de la clave. La clave se utiliza para generar el token (la dirección "Para:", si prefiere verlo de esa manera), y también para verificar dichos tokens. A un spammer realmente le gustaría tener en sus manos esa clave, ya que le permitiría enviar spam que evadía los filtros antispam. Pero la clave debe estar alojada en algunos sistemas en línea (tanto en la Aplicación que genera el token como en el servidor MTA que verifica los correos electrónicos entrantes), lo que rara vez es bueno para la confidencialidad a largo plazo. Además, la clave no se puede cambiar fácilmente ya que rompería las direcciones de correo electrónico publicadas anteriormente.

Este sistema solo funcionará siempre que pueda educar a los remitentes para que usen una herramienta personalizada para calcular el token (para integrarlo en la dirección "Para:") y también para convencerlos de que escriban ese aspecto feo. Dirección (la gente rara vez se deleita en la gloria del hexadecimal). Al mismo tiempo, no debe hacer que el sistema sea demasiado automático, ya que de lo contrario los spammers se adaptarán y utilizarán, derrotando el propósito. El equilibrio correcto es a menudo difícil de alcanzar, en particular porque un cliente potencial en una feria comercial a menudo exhibe menos capacidad mental que incluso el spammer promedio.

Además, a muchos administradores de sistemas no les va a gustar nada: un sistema destinado a evitar los filtros antispam también es un sistema que permitirá a los usuarios enviarse archivos ejecutables entre sí, se temerá una fiesta de virus.

Para resumir, no veo que el sistema sea realmente práctico. Creará más problemas de usabilidad de los que resuelve.

respondido por el Thomas Pornin 21.08.2013 - 20:29

fuente

Lea otras preguntas en las etiquetas email spam cloud-computing whitelist multi-tenancy

Usando la clase Apple NSKeyedArchiver sin cifrado para guardar los datos de puntuación localmente contribución de seguridad de reinstalación del sistema operativo

score 2 · Accepted Answer

Muchos sistemas admiten el uso de alias con un carácter como + . Por lo tanto, [email protected] sería equivalente a [email protected] para el MDA (es decir, terminarán en el mismo buzón).

Luego, mantienes una lista de tokens incluidos en la lista blanca (tal vez emparejados con el encabezado De que deben usar): [email protected] [email protected] [email protected] [email protected]

Si alguien le envía un correo electrónico a una dirección en su lista, se coloca en la lista negra. Si no lo es, se trata automáticamente como correo no deseado (para evitar la adivinación de tokens). Obviamente, si un buen token se ve comprometido, lo reemplazas;)

La lista blanca no necesita ser almacenada en el MTA, el filtrado se puede hacer localmente. Para usos fuera de línea, puede crear de antemano un montón de tokens de listas blancas. O incluso los inventó sobre la marcha siempre y cuando actualice la lista blanca verificada por el filtro antes de que procese ese correo nuevo.

Esto ha existido por algún tiempo, no recuerdo cuándo lo hice por primera vez. La mejor parte es que funciona hoy , sin tener que dar instrucciones a los MUA sobre un nuevo encabezado X-WhitelistReplyAddress .

Una gran diferencia con el hash de los destinatarios es que en su solución hay una clave única de la que se derivan los tokens, mientras que aquí hay tokens generados al azar que debe enumerar (aunque podría reemplazar el search the token in the list con %código%). Pero si un token de la lista blanca basada en hash se ve comprometido, no puede eliminarlo sin cambiar los tokens de todos, mientras que en el otro enfoque puede reemplazar fácilmente un solo token (además, si mantiene registros de las entidades que dio a su correo electrónico, puede encontrar quién filtró / vendió su dirección de correo electrónico).