tl; dr en bas.
Le protocole SMTP n'a pas la notion de destinataires CC ou BCC; Il s'agit d'une convention organisée par les clients de messagerie. Le serveur SMTP ne se soucie généralement que des informations et des données de routage. C'est une distinction importante, car sans cette capacité, BCC ne pourrait pas exister. En tant que communication BCC légitime, tenez compte de la transcription suivante du client:
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.
.
Maintenant, dans ce cas, Anonymous a reçu un message concernant cette réunion. Cependant, cette version du courrier n'a pas été acheminée à Jane Doe; elle ne sait rien sur Anonymous étant notifiée. En revanche, le message sera envoyé à Jane Doe avec un corps et un en-tête différents:
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.
.
Ici, comme Anonymous était dans le Cci, le message envoyé à Jane Doe n’incluait pas la liste des destinataires du Cci. En raison de la convention BCC, l'enveloppe de courrier électronique peut ne pas inclure les destinataires ayant effectivement reçu le message, mais également des destinataires ne figurant pas dans les en-têtes du message.
Comme mentionné par @JonasWielicki , que je voulais également inclure, est que le MUA (agent d'utilisateur de messagerie) est généralement responsable de l'envoi des multiples courriels nécessaires à la mise en œuvre de la CCC. Les serveurs de messagerie ne connaissent rien à BCC. Le MUA doit donc implémenter BCC en envoyant plusieurs courriels avec des itinéraires de messagerie différents spécifiés dans les en-têtes de l'enveloppe. Pour cette raison, les BCC prennent généralement plus de temps à envoyer que les courriels normaux, car différents corps de message doivent être construits et envoyés individuellement.
Cela aide également avec certaines règles de conformité de messagerie. Par exemple, un serveur de messagerie peut avoir des règles configurées pour BCC automatiquement un serveur de messagerie d'archivage (tous les courriers électroniques qui lui sont envoyés sont également archivés), auquel cas le serveur de messagerie peut même ne pas être un vrai destinataire.
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.
.
Ici, le destinataire est une autre partie qui n’est absolument pas divulguée à aucun des destinataires ni même à l’expéditeur. Il s'agit d'une fonctionnalité du protocole, généralement utilisée pour le relais ou l'archivage des messages.
Ce message de spam a profité de ce comportement. C'est une lacune standard qui, techniquement, devrait fonctionner avec tout serveur de messagerie conforme. Bien sûr, de nombreux serveurs mis à jour utilisent des "extensions" comme DKIM pour vérifier qu'un tel courrier est authentique, mais il existe encore de nombreux anciens serveurs de messagerie qui ne s'en soucient pas, tout simplement parce qu'il est tentant de ne pas réparer les éléments qui ne sont pas endommagés.
Notez également comment j'ai spécifié un en-tête Date. Cela peut être n'importe quelle valeur arbitraire (mais bien formatée); beaucoup de clients seront heureux d’afficher toute date légale allant du passé lointain au futur lointain. Je me suis personnellement adressé il y a quelques années un courrier électronique qui restera en tête de ma boîte aux lettres longtemps après mon espérance de vie, ainsi qu'un courrier électronique antérieur à mon compte de messagerie et à ma propre naissance.
tl; dr
Donc, en résumé, l'expéditeur a usurpé un courrier électronique, le serveur de messagerie d'origine l'a accepté / relayé, votre serveur de messagerie l'a accepté et l'a stocké dans votre boîte de réception, et votre client a fidèlement affiché les données qui se trouvaient dans votre boîte de réception, sans contourner le problème. toute sécurité. La sécurité "Envoi" est souvent beaucoup moins restreinte que la "réception" de la sécurité, dans la mesure où POP3 requiert presque toujours un nom d'utilisateur et un mot de passe avant de pouvoir accéder à une boîte aux lettres (vous pouvez théoriquement la contourner, mais je ne connais aucun mot de passe légitime. services de messagerie qui le font).
