tl; dr en la parte inferior.
El protocolo SMTP no tiene la noción de destinatarios CC o BCC; Esta es una convención celebrada por clientes de correo. El servidor SMTP generalmente solo se preocupa por la información y datos de enrutamiento. Esta es una distinción importante, porque sin esta capacidad, BCC no podría existir. Como comunicación legítima de BCC, considere la siguiente transcripción del cliente:
HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<anonymous@another-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM
This is an important meeting notice. We'll meet tomorrow.
.
Ahora, en este caso, Anonymous recibió un mensaje sobre esta reunión. Sin embargo, esta versión del correo no fue enrutada a Jane Doe; ella no sabe nada sobre Anonymous siendo notificado. Por el contrario, a Jane Doe se le enviará el mensaje con un cuerpo y encabezado diferentes:
HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<jane.doe@to-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM
This is an important meeting notice. We'll meet tomorrow.
.
Aquí, dado que Anonymous estaba en BCC, el mensaje enviado a Jane Doe no incluía la lista de destinatarios de BCC. Debido a la convención de BCC, el sobre del correo electrónico puede no incluir destinatarios que realmente recibieron el mensaje, y también puede incluir destinatarios que no aparecen en los encabezados del mensaje.
Como mencioné @JonasWielicki , que también quise incluir, es que el MUA (Agente de usuario de correo) generalmente es responsable de enviar los múltiples correos electrónicos necesarios para implementar BCC. Los servidores de correo electrónico no saben nada sobre BCC, por lo que el MUA debe implementar BCC enviando múltiples correos electrónicos con diferentes rutas de correo electrónico especificadas en los encabezados de los sobres. Por esta razón, los BCC suelen tardar más en enviarse que los correos electrónicos normales, ya que los diferentes cuerpos de mensajes deben construirse y enviarse individualmente.
Esto también ayuda con algunas reglas de cumplimiento de correo electrónico. Por ejemplo, un servidor de correo puede tener reglas configuradas para BCC automáticamente a un servidor de correo electrónico de archivo (todos los correos electrónicos que se le envían también se archivan), en cuyo caso el servidor de correo podría no ser un destinatario real.
HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<mail-archive@archive-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM
This is an important meeting notice. We'll meet tomorrow.
.
Aquí, el destinatario es otra parte que no se revela por completo a ninguno de los destinatarios o incluso al remitente. Esta es una característica del protocolo, que generalmente se usa para retransmitir o archivar mensajes.
Lo que hizo este mensaje de spam fue aprovechar ese comportamiento. Es una laguna estándar que técnicamente debería funcionar con cualquier servidor de correo compatible. Por supuesto, muchos servidores actualizados usan "extensiones" como DKIM para verificar que dicho correo electrónico sea auténtico, pero todavía hay muchos servidores de correo antiguos que no les importa, simplemente porque es tentador no arreglar cosas que no están rotas.
También tenga en cuenta cómo he especificado un encabezado de fecha. Esto puede ser cualquier valor arbitrario (pero bien formateado); muchos clientes mostrarán felizmente cualquier rango de fechas legales desde el pasado lejano hasta el futuro lejano. Personalmente, me envié un correo electrónico hace años que permanecerá en la parte superior de mi casilla de correo mucho después de mi expectativa de vida, así como un correo electrónico anterior a mi cuenta de correo electrónico y mi propio nacimiento.
tl; dr
Entonces, en resumen, el remitente falsificó un correo electrónico, el servidor de correo original lo aceptó / retransmitió, su servidor de correo electrónico lo aceptó y lo almacenó en su bandeja de entrada, y su cliente le mostró fielmente los datos que estaban en su bandeja de entrada, todo sin eludir Cualquier seguridad. La seguridad de "envío" a menudo es mucho menos restringida que la seguridad de "recepción" en esa perspectiva, ya que POP3 casi siempre requiere un nombre de usuario y una contraseña antes de poder acceder a un buzón de correo (teóricamente podría eludir esto, pero no sé de ningún legítimo servicios de correo que lo hacen).
