簡單郵件傳輸協議

簡單郵件傳輸協議（英語：Simple Mail Transfer Protocol，縮寫：SMTP）是一種用於電子郵件傳輸的網際網路標準通信協議。郵件伺服器使用SMTP來發送和接收郵件。電子郵件客戶端通常僅使用SMTP將郵件發送至郵件伺服器進行中繼，並通常在埠587或465上提交外發郵件（依據RFC 8314）。用於接收郵件的標準協議是IMAP（取代了舊的POP），但專有伺服器也常常實現專有協議，例如Exchange ActiveSync。

SMTP起源於1980年，基於1971年在ARPANET上實施的概念構建。此協議已多次更新、修改和擴展。目前普遍使用的版本具有可擴展的結構，支持多種擴展功能，如身份驗證、加密、二進位數據傳輸和國際化電子郵件地址。SMTP伺服器通常使用TCP，在埠25（用於伺服器之間）和埠587（用於來自已認證客戶端的提交）上運行，支持加密與非加密兩種方式。

## SMTP發展歷史

### SMTP的前身

在1960年代，不同形式的一對一電子資訊傳遞已在使用，使用者通過為特定大型計算機開發的系統進行通信。隨著電腦互聯增多，尤其是在美國政府的ARPANET中，逐漸制定了標準以允許在不同作業系統之間交換消息。

ARPANET上的郵件可以追溯到1971年：當時提出了未實現的Mail Box Protocol（郵件盒協議），該協議在RFC 196中有討論；同年，BBN的Ray Tomlinson改造了SNDMSG程序，使其能夠在ARPANET上的兩台電腦間發送消息。隨後在1973年6月的RFC 524中提出了另一種郵件協議，但同樣未被實現。

1973年3月，RFC 469建議使用文件傳輸協議（FTP）在ARPANET上進行網路郵件傳輸。通過RFC 561、RFC 680、RFC 724以及最終在1977年11月發布的RFC 733，形成了使用FTP郵件伺服器的標準化電子郵件框架。

SMTP的發展源於1970年代制定的這些標準。Ray Tomlinson在1974年9月的INWG協議備忘錄2中討論了網路郵件。1979年，INWG討論了電子郵件協議，該討論內容在Jon Postel關於網際網路郵件的早期工作中有引用。Postel在1979年首次提出了網際網路消息協議，作為網際網路實驗報告（IEN）系列的一部分。

### 原始的SMTP

1980年，Postel和Suzanne Sluizer發布了RFC 772，提出了郵件傳輸協議（Mail Transfer Protocol）以替代FTP用於郵件傳輸。1981年5月，RFC 780取消了所有對FTP的引用，並為TCP和UDP分配了埠57（但IANA後來取消了這一分配）。1981年11月，Postel發布了RFC 788——簡單郵件傳輸協議。

SMTP標準的開發與Usenet（一個具有相似之處的一對多通信網路）幾乎是同期的。

SMTP在1980年代初得到了廣泛使用。當時，它是對Unix間複製協議（UUCP）的補充，UUCP更適合用於處理兩台間歇性連接的電腦間的郵件傳輸。相比之下，SMTP更適合發送方和接收方的機器始終連接到網路的環境。兩者都使用存儲轉發機制，是推送技術的例子。儘管Usenet的新聞組仍然通過UUCP在伺服器間傳播，但UUCP作為郵件傳輸工具幾乎已消失，隨之消失的還有UUCP用於消息路由的「嘆號路徑」。

1983年隨4.1cBSD發布的Sendmail，是首批實現SMTP的郵件傳輸代理（MTA）之一。隨著BSD Unix成為網際網路最流行的作業系統，Sendmail也成為最常見的MTA。

原始的SMTP協議僅支持未經身份驗證的7位ASCII文本通信，且不加密，易受中間人攻擊、欺騙和垃圾郵件的侵害，並且需要將二進位數據編碼為可讀文本後才能傳輸。由於缺少適當的身份驗證機制，原始設計中的SMTP伺服器都是開放郵件中繼站。網際網路郵件聯盟（IMC）報告稱，1998年時有55%的郵件伺服器是開放中繼，而到2002年降至不到1%。由於垃圾郵件問題，大多數電子郵件提供商將開放中繼列入阻止名單，使原始SMTP在網際網路普遍使用場景中幾乎不再適用。

### 現代SMTP

1995年11月，RFC 1869定義了擴展簡單郵件傳輸協議（ESMTP），為現有和未來的所有擴展提供了通用結構，旨在彌補原始SMTP協議的功能缺失。ESMTP定義了一套一致、可管理的方式，用於識別ESMTP客戶端和伺服器，並讓伺服器指示其支持的擴展功能。

1998年和1999年，引入了消息提交（RFC 2476）和SMTP-AUTH（RFC 2554），標誌著電子郵件傳輸的新趨勢。最初，SMTP伺服器通常是內部使用的，用於接收來自外部的郵件並轉發組織內的郵件到外部。但隨著時間推移，SMTP伺服器（郵件傳輸代理，MTA）實際上擴展了其角色，成為郵件使用者代理（MUA）的消息提交代理，有些甚至中繼來自外部的郵件（例如，公司高管在出差時通過公司SMTP伺服器發送郵件）。這種變化是由於全球資訊網的快速普及，使得SMTP必須包含特定的中繼規則和使用者身份驗證方法，以防止濫用行為，如未經請求的郵件（垃圾郵件）的中繼。RFC 2476的消息提交工作最初是因為流行的郵件伺服器經常會在嘗試修復郵件問題時重寫郵件，例如為不完整的地址添加域名。雖然此行為在初次提交時有幫助，但在郵件來自他處並被中繼時則存在風險。將郵件清晰地分為提交和中繼被視為一種方法，既能允許和鼓勵提交時重寫，又禁止中繼時重寫。隨著垃圾郵件的增多，這一分離也被視為對組織外發送郵件提供授權和追蹤的方式。這種中繼和提交的分離迅速成為現代電子郵件安全實踐的基礎。

由於SMTP協議最初僅基於ASCII文本，因此對二進位文件或多語言字符處理不佳。多用途網際網路郵件擴展（MIME）標準被開發出來，將二進位文件編碼以便通過SMTP傳輸。在Sendmail之後開發的郵件傳輸代理（MTA）通常被實現為8位「乾淨」模式，使得可以使用「直接發送八位」的策略傳輸任意文本數據（以任意8位ASCII類似字符編碼）。然而，由於不同廠商的字符集映射差異，仍然存在亂碼問題，且電子郵件地址本身仍然只允許使用ASCII字符。如今，8位「乾淨」MTA傾向於支持8BITMIME擴展，使得部分二進位文件幾乎可以像純文本一樣容易傳輸（仍然存在行長和允許的八位值限制，因此大多數非文本數據和一些文本格式仍需要MIME編碼）。2012年，SMTPUTF8擴展被引入，以支持UTF-8文本，允許使用非拉丁字符（如西里爾字母或中文）的國際內容和地址。

許多人對核心SMTP規範作出了貢獻，包括Jon Postel、Eric Allman、Dave Crocker、Ned Freed、Randall Gellens、John Klensin和Keith Moore。

## 郵件處理模型

<image>

電子郵件通過郵件客戶端（郵件使用者代理，MUA）使用SMTP通過TCP埠587提交到郵件伺服器（郵件提交代理，MSA）。大多數郵箱提供商仍允許通過傳統的埠25提交。MSA將郵件傳送給其郵件傳輸代理（MTA）。通常，這兩個代理是同一軟體的實例，在同一台機器上啟動時採用不同選項。可以在單台電腦上完成本地處理，也可以分配到多台機器上；一台機器上的郵件代理進程可以共享文件，但如果在多台機器上進行處理，它們會使用SMTP在彼此之間傳遞消息，每台機器都配置為使用下一台機器作為智能主機。每個進程都是其自身的MTA（SMTP伺服器）。

邊界MTA使用DNS查找接收方域的MX記錄（即電子郵件地址中@符號右側的部分）。MX記錄包含目標MTA的名稱。根據目標主機和其他因素，發送MTA選擇一個接收伺服器並連接以完成郵件交換。

郵件傳輸可以在兩個MTA之間的單次連接中完成，或通過中間系統的一系列跳轉來完成。接收SMTP伺服器可能是最終目的地、中繼（即存儲並轉發消息）或網關（即可能使用SMTP以外的協議轉發消息）。根據RFC 5321第2.1節，每一次跳轉都正式交接了消息的責任，接收伺服器必須要麼傳遞消息，要么正確報告未能傳遞的原因。

一旦最終跳轉接受傳入消息，它將消息交給郵件投遞代理（MDA）以進行本地傳遞。MDA將消息保存在相關的郵箱格式中。和發送一樣，接收過程可以在一台或多台電腦上完成，但在上圖中MDA被描繪為位於郵件交換器附近的一個框。MDA可以直接將消息傳送到存儲中，或通過網路使用SMTP或其他協議（如本地郵件傳輸協議LMTP）轉發，這種協議是為此目的設計的SMTP衍生協議。

一旦郵件傳遞到本地郵件伺服器，郵件便被存儲以供經過身份驗證的郵件客戶端批量檢索。郵件由稱為電子郵件客戶端的終端用戶應用程式使用Internet消息訪問協議（IMAP）或郵局協議（POP）檢索。IMAP用於訪問和管理已存儲的郵件，而POP通常使用傳統的mbox郵件文件格式或專有系統，如Microsoft Exchange/Outlook或Lotus Notes。Webmail客戶端可能使用其中任一方式，但檢索協議通常不是正式標準。

SMTP定義了消息傳輸而非消息內容，因此它定義了郵件信封及其參數（如信封發件人），但不包括消息的頭部（除追蹤資訊外）或正文。STD 10和RFC 5321定義了SMTP（即信封），而STD 11和RFC 5322則定義了消息（頭部和正文），正式稱為網際網路消息格式。

## SMTP通信舉例

在發送方（客戶端）和接收方（伺服器）間建立連接之後，會建立一個合法的SMTP會話，如下例。在下面的例子中，所有客戶端發送的都以「C:」作為前綴，所有伺服器發送的都以「S:」作為前綴。在多數電腦系統上，可以在發送的機器上使用telnet命令來建立連接，比如：

```
telnet www.example.com 25
```

它建立一個從發送的機器到主機www.example.com的SMTP連接。

```
<span style="color: blue">S: 220 smtp.example.com ESMTP Postfix</span>
C: HELO relay.example.com
<span style="color: blue">S: 250 smtp.example.com, I am glad to meet you</span>
C: MAIL FROM:<bob@example.com>
<span style="color: blue">S: 250 Ok</span>
C: RCPT TO:<alice@example.com>
<span style="color: blue">S: 250 Ok</span>
C: RCPT TO:<theboss@example.com>
<span style="color: blue">S: 250 Ok</span>
C: DATA
<span style="color: blue">S: 354 End data with <CR><LF>.<CR><LF></span>
C: From: "Bob Example" <bob@example.com>
C: To: Alice Example <alice@example.com>
C: Cc: theboss@example.com
C: Date: Tue, 15 Jan 2008 16:02:43 -0500
C: Subject: Test message
C: 
C: Hello Alice.
C: This is a test message with 5 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: .
<span style="color: blue">S: 250 Ok: queued as 12345</span>
C: QUIT
<span style="color: blue">S: 221 Bye</span>
{The server closes the connection}
```

雖然是可選的，但幾乎所有的客戶端都會使用EHLO問候消息（而不是上面所示的HELO）來詢問伺服器支持何種SMTP擴展，郵件的文本體（接著DATA）一般是典型的MIME格式。

## SMTP安全和垃圾郵件

最初的SMTP的局限之一，在於它沒有對發送方進行身份驗證的機制。因此，後來定義了SMTP-AUTH擴展。

儘管有了身份認證機制，垃圾郵件仍然是一個主要的問題。但由於龐大的SMTP安裝數量帶來的網路效應，大刀闊斧地修改或完全替代SMTP被認為是不現實的。就是一個替代SMTP的建議方案。

因此，出現了一些同SMTP工作的輔助協議。反垃圾郵件研究小組正在研究一些建議方案，以提供簡單、靈活、輕量級的、可升級的源端認證。最有可能被接受的建議方案是發件人策略框架（SPF）協議。

提供SSL加密的SMTP協定被稱為SMTPS。

## 參見

### 相關 RFC

- RFC 5321 - 簡單郵件傳輸協議，在最近（2008.8）代替了 RFC 2821
- RFC 2821 - 簡單郵件傳輸協議，在最近（2001）代替了 RFC 821，RFC 1869，RFC 974
- RFC 2822 - Internet（比如 e-mail）消息格式，代替了 RFC 822
- RFC 3461 - SMTP的發送狀態通知（DSN）擴展，代替了 RFC 1891