私に送信された電子メールはMAIL@MAIL.COM宛に送られます。これはどのように行われますか？

私は最近詐欺メールを送られ、笑いのためにそれを開いてそれを読みました。非常に単純で、あまり労力を投入しません。

奇妙なことに気づきました。このメールは私宛ではありません。最初、CCまたはBCCを疑っていましたが、メールに住所が記載されていません。以下の写真を提供しました。これはどのように行われますか？

インターネット電子メールメッセージは2つの部分で構成されています。私たちはそれらをエンベロープおよびペイロードメッセージまたは単にメッセージと呼ぶことができます。

エンベロープにはルーティングデータがあります。主に、これは送信者アドレスと1つ以上の受信者アドレスです。

メッセージには、件名行、メッセージ本文、添付ファイルなどのメッセージコンテンツがあります。また、トレース（Received:）ヘッダー、DKIMデータなどの技術情報も保持しています。表示された送信者と受信者のアドレス（メールクライアントのFrom、ToおよびCcフィールドに表示されるもの）と同様に。

重要な点は次のとおりです。両者は同意する必要はありません。

メールサーバーは、エンベロープデータを見て、メッセージの送信方法を決定します。一方、例外はほとんどありませんが、メッセージ自体は単なるデータとして扱われます。特に、行儀の良いメールサーバーは、メッセージ自体のTo:およびCc:フィールドを見て受信者のリストを決定したり、From:フィールドを見て送信者のアドレスを決定したりしません。

電子メールを作成して送信すると、電子メールクライアントは、To、Cc、およびBccフィールドに入力した内容を取得し、それをエンベロープルーティング情報に変換します。これは主に完全な名前を削除することによって行われます（電子メールアドレスのみを残します）が、アドレスの書き換え、エイリアスの展開などのことも含まれます。結果は、メールクライアントが受信者のリストとして通信しているメールサーバーに与えられる電子メールアドレスのリストです。ToおよびCcリストは電子メールに保持されますが、Bccはサーバーに渡されないため、メッセージの受信者には見えません。送信者アドレスは非常によく似ています。

メッセージが最終的な宛先に到達すると、エンベロープデータは破棄されるか、詳細なメッセージヘッダーに保持されます。それが、Spittin 'ITが質問へのコメントで完全なメッセージヘッダーを要求した理由の1つです。

さらに、インターネット電子メールを使用すると、メールサーバーと直接通信することができるため、エンベロープデータと通常の正常な電子メールクライアントではできないメッセージデータとの間に不一致があるメッセージを挿入できます。作曲しましょう。また、メールサーバーは、エンベロープデータで指定された送信者アドレスに対してさまざまな程度のチェックを行います。構文的に有効な電子メールアドレスであることを確認する以外に、ほとんどまったくチェックしない人もいます。メッセージデータのFromヘッダーは、さらに監視の対象となりません。

受信側の電子メールクライアントは、ヘッダー、いない封筒からのアドレスデータにとCC、から何表示するので、それはそこにあなたが欲しいものを置くことが可能ですし、受信側の電子メールクライアントがあること、それを信用するしか遡求権を持っていませんかなり正確です。正当なメールの場合、通常は十分に正確です。スパムの場合、ほとんどありません。

単なる人間である有形の物理オブジェクトの世界では、エンベロープ送信者とエンベロープ受信者は、それぞれエンベロープの外側に書き込む返信先アドレスと受信者アドレスに対応しています。そしてFrom:およびTo:/ Cc:ヘッダは何でも、あなたは封筒に入れて手紙の中で、それぞれ、あなたと受信者のアドレスとして入れて対応しています。

tl; dr下部。

SMTPプロトコルには、CCまたはBCCの受信者という概念はありません。これは、メールクライアントが保持する規則です。SMTPサーバーは通常、ルーティング情報とデータのみを考慮します。この機能がなければ、BCCは存在し得ないため、これは重要な違いです。正当なBCC通信として、次のクライアントのトランスクリプトを考慮してください。

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.

.

さて、この場合、アノニマスにはこの会議に関するメッセージが送信されました。ただし、このバージョンのメールはJane Doeにルーティングされませんでした。彼女は匿名が通知されることについて何も知りません。対照的に、Jane Doeには、異なる本文とヘッダーを持つメッセージが送信されます。

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.

.

ここでは、匿名がBCCにあったため、Jane Doeに送信されたメッセージにはBCC受信者リストが含まれていませんでした。BCC規則により、電子メールエンベロープには、実際にメッセージを受信した受信者が含まれていない場合があり、メッセージヘッダーに表示されない受信者も含まれている場合があります。

@JonasWielickiで述べたように、これも含めるつもりでしたが、MUA（Mail User Agent）は通常、BCCの実装に必要な複数の電子メールの送信を担当します。電子メールサーバーはBCCについて何も知らないため、MUAはエンベロープヘッダーで指定された異なる電子メールルートで複数の電子メールを送信することにより、BCCを実装する必要があります。このため、異なるメッセージ本文を個別に作成して送信する必要があるため、BCCは通常、通常のメールよりも送信に時間がかかります。

これは、一部のメールコンプライアンスルールにも役立ちます。たとえば、メールサーバーには、アーカイブEメールサーバーを自動的にBCCするように構成されたルールがあります（送信されたすべてのEメールもアーカイブされます）。

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.

.

ここで、受信者は、受信者のいずれかまたは送信者にさえ完全に開示されていない別の当事者です。これはプロトコルの機能であり、通常はメッセージの中継またはアーカイブに使用されます。

このスパムメッセージは、その動作を利用しています。これは、技術的に準拠しているメールサーバーで動作する標準的な抜け穴です。もちろん、多くの更新されたサーバーは、DKIMのような「拡張機能」を使用して、そのような電子メールが本物であることを確認しますが、壊れていないものを修正しないようにしたいだけで、気にしない古いメールサーバーがまだたくさんあります。

また、Dateヘッダーの指定方法にも注意してください。これは、任意の（ただし適切にフォーマットされた）値にすることができます。多くのクライアントは、遠い過去から遠い未来までの法的日付範囲を喜んで表示します。私は数年前に自分自身にメールを送信しました。このメールは、平均寿命を過ぎてもメールボックスの一番上に表示されたままになります。

tl; dr

つまり、要約すると、送信者は電子メールを偽装し、発信元のメールサーバーはそれを受け入れ/中継し、電子メールサーバーはそれを受け入れて受信トレイに保存し、クライアントは受信ボックスにあったデータをすべて迂回せずに忠実に表示しましたセキュリティ。POP3は、メールボックスにアクセスする前にほとんど常にユーザー名とパスワードを必要とするため、「送信」セキュリティは「受信」セキュリティよりもはるかに制限されないことがよくあります（理論的にはこれを回避できますが、正当なものは知りません）するメールサービス）。

SMTPと電子メールは、セキュリティと認証がそれほど重要視されていなかった時代の非常に古いインターネットサービスです（DNSも別の例です）。プロトコルの設計では、送信者アドレスの信頼性を検証する努力はせず、メールが配信可能であることを確認している限り、受信者アドレスのみを検証します。

電子メールは、SMTPプロトコルを介して送信されます。SMTPプロトコルは比較的馬鹿げています。電子メールアドレスにプレーンテキストを送信する機能を提供します。この平文の構造は、RFC 5322で定義されています。一般的な考え方は、電子メールテキストにヘッダーと呼ばれるメタデータと、メッセージの実際のテキスト本文があることです。この電子メールヘッダーは送信者によって生成され（いずれも信頼できない）、「to：」、「from：」、「subject：」などのフィールドが含まれます。

SMTPプロトコルは、電子メールヘッダーがSMTPプロトコルで定義されたごくわずかなものと一致することを検証しません（基本的には検証されない送信者の電子メールアドレスです）。

電子メールメッセージのほとんどすべてが偽物である可能性があります。

今日の電子メールの内容についても遠隔的に信頼できる唯一のものはDKIM署名です。さらに掘り下げると、この詐欺メールにはDKIM署名がないことがわかります。

To電子メールヘッダーのアドレスは情報提供を目的としており、電子メールクライアントによって表示されます。実際の受信者アドレスはRCPT TO、SMTPで指定されます。手紙を書いたり、封筒に入れたり、封筒に住所-1を書いたりしても同じです。その後、宅配便に行き、別のアドレス2を指定します。宅配便業者は、住所2の大きな封筒に封筒を入れて、そこに発送します。秘書（メールクライアントソフトウェア）は、外部エンベロープをゴミ箱に入れて、Address-1の内部エンベロープを表示します。これは、電子メールメッセージのRAWビューで確認できます。

これは、ヘッダーの検査に基づいて、わずかに異なる外観です。他の答えは、SMTPの詳細を私よりもうまく処理します。

あなたのメッセージの完全なヘッダを得ることができる場合、あなたのアドレスのためにそれらを検索し、それから、あなたは可能というフィールドでそれを見つけるEnvelope-to、Delivered-toまたはX-Apparently-to。最初は私のメールプロバイダーによって使用され、2番目はGmailによって使用されます。3番目も同様に使用されています。これらは異なるフィールドですが、私たちの目的では、同じことを意味する傾向があります。実際にメッセージを配信するメールボックスです。Outlook（デスクトップバージョン）から送信して、受信者BCCを送信してテストしました。

私のメールプロバイダーもこのDelivered-Toフィールドを使用しますが、サーバー上のメールボックス名に使用します。これは私のメールアドレスではありませんが、1つのように見えます（考えてみてくださいChrisH-$ACCOUNTNAME@$SERVER.mail.com）。

一方、Outlook（Exchangeサーバーと組み合わせた場合）は、BCCとしてリストされている場合、ヘッダーに受信者のメールアドレスを含む単一のフィールドを含めません。