¿Qué beneficio proporcionaría DKIM si ya se usa SPF?
Si un dominio tiene SPF configurado, el servidor de correo receptor puede verificar si el remitente reclamado del correo de acuerdo con el cuadro de diálogo SMTP (es decir, CORREO) puede enviar correo desde esta dirección IP. Esto ayuda a evitar que el remitente falsifique solo un poco, ya que solo el remitente basado en el cuadro de diálogo SMTP está marcado, pero no el encabezado De del correo. Pero los clientes de correo generalmente solo se preocupan por este último.
Con DKIM, el servidor de correo saliente firma un correo y esta firma también puede ser verificada por el remitente, es decir, no solo por el servidor SMTP receptor. Esta firma puede incluir todo el cuerpo, pero también puede incluir solo una parte del cuerpo. Y si bien el encabezado Desde es parte de esta firma, no significa que el encabezado Desde debe ser del dominio de firmantes, lo que significa que aún es posible la suplantación de identidad.
La simulación de De solo se aborda mediante la configuración de una política DMARC que requiere que el dominio en el encabezado From esté protegido por SPF o DKIM y que especifique una política cuando no se cumple el requisito.
¿Es correcto decir que SPF garantiza que el servidor del cual se origina el reclamo del correo electrónico sea el mismo en el que se originó y DKIM se asegura de que el contenido del mensaje de correo electrónico no haya sido modificado?
Los correos electrónicos no pretenden ser de un servidor específico sino de un dominio específico. Y como dije, tanto SPF como DKIM por sí solos no protegen contra la falsificación del encabezado From. Y DKIM solo protege parte del correo contra modificaciones: generalmente protege todo el cuerpo, pero puede configurarse para permitir la extensión del cuerpo. Y solo protege algunos encabezados pero no todos.
Si es correcto que DKIM proteja el mensaje para que no lo manipulen, ¿a quién protege exactamente? ¿Quién puede alterar el contenido del correo electrónico mientras está en tránsito, cuáles son los vectores de ataque comunes? ¿Puede haber un "nodo" malicioso que transmita el correo electrónico pero modifique su contenido?
El correo se entrega salto a salto e incluso si está cifrado con TLS, esto solo es relevante entre los saltos. Así que hay muchas partes involucradas que tienen acceso al correo no protegido y podrían modificarlo.
¿Un atacante podría crear un servidor que transmita correos electrónicos y luego rastrearlos o modificar el contenido, como cualquier persona puede hacer un nodo Tor malicioso?
Si el atacante puede falsificar los registros de DNS MX que especifican cómo se entrega un correo o si el atacante puede interceptar el correo en un transporte no protegido o en uno de los saltos, el atacante puede modificarlo. Pero el atacante no puede simplemente poner un servidor en Internet y declararlo como el servidor responsable del dominio; debe convencer a las demás partes de que envíen el correo a través de este servidor (es decir, falsificando el registro de DNS MX).
Si el proveedor de correo electrónico que utilizo admite el envío de correos electrónicos a través de SSL y deseo enviar un correo electrónico a mi amigo que usa Gmail (que también admite SSL), ¿mi mensaje recorre toda la ruta cifrada? ¿Significa que el mensaje está cifrado con una clave pública que pertenece a Gmail y que ningún servidor que transmita el mensaje lo verá descifrado?
Los mensajes viajan encriptados desde su cliente de correo al servidor de correo de su proveedor, se descifran allí, se modifican (se agrega el encabezado Recibido, tal vez el encabezado DKIM) y se vuelven a cifrar nuevamente para transportarlos al próximo salto que podría ser Google ya sea o podría ser otro servidor de correo ascendente.
Supongamos que uso SPF. Un atacante intenta enviar un correo electrónico que parece provenir de mí. ¿Dónde se reenvía este correo electrónico (esto es algo llamado MTA)? ¿Funciona como un nodo que envía información a otros nodos? Si el atacante controla el primer "nodo", ¿no puede informar a los nodos a los que se reenvía, que el mensaje pasa el SPF cuando no lo hace y los nodos que se reenvían al mensaje lo creerían?
Mientras que el atacante puede agregar un encabezado Received-SPF al correo y, por lo tanto, reclamar, comprobó que SPF no tiene un servidor de correo (MTA) en el borde entre Internet y la intranet que recibe este correo podría verificar nuevamente desde qué dirección IP el correo realmente viene, es decir, no confiará en el encabezado Received-SPF. Este encabezado es utilizado principalmente por los verificadores de correo no deseado que desean incorporar el resultado de la prueba SPF en su verificación de reputación, pero no se ejecutan en el servidor de correo y, por lo tanto, no tienen acceso a la IP original del remitente.