web-dev-qa-db-fra.com

Comment ai-je reçu cet e-mail sans champ "À"?

J'ai reçu un e-mail vide dans ma langue (hébreu) ​​avec uniquement un titre qui peut être traduit en I am still waiting for your feedback (original: עדיין מחכה למשוב שלך)

Étant donné que mon gmail gère plusieurs comptes (par transfert et par utilisateur\passe), j'ai essayé de déterminer quel compte était la cible, et à ma grande surprise - Aucun!

Strange email without To

Ma question est simple, pourquoi gmail a choisi de mettre cet e-mail dans ma boîte de réception? Ci-dessous est la source complète de l'e-mail (de gmail) sauf mon e-mail censuré. Comment n'est-ce pas une faille de sécurité\arrêtée par les filtres anti-spam ?

Message d'origine:

  • ID de message <[email protected]>
  • Créé le: mar.16 janv.2018 à 2h54 PM (livré après 2 secondes)
  • De: joseph andrew Utilisation de Mail.Ru Mailer 1.0
  • À:
  • Objet: עדיין מחכה למשוב שלך
  • SPF: PASS avec IP 217.69.138.160 En savoir plus
  • DKIM: 'PASS' avec le domaine bk.ru En savoir plus
  • DMARC: 'PASS' En savoir plus
Delivered-To: ****<cencored>****@gmail.com
Received: by 10.2.76.217 with SMTP id q86csp4037724jad;
        Tue, 16 Jan 2018 04:54:21 -0800 (PST)
X-Google-Smtp-Source: ACJfBotHqXkzj6W7Gd+8IjEmxrwG9SqXBSC+QiTqyAB1j2Dt4ASXtmXr5UpqIpdU7Mge/EFmnzVI
X-Received: by 10.46.101.207 with SMTP id e76mr192303ljf.115.1516107261904;
        Tue, 16 Jan 2018 04:54:21 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1516107261; cv=none;
        d=google.com; s=arc-20160816;
        b=O+SDwmDS2Y7Jxi+mhwkV/+svfXK0KI3VvepeQgBpyhlgYY5gK3wln+RC4YPO+MMn71
         tyrGBUoc1iGKpeGcilWAovf0XLceJY+EAGoMX4Hl4Pse8C5mWiP0DJQXfmolB5myOFD/
         EoSl7Km4KDcQsvSC0DGwcni1yUPjgiQr+KIY+y19WCqVfm5EtCkbYkUCnFP1RWh/BUBp
         YZHKJrRYH/gWsSqBuIm/fDuSFk4bYAFaCOfkq5LfJcnkf7lpRFBnNYseignqwnnYMEzB
         aScqj1ppvCoYLbBuEiw+yLo1iQLoNdXwGOLShsGXELxkpdFpmchOEV44Wx2vp+RlJMF0
         v1/A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-transfer-encoding:message-id:reply-to:date:mime-version
         :subject:from:dkim-signature:arc-authentication-results;
        bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
        b=IPjf/U3N1a7Dx8HIw59iWKeccU4mS7Bd0Iy2FY/Be4Mx4QATd8uBvH7pLOVOLHRAXj
         iATzKUy69ZyLgu6gJVc+yjW3+i740O9ccPNbWAPQQASX1H9OkiMsmlhNYOU5u4KDKfbj
         nNm77TeMxrF57z4XKpbO3iE4YEv6JFankI949HvLnehC7wPP5M5YHpS8CllmV3zP8RX4
         2kb14n4PzguduwYoHL3q7wwWHHnyPUsa3UuhCKLvNJYw4KWKLWNY6Kt7fwReb83T+OsG
         lavZ7huDrCcf0P8Ee7YGepcNpGFyh2WjpA4o7l+gAlnqsb6+5FZloH6j7cmQx/gA+gKh
         aVng==
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass [email protected] header.s=mail header.b=kgyoMcic;
       spf=pass (google.com: domain of [email protected] designates 217.69.138.160 as permitted sender)
       [email protected];
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bk.ru
Return-Path: <[email protected]>
Received: from f493.i.mail.ru (f493.i.mail.ru. [217.69.138.160])
        by mx.google.com with ESMTPS id 1si926950ljd.480.2018.01.16.04.54.21
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 16 Jan 2018 04:54:21 -0800 (PST)
Received-SPF: pass (google.com: domain of [email protected] designates 217.69.138.160 as permitted sender) client-ip=217.69.138.160;
Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=mail header.b=kgyoMcic;
       spf=pass (google.com: domain of [email protected] designates 217.69.138.160 as permitted sender)
       [email protected];
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bk.ru
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bk.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:From;bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=kgyoMcicHiqU/OvYmq/2sQYQ3607jIk9ZHkh3oVDZTrA6cWDxLGvol37xuQ3L0mfrqIOpSTYHuJzssIjww+4FL/h/GwBRRO1AsuLgxyjSQaOLVqidNe0MUIz6EVQxYXLcUCl9USryPLWAWKBiwL80efALu5znH8K96P6fF33Gzw=;
Received: by f493.i.mail.ru with local (envelope-from <[email protected]>) id 1ebQkt-0004Zj-4G; Tue, 16 Jan 2018 15:54:19 +0300
Received: by e.mail.ru with HTTP; Tue, 16 Jan 2018 15:54:19 +0300
From: joseph
  andrew <[email protected]>
Subject: עדיין מחכה למשוב שלך
MIME-Version: 1.0
X-Mailer: Mail.Ru Mailer 1.0
Date: Tue, 16 Jan 2018 15:54:19 +0300
Reply-To: joseph
  andrew <[email protected]>
X-Priority: 3 (Normal)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Authentication-Results: f493.i.mail.ru; auth=pass [email protected] [email protected]
X-7FA49CB5: 0D63561A33F958A5898151702DBFE222A841889EBAE90B8E20672C31CB87FE38725E5C173C3A84C39B8A9203B4187291E49527301AB7C5D479C543ECCDAE434EC4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F20A889B128FC2D163B503F486389A921A5CC5B56E945C8DA
X-Mailru-Sender: AEEF7784B292FD580FA14CB39DA65BAAC14FF9386EF48BFAB56EC34AB37A73FC68AD8B15A0E9EE36875DC23763F10D8F75E89B9EB25B1370F805D6321A69DA8E2FB9333096616C166E245241366DF001CF5B8F1B83B229A3C432A6261406F5E9E7E03437FF0094633453F38A29522196
X-Mras: OK
X-Spam: undefined

Éditer:

J'ai essayé d'envoyer avec bcc et vide "to" et gmail a montré le bcc. Donc, actuellement, la réponse @Luc semble être la vraie réponse (RCPT TO a été utilisé).

BCC try fail

emailspam
58
YoniXw

Pourquoi?

Deux explications:

  • BCC
  • Spam

J'ai souvent reçu du spam où ils semblent vouloir cacher à qui il a été adressé pour une raison quelconque. Étant donné que j'ai un fourre-tout sur mon domaine, il m'arrivera quelle que soit l'adresse utilisée (sauf s'ils en ont utilisé une que j'ai mise sur liste noire).

Comment est-ce possible?

Le trafic SMTP ressemble à ceci:

EHLO example.com 
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
RCPT TO:<[email protected]>
RCPT TO:<[email protected]>
DATA
Subject: test
From: <[email protected]>
To: <[email protected]>
CC: <[email protected]>

Hi Jake,
Just letting you know that email works.

.
QUIT

Vous pouvez ouvrir une connexion TCP à n'importe quel serveur de messagerie et taper ceci, et il vous répondra et vous enverra votre courrier électronique (j'ai omis les réponses dans l'exemple). Sous Windows, installez Telnet dans le menu des fonctionnalités de Windows et tapez telnet example.com 25 pour se connecter au serveur à example.com sur le port 25.

Comme vous pouvez le voir, user4 a été adressé dans le RCPT TO et il se retrouvera dans leur boîte de réception, mais ils ne sont pas mentionnés dans les en-têtes from, to ou cc des données e-mail. Les données de l'e-mail, de la commande DATA jusqu'au . sur une ligne à part, est la partie que vous verrez lorsque vous ouvrirez "voir la source" dans votre client de messagerie. Cela n'a donc pas grand-chose à voir avec l'échange d'e-mails. Bien sûr, cela correspond généralement, mais dans un cas malveillant, ils ne se soucient pas de ce qui est "habituel". Et dans le cas de BCC, vous ne le verrez pas non plus.

J'ai souvent reçu du spam où il se cache où il a été envoyé. Pour pouvoir le retrouver, je dois creuser dans les journaux de mon serveur de messagerie.

Un administrateur de serveur peut également rechercher des BCC comme celui-ci, mais bien sûr uniquement de leur propre domaine (s'il s'agissait de BCC pour [email protected] et [email protected], l'administrateur de a.example.com ne verra pas stefan).

Quant à savoir pourquoi vous pouvez vous envoyer GMail dans le BCC et voir un champ BCC avec vous-même répertorié sur l'extrémité de réception: le programme de messagerie/fournisseur peut simplement envoyer des messages SMTP séparés pour chaque destinataire dans le BCC, avec le BCC en-tête conçu dans l'en-tête de l'e-mail imbriqué pour répertorier uniquement ce destinataire.

84
Luc

Les en-têtes comme To, Cc et Bcc sont essentiellement tous cosmétiques; ils ne contrôlent pas le destinataire réel d'un e-mail selon le protocole SMTP. Il est possible de mettre tout ce que vous voulez dans ces champs et d'avoir toujours un contrôle séparé sur qui va l'e-mail au niveau du protocole.

Lorsque vous envoyez un e-mail sur Internet, votre serveur de messagerie expéditeur communique avec le serveur de messagerie destinataire par SMTP. Pour envoyer un e-mail, le serveur d'envoi envoie une série de commandes au serveur de réception.

  1. Une commande HELO spécifiant le nom d'hôte du serveur d'envoi (elle peut être remplacée par EHLO (abréviation de "Extended HELO") dans les versions plus récentes du protocole).
  2. UNE MAIL FROM commande annonçant l'adresse de l'expéditeur de l'e-mail.
  3. UNE RCPT TO commande annonçant les adresses des destinataires du message.
  4. Une commande DATA annonçant le début du message lui-même, y compris les en-têtes et le corps.

Les en-têtes du message tels que To, Cc ou Bcc ne sont pas traités ou utilisés, mais sont transmis sans modification.

Si ces en-têtes sont ignorés par les serveurs de messagerie d'envoi et de réception, pourquoi existent-ils?

Parce qu'ils sont une convention courante utilisée par le logiciel d'agent d'utilisateur de messagerie (client de messagerie), qui est le logiciel avec lequel l'utilisateur interagit réellement pour envoyer du courrier. La façon habituelle pour un client de messagerie de fonctionner est que l'utilisateur tape les adresses de réception dans trois champs du client de messagerie appelés "À", "Cc" et "Cci" que le client de messagerie utilise comme base pour envoyer le message à . Le client de messagerie prend ensuite ce qui a été écrit dans les champs "À" et "Cc" et les place dans des en-têtes de courrier appelés "À" et "Cc" pour indiquer au destinataire ce que l'expéditeur a initialement tapé dans ces champs. Il s'agit simplement d'une courtoisie envers le client de messagerie destinataire; le client de messagerie expéditeur pourrait choisir de garder ce secret - en effet, c'est ce qui se passe avec son champ "Cci": le client de messagerie ne crée jamais d'en-tête "Cci" dans le courrier électronique qu'il envoie, car le point de cette fonctionnalité est qu'il n'est pas inclus dans le courrier lui-même.

Le client de messagerie contient également un champ "Objet" qu'il place dans le courrier en tant qu'en-tête "Objet", et il crée un en-tête "De" dans l'e-mail avec des informations sur l'expéditeur.

Comment n'est-ce pas un problème de sécurité?

C'est. Il est très facile de mettre de fausses informations sur l'expéditeur ou les destinataires dans un e-mail. Lorsque les utilisateurs pensent que cela est exact et que ce n'est pas le cas, c'est un problème de sécurité potentiel.

Les clients de messagerie pourraient simplement ignorer de tels en-têtes, mais vous perdriez alors la commodité de savoir à qui un e-mail était adressé lorsque ces informations existent et sont authentiques, et selon la même logique, vous devriez également ignorer le "De" et expéditeur d'enveloppe (MAIL FROM command) également, ne laissant aucune indication de qui l'a envoyé. Les clients de messagerie adoptent donc l'approche selon laquelle il est plus avantageux d'afficher ces informations même si elles peuvent être truquées.

Une nouvelle norme appelée DMARC, s'appuyant sur d'autres normes DKIM et SPF, peut permettre à un client de messagerie de réception de vérifier que la partie domaine/nom d'hôte de l'en-tête "De" est authentique. Bien que cela vérifie uniquement une partie de l'en-tête "De" et ne vérifie pas l'en-tête "À" ou "Cc", cela vous permet de savoir que le le courrier provenait véritablement du système dont il prétend provenir. S'il s'agit d'un système approuvé, vous pouvez au moins en déduire que le courrier et ses en-têtes ont été créés par un utilisateur autorisé de ce système.

Outre ces options, le courrier électronique n'a tout simplement pas été conçu pour que tout cela soit vérifiable. Si vous en voulez plus, vous devez utiliser une forme de vérification cryptographique telle que PGP au-dessus de votre message et avoir un moyen hors bande de vérifier l'autorité.

32
thomasrutter

Jusqu'à présent, je pense que votre adresse a été utilisée comme BCC .

18
Mirsad

Cela peut être surprenant, mais c'est tout à fait normal dans le protocole SMTP. Un message est composé d'en-têtes et d'un corps. Il est envoyé via une chaîne d'agents de transport de courrier. Aucun agent ne doit changer le corps, mais il peut modifier les en-têtes, principalement pour ajouter un champ Received, un champ Date s'il n'est pas présent et tout autre champ requis par leur propre traitement. Mais ni le champ To ni le champ From ne sont spéciaux, et en particulier ils ne sont pas utilisés pour remettre le courrier . Les MTAs utilisent ce qu'on appelle la enveloppe, c'est ce qui est passé dans le MAIL FROM et RCPT TO commandes du protocole SMTP.

Les agents utilisateurs de messagerie (comme Thunderbird) utilisent les champs À, Cc et Cci pour créer l'enveloppe, mais si vous connaissez le protocole SMTP , il est facile d'envoyer un courrier électronique avec et contre ou vers et depuis de faux et absents. en-têtes.

15
Serge Ballesta