題 發送給我的電子郵件地址是MAIL@MAIL.COM。這是怎麼做到的?


我最近收到了一封騙局電子郵件,為了咯咯笑,我打開它閱讀它。非常簡單,並沒有太多的努力投入。

我注意到一些奇特的東西;這封電子郵件不是發給我的。 起初,我懷疑是CC或BCC,但它在郵件上沒有我的地址。我在下面提供了一張圖片。這是怎麼做到的?

enter image description here


103
2018-05-15 18:22


起源


發布完整的郵件標題...也可能在電子郵件服務器上有一個輔助SMTP地址,可能是這個。電子郵件服務器管理員應該能夠為此提供建議,但是 編輯 您也可以回答並發布此郵件的完整郵件標題詳細信息。 - Pimp Juice IT
你可能在 盲目複印 電子郵件的領域。 - Mokubai♦
你不會看到BCC列表, 那是“B”的外皮部分。 ;) - Ƭᴇcʜιᴇ007
@tuskiomi不,不在Outlook中。 Gmail確實顯示 bcc: me也許其他人也這樣做......但是如果你查看完整的郵件標題,你應該在那裡看到你的電子郵件 - wysiwyg
@tuskiomi - 不,你永遠不會看到任何人在BCC中列出,甚至不是你自己。此外,如果它是垃圾郵件,甚至可能沒有真正的BCC列表;垃圾郵件可以以任何方式管理收件人列表,最重要的是垃圾郵件與郵件服務器的對話是什麼樣的 - 而不是郵件的內容。如果您查看互聯網標題,您將看到您的電子郵件地址的唯一方法。 - Jeff Zeitlin


答案:


Internet電子郵件由兩部分組成。我們可以將它們稱為 信封 和 有效載荷消息 或簡單地說 信息

信封有路由數據: 主要是,這是發件人地址和一個或多個收件人地址。

消息包含消息內容: 主題行,郵件正文,附件等。它還帶有一些技術信息,如trace(Received:)標題,DKIM數據等;以及 顯示 發件人和收件人地址(你在中看到的) FromTo 和 Cc 郵件客戶端中的字段)。

這是它的關鍵所在: 兩人不必同意!

郵件服務器將查看信封數據以確定如何發送郵件。另一方面,除了少數例外,消息本身將被視為數據。特別是一個表現良好的郵件服務器 才不是 看著那(這 To: 和 Cc: 消息本身的字段用於確定收件人列表,也不會查看收件人列表 From: 字段以確定發件人的地址。

撰寫和發送電子郵件時, 您的電子郵件客戶端將您輸入的內容轉換為“收件人”,“抄送”和“密件抄送”字段,並將其轉換為信封路由信息。 這主要通過刪除任何全名(僅留下電子郵件地址)來完成,但也可能涉及地址重寫,別名擴展等內容。結果是一個電子郵件地址列表,該郵件地址被提供給您的郵件客戶端正在與之通信的郵件服務器作為收件人列表。 “收件人”和“抄送”列表保留在電子郵件中,但密件抄送不會傳遞到服務器,使郵件收件人不可見。 發件人地址非常相似。

當郵件到達其最終目的地時,信封數據將被丟棄,或保留在詳細的郵件標題中。這就是為什麼Spittin的IT在對您的問題發表評論時要求提供完整郵件標題的原因之一。

此外,通過Internet電子郵件,可以直接與郵件服務器通信,從而注入包絡數據與正常的消息數據不匹配的消息, 規矩 電子郵件客戶端不會讓你撰寫。也, 郵件服務器對包絡數據中給出的發件人地址進行不同程度的檢查;有些人根本沒檢查過 除了確保它是一個 語法 合法的郵件地址。 消息數據的From標題受到更嚴格的審查。

由於接收電子郵件客戶端顯示From,To和Cc標題中的內容,而不是信封中的地址數據, 你可以在那裡放任何你想要的東西 並且接收電子郵件客戶端將無法追索,但相信它是合理準確的。對於合法郵件,它通常足夠準確;對於垃圾郵件,它幾乎從來都不是。

在我們僅僅是人類居住的有形物體世界中, 該 信封發件人 和 信封收件人 對應於您在信封外面寫的返回地址和收件人地址;和 From: 和 To:/Cc: 標題分別對應於您在信封中放入的字母中作為您和收件人地址的內容。


154
2018-05-15 18:56



我希望人們在這裡做出更真實的比喻,以便其他人能夠理解物理等價物是什麼。電子郵件的“發件人”就像把郵遞員遞給信封的人; “來自”地址是它的目的地。就像你可以成為秘書一樣,代表別人發送,等等。 - Mehrdad
@Mehrdad No; (SMTP) 信封發件人 地址就像信封外面的返回地址(如果無法傳遞它將被發送),而地址則在 From 標題是你在你堅持的那張紙上寫的任何東西 內 信封和郵遞員甚至都不知道。 - α CVn
當我寫這篇文章的時候,我在想著Sender:標題,這只是一個例子。只是說將這樣的例子添加到你的答案中會很好。 - Mehrdad
該 這裡的粗體數量 是真的 最多是不必要的。那就是 只有我的意見。 - JakeGould
@SupremeGrandRuler因為 接受者 電子郵件中不包含信息(與可能的發件人或回程路徑相反)。想像一下,包括完整的收件人列表,包括MUA從密件抄送字段獲得的地址(記住:SMTP(信封協議)不知道密件抄送,它只知道收件人)...這是一個隱私問題(和巨大的空間浪費)不僅在大型郵件列表上(按照與Bcc相同的原則運行)。 - Jonas Schäfer


tl;博士在底部。

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.

.

現在,在這種情況下,Anonymous收到了有關此會議的消息。但是,這個版本的郵件是  路過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.

.

在這裡,由於Anonymous在BCC中,發送給Jane Doe的消息不包括BCC收件人列表。由於BCC約定,電子郵件信封可能不包括實際接收郵件的收件人,並且還可能包括未顯示在郵件標題中的收件人。

如上所述 @JonasWielicki我還要包括的是,MUA(郵件用戶代理)通常負責發送實現BCC所需的多個電子郵件。電子郵件服務器對BCC一無所知,因此MUA必須通過發送多封包含在信封標頭中指定的不同電子郵件路由的電子郵件來實施BCC。因此,BCC通常比普通電子郵件需要更長的時間,因為必須構建不同的郵件正文並單獨發送。

這也有助於一些電子郵件合規性規則。例如,郵件服務器可能具有配置為自動BCC存檔電子郵件服務器的規則(發送給它的所有電子郵件也被存檔),在這種情況下,郵件服務器甚至可能不是真正的收件人。

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;博士

因此,總而言之,發件人欺騙了一封電子郵件,原始郵件服務器接受/轉發了它,您的電子郵件服務器接受了它並將其存儲在您的收件箱中,您的客戶端忠實地向您顯示收件箱中的數據,所有這些都沒有繞過任何安全。從這個角度來看,“發送”安全性通常比“接收”安全性要少得多,因為POP3在訪問郵箱之前幾乎總是需要用戶名和密碼(理論上你可以繞過它,但我不知道任何合法的郵件服務)。


23
2018-05-16 00:33



您應該注意通常剝離密件抄送 不 由郵件服務器處理(否則您提供的SMTP腳本建議,因為HELO聽起來像郵件服務器而不是MUA)。要向該標題中提到的人提供密件抄送標題的副本,需要MUA通過發送兩封單獨的電子郵件來進行額外的工作。 - Jonas Schäfer
@JonasWielicki這是一個好點。我添加了一個編輯效果。 - phyrfox
如果你在發送的郵件中添加一個密件抄送行,它就不再是盲目了:) - eckes
實際上要求客戶端在BCC的情況下發送多條消息是不正確的。發送一條消息是完美的聲音。 SMTP客戶端可以列出多個 RCPT TO 說明。唯一的要求是接收SMTP服務器要么是兩個收件人的權威服務器,要么願意轉發任何不是。 - Patrick


從安全性和身份驗證不太重視的時代開始,SMTP和電子郵件是非常古老的Internet服務(DNS是另一個例子)。協議的設計不會驗證發件人地址的真實性,只會驗證收件人地址,因為它確保郵件是可交付的。

電子郵件通過SMTP協議傳輸。 SMTP協議相對愚蠢;它提供了一個將明文傳輸到電子郵件地址的工具,而且幾乎沒有。該明文的結構由下式定義 RFC 5322。一般的想法是電子郵件文本具有稱為標題的元數據,以及消息的實際文本正文。此電子郵件標題由發件人生成(不可信任)並包含“to:”,“from:”,“subject:”等字段...

SMTP協議不會(並且不應該)驗證電子郵件標頭是否與SMTP協議中定義的極少數內容相匹配,這些內容基本上是您的電子郵件地址和從未以任何方式驗證的發件人電子郵件地址。

電子郵件中的幾乎所有內容都可能是假的。

今天唯一對遠程可信賴的電子郵件內容是DKIM簽名,這證明該電子郵件是通過域名註冊人批准的電子郵件服務器處理的。深入挖掘,您會發現此騙局電子郵件沒有DKIM簽名。


6
2018-05-15 22:28



我要加上決賽 Received: 標頭由您自己的系統添加到可信賴的部分。 - Hagen von Eitzen


地址 To 在電子郵件標題中用於信息目的,它由電子郵件客戶端顯示。真實的收件人地址是給出的 RCPT TO 在SMTP中。如果你寫信,放入信封,在信封上寫地址-1,也是一樣的。然後去快遞,給另一個地址-2。快遞員將您的信封放在地址為2的更大信封中,貨物將運到那裡。您的秘書(電子郵件客戶端軟件)將外部信封放入垃圾箱,並顯示帶有地址-1的內部信封。您可以通過電子郵件的RAW視圖查看此信息。


3
2018-05-16 08:33





這是一個略有不同的外觀,基於檢查標題。其他答案比我能更好地處理SMTP的細節。

如果您可以獲得郵件的完整標題,那麼請搜索他們的地址 可以 在一個叫做的領域找到它 Envelope-toDelivered-to 要么 X-Apparently-to。第一個由我的郵件提供商使用,第二個由Gmail使用;我也見過第三個用過的。這些是不同的字段,但對於我們的目的而言往往意味著相同的事情:實際傳遞消息的郵箱。我通過發送Outlook(桌面版)與收件人BCCed進行測試。

我的郵件提供商也使用 Delivered-To 字段,但用於其服務器上的郵箱名稱。這不是我的電子郵件地址,雖然它看起來像一個(想想 ChrisH-$ACCOUNTNAME@$SERVER.mail.com)。

另一方面,Outlook(與Exchange服務器結合使用)在標題中不包含帶有收件人電子郵件地址的單個字段(如果您列為BCC)。


2
2018-05-16 08:23