"To"フィールドなしでこのEメールを受信した

私は自分の言語(ヘブライ語)で私はまだあなたのフィードバックを待っていますに翻訳できるタイトルだけの空のEメールを得ました。

私のGmailは複数のアカウントを(順方向とユーザーパスで)扱っているので、どのアカウントがターゲットだったのかを見つけようとしました。驚いたことに - なし!

Strange email without To

私の質問は簡単です、なぜGmailは私の受信箱にこのEメールを入れることを選んだのですか?私の検閲された電子メールを除いて、添付のジャバラは からの電子メールの完全な情報源です。 これはセキュリティ違反ではなく、スパムフィルターによって阻止されていません。


オリジナルメッセージ:

  • Message ID <[email protected]>
  • Created at: Tue, Jan 16, 2018 at 2:54 PM (Delivered after 2 seconds)
  • From: joseph andrew Using Mail.Ru Mailer 1.0
  • To:
  • Subject: עדיין מחכה למשוב שלך
  • SPF: PASS with IP 217.69.138.160 Learn more
  • DKIM: 'PASS' with domain bk.ru Learn more
  • DMARC: 'PASS' Learn more
Delivered-To: ********@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: 
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 ) 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 
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 
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

編集する

bccと空の "to"で送信しようとしたところ、gmailはbccを表示しました。そのため、現在@Lucという回答が本当の回答のようです( RCPT TO が使用されています)。

BCC try fail

55
ちょっと注意:「Edit:」イメージでEメールの名前をカバーしようとする試みは本当に十分ではありません。完全な文字が網羅されていないだけでなく、網羅されている部分がすべての場合で異なり、テキストの大部分が検索可能になります。
追加された 著者 ehfeng,
送信側からのメッセージを見ると、 Bcc ヘッダーが保存される可能性が非常に高いです。しかし、受信機にはあってはいけません。
追加された 著者 user118457,
「どのアカウントがターゲットだったのかを特定しようとしました」 - 信頼できない送信者の管理下にあるため、「To」MIMEヘッダーは使用できません。代わりにDelivered-Toヘッダーを見てください。サーバ。
追加された 著者 FatalSleep,
封筒に入った手紙を考えてください。レターには "To"フィールドがあってもなくても構いません。エンベロープのアドレスが指定されている場所に到達することはあります。彼女がそうしたいのであれば、アリスと郵便でチャーリーからダビデへ手紙を送ってください。
追加された 著者 David Schwartz,
Thunderbird(またはNetscapeコミュニケータ)の@ToddWilcox旧バージョンでは、 BCC だけでなく To または CC フィールドに有効なアドレスが必要です。 。これは、意図した受信者をBCCして自分宛の電子メールを することが一般的なパターンであることを意味していました。これはなぜそれがあなたのユーザーの何人かに受け入れられたか説明するかもしれません
追加された 著者 Chris H,
@ nisarg-shah似ていますが違います。ここでのEメールソースには、私の受信箱にこのEメールを配信することを正当化するフィールドはありませんでした。
追加された 著者 Magnus Reftel,
私の大学は大量メール送信のターゲットとして偽のアカウントを使用しています。電子メールにはTo:Students-Cloud、またはそれに類するものが含まれます。会社が空白のToフィールドを使用すると、混乱を招くだけです。
追加された 著者 CAD97,
あなたのBCCテストは良いテストではありません。あなたはGMailを使っています、(a)自分が送信者であることを知っています。(b)とにかく奇妙なことをするかもしれません。テストするには、最低でも別のアドレス(自分のアドレスではないアドレス)から送信する必要があります。また、GMailをクライアントとして使用しないことをお勧めします。
追加された 著者 Preston,
編集は、自己回答や更新としてではなく、質問の一部を明確にするために使用する必要があります。あなたの更新はおそらく @ luc's answer にコメントとして投稿されるべきです。
追加された 著者 Steven Vascellaro,
空白のTo:フィールドを拒否するようにスパムフィルタを設定したので、スパムフィルタがこれを止めることは可能です。不利な点は、合法的な(そして私見が愚かな)送信者は空白のTo:フィールドを望んでいるので、自分のアドレスをすべて公開せずに多数の人々に電子メールを送信できることです。自分のアドレスと同じように何かを迷惑メールで空の "To:"フィールドを許可するように指示された場所に入力しなければならないと言うことをやめたことがあります。フィルタ。
追加された 著者 pinguinos,
追加された 著者 Suresh,

4 答え

どうして?

2つの説明

  • BCC
  • スパム

何らかの理由で対処された相手に隠れたいと思う場所でスパムを頻繁に入手します。私は自分のドメインにキャッチオールを持っているので、彼らがどんなアドレスを使ったとしてもそれは私に届くでしょう(彼らが私がブラックリストに載せたものを使わない限り)。

これはどのように可能ですか?

SMTPトラフィックは次のようになります。

EHLO example.com 
MAIL FROM:
RCPT TO:
RCPT TO:
RCPT TO:
DATA
Subject: test
From: 
To: 
CC: 

Hi Jake,
Just letting you know that email works.

.
QUIT

あなたはどんなメールサーバへのTCP接続を開いてこれをタイプすることができます、そしてそれはあなたに返事をしあなたの電子メールを届けるでしょう(私は例で返事を省略しました)。 Windowsでは、Windowsの機能メニューからTelnetをインストールし、 telnet example.com 25 と入力してポート25の example.com でサーバーに接続します。

ご覧のとおり、user4は RCPT TO でアドレス指定されており、最終的には電子メールの受信トレイに入りますが、電子メールデータのfrom、to、またはccヘッダーには記載されていません。 DATA コマンドからまでの1行の電子メールデータは、電子メールクライアントで[ソースの表示]を開いたときに表示される部分です。したがって、実際のEメール交換とはほとんど関係ありません。もちろんそれは通常は一致しますが、悪意のある場合には「通常」とは関係ありません。そしてBCCの場合にはそれも見えないでしょう。

送信先を隠す場所で迷惑メールを受け取ることがよくあります。それをたどることができるようにするために、私は私のメールサーバログを掘り下げる必要があります。

もちろん、自分自身のドメイン( [email protected] [email protected]>の場合のみ)でも、サーバー管理者はこのようにBCCを検索することもできます。 com a.example.com の管理者にはstefanが表示されません)。

なぜあなたはBCCであなた自身にGMailを送ることができて、あなた自身が受信側にリストされているBCCフィールドを見ることができます:Eメールプログラム/プロバイダーはBCCのそれぞれの受取人に対して別々のSMTPメッセージを送ることができます。/code> headerその受信者だけを一覧表示するためにネストされた電子メールヘッダーで作成されました。

80
追加された
@JIK:受信者に配信されました 。ソースの一番上にある Delivered-To MIMEヘッダーにあります。それはそれを表示していない単なる電子メールプログラムです。
追加された 著者 FatalSleep,
@ JiK(a)当時のインターネットはもっと無実でした。 (b) RCPT TO:行は封筒の住所のようなもので、 To:行はその中の文字に表示されているものです。あるオフィスでは、メールルームのスタッフが封筒を開けて(Private&Confidentialを明記していない限り)、その中身だけを提供していたのが以前のようです。 SMTPはそのように動作します。
追加された 著者 Metalskin,
この情報が通常受信者に配信されない理由はありますか?私には、電子メールプロトコルを設計するときにやるべきことは明らかに必要なことのように思えます。
追加された 著者 JiK,

To Cc 、および Bcc などのヘッダーは、基本的にすべて装飾的です。それらはSMTPプロトコルに従って電子メールの実際の受信者を制御しません。あなたが好きなことは何でもこれらのフィールドに入れて、それでもプロトコルレベルでEメールが誰に行くかを別々に制御することが可能です。

インターネットにEメールを送信すると、送信側メールサーバーは受信側メールサーバーとSMTPで通信します。電子メールを送信するために、送信側サーバーは一連のコマンドを受信側サーバーに送信します。

  1. 送信サーバーのホスト名を指定する HELO コマンド(これは新しいバージョンのプロトコルでは EHLO ( "Extended HELO"の略)に置き換えられます)
  2. Eメールの送信者のアドレスをアナウンスする MAIL FROM コマンド。
  3. メッセージ受信者のアドレスをアナウンスする RCPT TO コマンド。
  4. ヘッダーと本文を含む、メッセージ自体の開始を通知する DATA コマンド。

To Cc Bcc などのメッセージ内のヘッダーは処理も使用もされませんが、そのまま送信されます。

これらのヘッダーが送受信メールサーバーで無視されている場合、なぜそれらが存在するのですか?

なぜならそれらはメールユーザーエージェント(メールクライアント)ソフトウェアによって使用される一般的な規約であるからです。これはユーザーが実際にメールを送信するために対話するソフトウェアです。メールクライアントが機能するための通常の方法は、メールクライアント内の3つのフィールド「To」、「Cc」、および「Bcc」に受信者アドレスを入力することです。 。そしてメールクライアントは、 "To"と "Cc"フィールドに書かれたものを受け取り、それらを "To"と "Cc"と呼ばれるメールヘッダに送ります。これは単に受信側メールクライアントにとっての好意です。送信側のメールクライアントはこの秘密を守ることを選択できます - 実際、それは "Bcc"フィールドで起こることです:メールクライアントは送信する電子メールに "Bcc"ヘッダを作成しませんメール自体に。

メールクライアントには、 "件名"ヘッダーとしてメールに入れる "件名"フィールドも含まれており、送信者に関する情報を含む "From"ヘッダーを電子メールに作成します。

これはセキュリティ上の問題ではないのですか。

そうです。それは送信者または受信者に関する偽の情報をEメールに入れることを簡単にします。これが正確であるとユーザーが信じているが、そうではないとすると、それは潜在的なセキュリティ問題です。

メールクライアントはそのようなヘッダを単に無視することができますが、その場合、この情報が存在し、本物であるときに電子メールが誰に宛てられたのかを知るという便利さを逃すことになります。封筒送信者( MAIL FROM コマンド)も同様に、誰が送信したのか表示されません。そのため、メールクライアントは、たとえ偽造されたとしても、この情報を表示することにはより多くの利益があるというアプローチを取ります。

DMARCと呼ばれる新しい規格で、他の規格のDKIMとSPFに便乗したもので、受信側のメールクライアントが "From"ヘッダのドメイン/ホスト名部分が本物であることを検証することを可能にします。これは "From"ヘッダーの部分のみを検証し、 "To"や "Cc"ヘッダーを検証することはしませんが、そのメールが本物のものであることを知ることができます。 。これが信頼できるシステムである場合は、少なくともメールとそのヘッダーがそのシステムの許可ユーザーによって作成されたと推測できます。

これらのオプション以外にも、電子メールは単に検証可能になるように設計されていません。もっと欲しい場合は、メッセージの上にPGPなどの何らかの形式の暗号検証を使用し、権限を検証するための何らかの帯域外の方法が必要です。

30
追加された
「プロトコルのより新しいバージョン」と言うとき、それは「1995より新しい」という意味です。
追加された 著者 deceze,
@HopefullyHelpful邪魔にならない。そのような古い標準を変更することは非常に困難であり、それを使用するほとんどすべてを完全に壊すことはありません。 SMTPは、ユーザーが科学者であることを想定していました。エンドユーザーはセキュリティでした。インターネットは、コンシューマサービスとしてはまったく設計されていませんでした。程遠い。
追加された 著者 plusplus,
@ mattdmハハええ。ちょっと私はphoto.stackexchangeであなたを知っています!
追加された 著者 Wasabi,
@TobySpeightこれは、 RCPT-TO が1つしかない場合にのみ当てはまります。
追加された 著者 Russ Clarke,
すべての学年が終わっても、より安全な標準を実装することに悩まされている人はいません。
追加された 著者 HopefullyHelpful,
おそらく、MTAの Received:ヘッダーに for 句が含まれ、そのホップのエンベロープ RCPT TO が表示されることを言及する価値があります。確認はしていませんが、受信者が1人の場合にのみ行われることを期待しています(プライバシーのため)。質問のヘッダーには、そのような for 句はありません。
追加された 著者 brandonmack,

これまでのところ、あなたのアドレスは BCC として使用されていたと思います。

18
追加された
それが最も単純で論理的な説明です。
追加された 著者 baldPrussian,
私は試してみましたが再現できませんでした。上記のLucの答えは正しいもののようです(私の編集を見てください)
追加された 著者 Magnus Reftel,
@baldPrussian 最短
追加された 著者 usr-local-ΕΨΗΕΛΩΝ,

驚くことかもしれませんが、これはSMTPプロトコルではかなり普通のことです。メッセージはヘッダと本文から構成されています。メールトランスポートエージェントのチェーンを介して送信されます。どのエージェントも本体を変更するべきではありませんが、主に Received フィールド、存在しない場合は Date フィールド、およびその他の要求に応じてその他のフィールドを追加するためにヘッダーを変更できます。独自の処理ただし、 To フィールドも From フィールドも特別なものではなく、特にメールの配信には使用されていません。 MTAはエンベロープと呼ばれるもの、つまりSMTPプロトコルの MAIL FROM RCPT TO コマンドで渡されるものを使用します。

Thunderbirdのようなメールユーザエージェントは、To、Cc、Bccの各フィールドを使ってエンベロープを作成しますが、 SMTPプロトコルを使用すると、ToおよびFromヘッダーが偽造された、または存在しないメールを簡単に送信できます。

15
追加された