電子郵件傳輸範例

RFC 標準從字面上強制我們接受埠上的未加密連接25。要了解原因，我們必須了解電子郵件的工作原理。但是電子郵件是一個相當複雜的主題，我創建了這個範例和一個表格來嘗試理解所有內容。

任何人都可以閱讀並告訴我我在解釋的任何部分是否有誤嗎？因為我不太確定我對這個話題的理解是否正確。

---

例子

當使用者（發件人）通過*“郵件使用者代理”* （MUA）發送電子郵件時，該電子郵件會立即轉移到位於或不在單獨機器上的*“郵件送出代理” （MSA）。MSA 對電子郵件進行預處理並將其交給同一台機器上的“郵件傳輸代理” (MTA)。*然後 MTA（發件人）使用 DNS 並確定應將電子郵件發送到哪個 MTA（收件人）。這部分傳輸僅通過 port 完成25。當 MTA（接收者）收到電子郵件時，它會將其處理到同一台機器上的 MSA，然後使用者（接收者）可以使用 MUA 閱讀電子郵件。

MUA & MSA 和 MSA & MTA 之間的通信可以使用安全埠，但 MTA 和 MTA 之間的連接不能。下表顯示了使用或可以使用的協議以及上述範例的每個步驟可以使用的埠。我們還使用 ✘ 和 ✔ 來表示現代設置應該使用什麼。

#	發件人	接收者	我們可以使用的協議	各自協議的埠
1	MUA	MSA	(✘) SMTP (✔) SMTPS	(✘) 25 (✔) 587
2	MSA	MTA	(✘) SMTP (✔) SMTPS	(✘) 25 (✔) 587
3	MTA	MTA	(✔) SMTP	(✔)25
4	MTA	MSA	(✔) SMTP	(✔)25
5	MSA	MUA	(✘) POP3 (✘) POP3S (✘) IMAP (✔) IMAPS	(✘) 110 (✘) 995 (✘) 143 (✔) 993

這是基於一種誤解，即埠與加密有任何關係。但是，我發現這是一個很好的問題，因為它提供了糾正這種誤解的機會。

這些埠不是為了表示加密，而是用於不同的目的：

• 埠25用於MTA:s 之間的 SMTP ( RFC 5321 )消息中繼。
• 埠587用於從 MUA 到 MSA的消息送出( RFC 6409 )。
• 這兩個都可以用STARTTLS（RFC 3207）加密。
• 此外，還有 SMTPS 將 SMTP（從 MUA 到 MSA）包裝在 TLS 中的 port 上465。這在 1997 年註冊，但在 1998 年STARTTLS被標準化時被撤銷。然而，這在 20 年後的 2018 年被逆轉，因為RFC 8314現在認為明文已過時，並為 POP、IMAP 和 SMTP 送出帶回了隱式 TLS。

Google透明度報告稱，今天的大部分電子郵件在傳輸過程中（在 MTA 之間）都是加密的。

MTA 之間的通信仍應批准未加密的連接以實現向後兼容性，因此，中間人很容易通過刪除250-STARTTLS表示支持擴展的回復來降級連接。但是，如果發送方支持機會性 DANE ( RFC 7672 ) 並且接收方有TLSA記錄表明他們不需要未加密的傳遞嘗試（作為向後兼容性的例外），這種攻擊將會失敗。

下圖（維基百科消息送出代理中Ale2006-from-en的CC BY-SA 3.0）顯示了不同的伺服器角色，藍色箭頭可以通過不同的 SMTP 變體實現。另請注意，同一伺服器在傳遞消息時可以具有多個角色。

要增強您的表：

#	發件人	接收者	使用的協議和埠
1	MUA	MSA	(✘)587使用STARTTLS(✔)465帶有隱式 TLS 的SMTPS 送出
2	MSA	MTA	內部傳遞（具有兩個角色的同一伺服器）
3…	MTA	MTA（可能是MX）	(✘✘) 未加密的 SMTP 25(✘)25帶有STARTTLS (✔) SMTP的 SMTP 25，STARTTLS由 DANE 強制執行
N-1	MX	MDA➔MS	內部傳遞（具有多個角色的同一伺服器）
ñ	多發性硬化症	MUA	(✘) IMAP143和STARTTLS (✔) IMAPS993和隱式 TLS

最後兩個步驟不能完全被視為發送者和接收者，因為消息使用者代理MUA 連接到消息儲存MS 並拉取消息而不是推送。最終的 MX MTA 使用稱為消息傳遞代理(MDA)的功能將郵件傳遞給 MS 。消息送出代理( MSA) 僅指發送郵件。有關這些定義的更多詳細資訊，請參閱Internet Mail Architecture RFC 5598。

引用自：https://serverfault.com/questions/1045480