RFC 標準實際上迫使我們接受連接埠上未加密的連線25。要理解其中的原因，我們必須了解電子郵件的工作原理。但電子郵件是一個相當複雜的主題，我創建了這個範例並附上一個表格來嘗試理解所有內容。
誰能閱讀並告訴我我的解釋是否有任何錯誤？因為我不太確定我對這個主題的理解是否正確。
例子
當使用者（寄件者）透過以下方式發送電子郵件時“郵件用戶代理” (MUA)，此電子郵件將立即轉移至“郵件提交代理”(MSA) 位於或不在單獨的電腦上。 MSA 預處理電子郵件並將其移交給“郵件傳輸代理”(MTA) 在同一台機器上。然後，MTA（寄件者）使用 DNS 並確定應將電子郵件傳送到哪個 MTA（收件者）。這部分傳輸僅透過連接埠完成25。當 MTA（收件者）收到電子郵件時，它會將其處理到同一台電腦上的 MSA，然後使用者（收件者）可以使用 MUA 閱讀電子郵件。
MUA 和 MSA 以及 MSA 和 MTA 之間的通訊可以使用安全端口，但 MTA 和 MTA 之間的連接則不能。下表顯示了上述範例的每個步驟使用或可以使用哪些協定以及可以使用哪些連接埠。我們也使用 ✘ 和 ✔ 來指示現代設定應使用的選項。
| # | 寄件人 | 接收者 | 我們可以使用的協議 | 各協定連接埠 |
|---|---|---|---|---|
| 1 | 穆阿 | MSA | (✘) SMTP (✔) SMTPS |
(✘) 25(✔) 587 |
| 2 | MSA | MTA | (✘) SMTP (✔) SMTPS |
(✘) 25(✔) 587 |
| 3 | MTA | MTA | (✔) 郵件發送 | (✔)25 |
| 4 | MTA | MSA | (✔) 郵件發送 | (✔)25 |
| 5 | MSA | 穆阿 | (✘) POP3 (✘) POP3S (✘) IMAP (✔) IMAPS |
(✘) 110(✘) 995(✘) 143(✔) 993 |
答案1
這是基於一種誤解，即連接埠與加密有關。然而，我發現這是一個很好的問題，因為它提供了糾正這種誤解的機會。
這些連接埠並不表示加密，而是用於不同的目的：
- 連接埠
25用於 SMTP（RFC 5321）訊息中繼MTA:s 之間。 - 連接埠
587用於訊息提交（RFC 6409) 從 MUA 到 MSA。 - 這兩者都可以使用
STARTTLS(RFC 3207）。 - 此外，還有 SMTPS 將 SMTP（從 MUA 到 MSA）包裝在連接埠 上的 TLS 內
465。該標準於 1997 年註冊，但於 1998 年STARTTLS標準化後被撤銷。然而，20年後的2018年，這一情況發生了逆轉：RFC 8314現在認為明文已過時，並為 POP、IMAP 和 SMTP 提交恢復隱式 TLS。
當今大多數電子郵件在傳輸過程中（MTA 之間）都是加密的，說道Google透明度報告。
MTA 之間的通訊仍應批准未加密的連線以實現向後相容性，因此，中間人很容易透過刪除250-STARTTLS指示支援擴充的回覆來降級連線。但是，如果寄件者支持機會主義的丹麥人（RFC 7672）並且接收者有TLSA記錄表明他們不需要未加密的傳遞嘗試（作為向後相容性的例外），這種攻擊將會失敗。
下圖（抄送-SA 3.0從Ale2006-來自-en在維基百科中訊息提交代理）顯示了不同的伺服器角色，藍色箭頭可以透過不同的 SMTP 變體來實現。另請注意，同一台伺服器在傳遞訊息時可以扮演多個角色。
為了增強你的桌子：
| # | 寄件人 | 接收者 | 使用的協定和連接埠 |
|---|---|---|---|
| 1 | 穆阿 | 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 | 內部交付（同一台伺服器具有多個角色） |
| 氮 | 多發性硬化症 | 穆阿 | (✘) IMAP143和STARTTLS(✔) IMAPS 993和隱式 TLS |
最後兩個步驟不能完全視為發送者和接收者，因為訊息用戶代理MUA 連接到訊息儲存MS 並拉取訊息而不是推播。最終的 MX MTA 會將郵件傳送到 MS，其功能稱為訊息傳遞代理（MDA）。這訊息提交代理(MSA)僅指發送郵件。有關這些定義的更多詳細信息，請參見網際網路郵件架構 RFC 5598。