通訊網路/SMTP協議
通常歸因於TCP/IP埠25，SMTP是以下RFCs的精簡結果
- RFC 821 - 簡單郵件傳輸協議（標準）
- RFC 1870 - 用於郵件大小宣告的SMTP服務擴充套件（標準）
- RFC 2821 - 簡單郵件傳輸協議（建議）
- RFC 2822 - 網際網路郵件格式（建議）
- RFC 2920 - 用於命令流水線的SMTP服務擴充套件（標準）
- RFC 3030 - 用於傳輸大型和二進位制MIME郵件的SMTP服務擴充套件（建議）
- RFC 2487 - 用於透過TLS進行安全SMTP的SMTP服務擴充套件（建議？）
- RFC 5321 - 簡單郵件傳輸協議（草案標準 - 廢棄 RFC 2821)
從技術上講，其中一些構成了ESTMP，但我傾向於將它們全部歸類在一起。在我處理電子郵件的地方，似乎沒有太大區別（或者我不知道更好）。
注意：我將在本文中進行一些吐槽。
即使我提供以上RFC的連結，我也沒有花時間去閱讀它們。那是寫MTA的人的工作；）我只是找出錯誤，如果可以的話就修復它們，並盡力阻止任何大量的垃圾郵件到達我的使用者，以人力和計算能力為可能。我在以下方面使用“應該”是基於個人意見和經驗，而不是RFC。雖然它們通常匹配，但我對可接受內容的限制要嚴格得多。
您可能還會注意到我在SMTP對話中的某些點說要拒絕郵件。為什麼不呢？如果對方是郵件伺服器，那麼它完全有能力生成一個退回訊息並將其傳送回編寫電子郵件的人，而且它將採用本地系統管理員知道並可以處理的格式。如果它是一個垃圾郵件引擎或病毒，那麼您的退回訊息本身就會變成垃圾郵件 - 如果您在接受訊息之前拒絕，則不會生成退回訊息。
允許 - 有效的主機名和IP
[x.x.x.x] - 不太可能找到任何郵件伺服器會這樣做，但我仍然接受它。
mail.example.com - 完美。
不允許 - 其他！
x.x.x.x - 缺少方括號
ms_server.example.com - 下劃線是非法字元！（MS$ 將其放在空格的位 - 哎喲）
在HELO時提供的主機名應解析為連線主機的IP地址。反向IP可能與正向IP匹配，但隨著ADSL（和其他BB連結）上小型企業的增加，許多伺服器無法訪問其rdns記錄。
應該是傳送所有退回訊息和任何狀態更新訊息的電子郵件地址。通常是傳送電子郵件的人、處理退回訊息的指令碼或其他你能想到的東西。垃圾郵件傳送者會編造假的電子郵件地址（目前是這樣），所以這是一個殺死大量垃圾郵件的好方法。用回撥來驗證它，或者你的最喜歡的MTA提供什麼。萬歲[Exim]
電子郵件地址應採用“真實姓名”<email@domain.com>的形式
你把郵件發給誰了？
郵件的最終接收者。應該在此時進行驗證，並可能進行字典攻擊防禦。這是一個對標準的輕微修改（據我所知），但已將某些網站的流量減少了至少50%。它還阻止了垃圾郵件傳送者使用您的MTA作為退回垃圾郵件的宿主（許多伺服器接受退回郵件的限制遠遠低於普通郵件）。
有關格式，請參見 MAIL FROM:。
郵件的核心內容。應該過濾掉垃圾郵件和病毒，如果出現問題，就應該在這裡拒絕。拯救世界免受無用的退回訊息的困擾。
格式是標題後跟一個空行，郵件正文，然後是CRLF.CRLF（單獨一行上的句號）。
標題是單行內容 - 標題：內容
如果需要換行，第二行及以後的行的開頭必須是空格。
正文幾乎可以是任何7位ASCII字元。
我相信還有很多內容可以新增到這裡，但是，這就是維基百科的作用！趕快貢獻吧。