シンプルメール転送プロトコル

シンプルメール転送プロトコル
通信プロトコル
略語SMTP
目的電子メール送信プロトコル
導入1981年11月 （1981-11）
OSI層アプリケーション層
ポート465, 587, 25
RFC(s)5321

簡易メール転送プロトコル（SMTP）は、電子メール送信のためのインターネット標準通信プロトコルです。メールサーバーやその他のメッセージ転送エージェントは、メールの送受信にSMTPを使用します。ユーザーレベルの電子メールクライアントは通常、中継用のメールサーバーにメッセージを送信するためにのみSMTPを使用し、 RFC 8314に従ってポート465または587でメールサーバーに送信メールを送信します。メッセージの取得には、IMAP（従来のPOP3に代わるプロトコル）が標準ですが、独自のサーバーでは、 Exchange ActiveSyncなどの独自のプロトコルを実装していることがよくあります。  

SMTPの起源は1980年に遡り、1971年以降ARPANETに実装された概念に基づいて構築されました。その後、何度も更新、修正、拡張されてきました。現在一般的に使用されているプロトコルバージョンは、認証、暗号化、バイナリデータ転送、国際化メールアドレスのための様々な拡張機能を備えた拡張可能な構造を備えています。SMTPサーバーは、通常、ポート番号25（サーバー間）と587（認証済みクライアントからの送信）で伝送制御プロトコルを使用します。暗号化の有無は問いません。送信時は465で暗号化を使用します。

歴史

SMTPの前身

1960年代には、様々な形態の1対1電子メッセージングが使用されていました。ユーザーは、特定のメインフレームコンピュータ向けに開発されたシステムを使用して通信していました。特に米国政府のARPANETにおいて、より多くのコンピュータが相互接続されるにつれて、異なるオペレーティングシステム間でのメッセージ交換を可能にする標準が開発されました。

ARPANET上のメールの起源は1971年に遡ります。メールボックスプロトコルは実装されませんでしたが[ 1 ] 、 RFC 196で議論されています。また、BBNのレイ・トムリンソンがその年に採用したSNDMSGプログラムもARPANET上の2台のコンピュータ間でメッセージを送信することができました。[ 2 ] [ 3 ] [ 4 ]メールプロトコルのさらなる提案は1973年6月にRFC 524で行われましたが[ 5 ] 、実装されませんでした。[ 6 ] 

ARPANET上の「ネットワークメール」にファイル転送プロトコル（FTP）を使用することは、 1973年3月にRFC 469で提案されました。 [ 7 ] RFC 561、RFC 680、RFC 724、そして最終的に1977年11月のRFC 733を経て、FTPメールサーバーを使用した「電子メール」の標準化されたフレームワークが開発されました。[ 8 ] [ 9 ]

SMTPは1970年代に開発されたこれらの標準規格から発展しました。レイ・トムリンソンは、1974年9月に執筆されたINWGプロトコルノート2において、国際ネットワークワーキンググループ（INWG）におけるネットワークメールについて議論しました。 [ 10 ] INWGは1979年に電子メールのプロトコルについて議論し、[ 11 ]ジョン・ポステルはインターネット電子メールに関する初期の研究でこのプロトコルを参照しました。ポステルは1979年にインターネット実験ノート（IEN）シリーズの一環として、初めてインターネットメッセージプロトコル（IMP）を提案しました。 [ 12 ] [ 13 ] [ 14 ]

オリジナルSMTP

1980年、ポステルとスザンヌ・スルイザーはRFC 772を公開し、メールにおけるFTPの代替としてメール転送プロトコル（Mail Transfer Protocol）を提案しました。 1981年5月のRFC 780では、FTPへの言及がすべて削除され、 TCPとUDPにポート57が割り当てられました。[ 15 ]この割り当てはその後IANAによって削除されました。1981年11月、ポステルはRFC 788 「Simple Mail Transfer Protocol」を公開しました。    

SMTP規格は、いくつかの類似点を持つ1対多の通信ネットワークであるUsenetとほぼ同時期に開発されました。 [ 15 ]

SMTPは1980年代初頭に広く使用されるようになりました。当時、SMTPはUnix to Unix Copy Program（UUCP）を補完するものであり、UUCPは断続的に接続しているマシン間の電子メール転送に適していました。一方、SMTPは送信側と受信側のマシンが常にネットワークに接続されている場合に最も効果的に機能します。どちらもストア・アンド・フォワード方式を採用しており、プッシュ技術の例です。Usenetのニュースグループは依然としてサーバー間でUUCPによって伝播されていましたが[ 16 ] 、メール転送手段としてのUUCPは事実上姿を消し[ 17 ]、メッセージルーティングヘッダーとして使用されていた「バンパス」も姿を消しました[ 18 ] 。

Sendmailは1983年に4.1cBSDとともにリリースされ、SMTPを実装した最初のメール転送エージェント（MTA）の1つでした。[ 19 ]時が経ち、BSD Unixがインターネット上で最も人気のあるオペレーティングシステムになったため、Sendmailは最も一般的なメール転送エージェントになりました。[ 20 ]

オリジナルのSMTPプロトコルは、認証なしの暗号化されていない7ビットASCIIテキスト通信のみをサポートしていたため、単純な中間者攻撃、スプーフィング、スパム攻撃を受けやすく、バイナリデータは送信前に判読可能なテキストにエンコードする必要がありました。適切な認証メカニズムがなかったため、設計上、すべてのSMTPサーバーはオープンメールリレーでした。インターネットメールコンソーシアム（IMC）の報告によると、1998年にはメールサーバーの55%がオープンリレーでしたが、[ 21 ] 2002年には1%未満でした。 [ 22 ]スパムの懸念から、ほとんどのメールプロバイダーはオープンリレーをブロックリストに登録しており、[ 23 ]オリジナルのSMTPはインターネットでの一般的な使用には基本的に非実用的でした。

現代のSMTP

1995年11月、RFC 1869はExtended Simple Mail Transfer Protocol（ESMTP）を定義しました。これは、元のSMTPに欠けている機能を追加することを目的とした、既存および将来のすべての拡張機能の一般的な構造を確立しました。ESMTPは、ESMTPクライアントとサーバーを識別し、サーバーがサポートされている拡張機能を示すための、一貫性があり管理しやすい手段を定義します。  

メッセージ送信 ( RFC 2476 ) とSMTP-AUTH ( RFC 2554 ) はそれぞれ 1998 年と 1999 年に導入され、どちらも電子メール配信の新しい傾向を記述しています。当初、 SMTP サーバーは通常組織の内部にあり、組織の外部から組織のメールを受信し、組織から外部にメッセージを中継していました。しかし時が経つにつれ、 SMTP サーバー (メール転送エージェント) は実際にはその役割を拡張し、メール ユーザー エージェントのメッセージ送信エージェントになり、そのいくつかは組織の外部からのメールを中継するようになりました。 (たとえば、会社の重役が出張中に会社の SMTP サーバーを使用してメールを送信したい場合など)。この問題は、ワールド ワイド ウェブの急速な拡張と普及の結果であり、迷惑メール (スパム)の中継などの不正使用を防ぐために、メールの中継とユーザーの認証に関する特定のルールと方法を SMTP に含める必要が生じました。メッセージ送信 ( RFC 2476 ) に関する作業は、もともと、一般的なメール サーバーが、たとえば非修飾アドレスにドメイン名を追加するなど、メール内の問題を修正するためにメールを書き換えることが多かったために開始されました。この動作は、修正対象のメッセージが最初の送信である場合は役立ちますが、メッセージが他の場所で発信され、リレーされている場合は危険で有害です。メールを送信とリレーに明確に分けることは、書き換えによる送信を許可および奨励しながら、書き換えによるリレーを禁止する方法だと考えられていました。スパムが蔓延するにつれて、これは組織から送信されるメールの承認と追跡可能性を提供する方法でもあると見なされました。リレーと送信を分離することは、すぐに現代の電子メール セキュリティ対策の基礎となりました。    

このプロトコルは当初純粋にASCIIテキストベースだったため、バイナリファイルや多くの英語以外の言語の文字を適切に処理できませんでした。SMTP経由で転送するためにバイナリファイルをエンコードするために、Multipurpose Internet Mail Extensions ( MIME ) などの標準規格が開発されました。Sendmail以降に開発されたメール転送エージェント (MTA)も8ビットクリーンで実装される傾向があり、「just send eight」戦略を使用して、任意のテキストデータ（任意の8ビットASCII風文字エンコード）をSMTP経由で送信することができました。メールアドレス自体は依然としてASCIIのみに対応していましたが、ベンダー間で異なる文字セットマッピングのため、文字化けは依然として問題でした。今日の8ビットクリーンMTAは8BITMIME拡張をサポートする傾向があり、一部のバイナリファイルをプレーンテキストとほぼ同じくらい簡単に送信できます（行の長さと許容オクテット値の制限は依然として適用されるため、ほとんどの非テキストデータと一部のテキスト形式ではMIMEエンコードが必要です）。 2012 年に、UTF-8テキストをサポートする拡張機能が作成され、キリル文字や中国語などのラテン文字以外の文字による国際的なコンテンツやアドレスが可能になりました。 SMTPUTF8

SMTP コア仕様には、Jon Postel、Eric Allman、 Dave Crocker 、Ned Freed、 Randall Gellens 、John Klensin、Keith Mooreなど、多くの人が貢献しました。

メール処理モデル

青い矢印は SMTP バリエーションの実装を示しています。

電子メールは、メール クライアント (メール ユーザー エージェント、MUA)によって、 TCPポート 465 または 587上の SMTP を使用してメール サーバー (メール送信エージェント、MSA) に送信されます。ほとんどのメールボックス プロバイダーは、依然として従来のポート 25 での送信を許可しています。MSA は、メールをメール転送エージェント(MTA) に配信します。多くの場合、これら 2 つのエージェントは、同じマシン上で異なるオプションで起動された同じソフトウェアのインスタンスです。ローカル処理は、1 台のマシンで実行することも、複数のマシンに分割することもできます。1 台のマシン上のメール エージェント プロセスはファイルを共有できますが、処理が複数のマシン上で行われる場合は、各マシンが次のマシンをスマート ホストとして使用するように構成された SMTP を使用して、マシン間でメッセージを転送します。各プロセスは、それ自体が MTA (SMTP サーバー) です。

境界MTAはDNSを使用して、受信者のドメイン（メールアドレスの右側の部分）のMX（メールエクスチェンジャ）レコードを検索します。MXレコードには、送信先MTAの名前が含まれています。送信元MTAは、送信先ホストなどの要素に基づいて受信者サーバーを選択し、接続してメール交換を完了します。 @

メッセージ転送は、2つのMTA間の単一の接続で行われる場合もあれば、中間システムを経由する一連のホップで行われる場合もあります。受信側のSMTPサーバーは、最終的な宛先、中間の「リレー」（つまり、メッセージを保存して転送する）、「ゲートウェイ」（つまり、SMTP以外のプロトコルを使用してメッセージを転送する）となる場合もあります。RFC 5321セクション2.1によれば、各ホップはメッセージに対する責任の正式な引き継ぎであり、受信側サーバーはメッセージを配信するか、配信に失敗したことを適切に報告する必要があります。  

最終ホップで受信メッセージを受け取ると、ローカル配信のためにメール配信エージェント（MDA）に渡されます。MDAはメッセージを適切なメールボックス形式で保存します。送信と同様に、受信も1台または複数のコンピュータで行うことができますが、上の図ではMDAはメールエクスチェンジャーボックスの近くにある1つのボックスとして描かれています。MDAはメッセージをストレージに直接配信することも、 SMTPまたはこの目的のためにSMTPから派生したローカルメール転送プロトコル（LMTP）などの他のプロトコルを使用してネットワーク経由で転送することもできます。

ローカルメールサーバーに配信されたメールは、認証済みメールクライアント（MUA）による一括取得のために保存されます。メールは、メールクライアントと呼ばれるエンドユーザーアプリケーションによって、メールへのアクセスを容易にし、保存されたメールを管理するプロトコルであるインターネットメッセージアクセスプロトコル（IMAP）、または、通常は従来のmboxメールファイル形式、あるいはMicrosoft Exchange/Outlook、 Lotus Notes / Dominoなどの独自システムを使用するPost Office Protocol （POP）を使用して取得されます。Webメールクライアントはどちらの方法も使用できますが、取得プロトコルは正式な標準ではないことがよくあります。

SMTPはメッセージ転送を定義するものであり、メッセージの内容を定義するものではありません。つまり、メールエンベロープと、エンベロープ送信者などのパラメータは定義しますが、ヘッダー（トレース情報を除く）やメッセージ本文自体は定義しません。STD 10とRFC 5321はSMTP（エンベロープ）を定義し、STD 11とRFC 5322はメッセージ（ヘッダーと本文）を定義します。これらは正式にはインターネットメッセージフォーマットと呼ばれます。   

プロトコルの概要

SMTP は、接続指向のテキストベースのプロトコルであり、メールの送信者は、信頼性の高い順序付けられたデータ ストリーム チャネル (通常はTransmission Control Protocol (TCP) 接続) を介してコマンド文字列を発行し、必要なデータを提供して、メールの受信者と通信します。SMTPセッションは、SMTPクライアント(開始エージェント、送信者、またはトランスミッタ)によって発行されたコマンドと、それに対応する SMTPサーバー(リスニング エージェント、または受信者) からの応答で構成されます。これにより、セッションが開始され、セッション パラメータが交換されます。セッションには、0 個以上の SMTP トランザクションが含まれる場合があります。SMTPトランザクションは、次の 3 つのコマンド/応答シーケンスで構成されます。

  1. MAILコマンドは、返信先アドレスを確立します。返信先アドレスは、リターンパス、[ 24 ]リバースパス、[ 25 ]バウンスアドレス、mfrom、またはエンベロープ送信者とも呼ばれます。
  2. RCPTコマンドは、メッセージの受信者を確立するためのものです。このコマンドは、受信者ごとに1回ずつ、複数回発行できます。これらのアドレスもエンベロープの一部となります。
  3. DATAはメッセージテキストの開始を知らせるものです。これは、エンベロープではなく、メッセージの内容です。DATAは、メッセージヘッダーとメッセージ本体で構成され、空行で区切られています。DATAは実際にはコマンドの集合体であり、サーバーは2回応答します。1回目はDATAコマンド自体に応答し、テキストの受信準備が完了したことを通知します。2回目はデータ終了シーケンスの後に応答し、メッセージ全体を受け入れるか拒否するかを決定します。

DATA に対する中間応答に加えて、各サーバーからの応答は肯定応答（2xx 応答コード）または否定応答のいずれかになります。否定応答は永続的応答（5xx コード）または一時的応答（4xx コード）です。拒否応答は永続的な失敗であり、クライアントはメッセージを受信したサーバーにバウンスメッセージを送信する必要があります。ドロップ応答は肯定応答の後、メッセージを配信せずに破棄するものです。

送信元ホストであるSMTPクライアントは、エンドユーザーのメールクライアント（機能的にはメールユーザーエージェント（MUA）として識別されます）またはリレーサーバーのメール転送エージェント（MTA）のいずれかです。MTAとは、メールを中継するために、該当セッションにおいてSMTPクライアントとして機能するSMTPサーバーです。完全な機能を備えたSMTPサーバーは、一時的な障害によって送信が再試行されるため、メッセージのキューを保持します。

MUA は、設定から送信メールのSMTP サーバーを認識します。リレーサーバーは通常、各受信者のドメイン名のMX (Mail eXchange) DNSリソースレコードを参照して、接続先のサーバーを決定します。MX レコードが見つからない場合、準拠したリレーサーバー (すべてではありません) は代わりにA レコードを参照します。リレーサーバーは、スマートホストを使用するように設定することもできます。リレーサーバーは、SMTP の場合は「ウェルノウンポート」であるポート25、MSA への接続の場合はポート 465 または 587 で、サーバーへのTCP接続を開始します。MTA と MSA の主な違いは、MSA への接続にはSMTP 認証が必要であることです。

SMTPとメール取得

SMTPは配信プロトコルとしてのみ機能します。通常の使用では、メールは到着すると宛先メールサーバー（または次ホップメールサーバー）に「プッシュ」されます。メールは、宛先のユーザーではなく、宛先サーバーに基づいてルーティングされます。Post Office Protocol（POP）やInternet Message Access Protocol （IMAP）などの他のプロトコルは、個々のユーザーがメッセージを取得したりメールボックスを管理したりするために特別に設計されています。断続的に接続しているメールサーバーがリモートサーバーから要求に応じてメッセージを取得できるように、 SMTPにはリモートサーバー上でメールキュー処理を開始する機能があります（下記の「リモートメッセージキューの開始」を参照）。POPとIMAPは、断続的に接続しているマシンによるメール中継には適さないプロトコルです。これらのプロトコルは、メール中継の正常な動作に不可欠な情報（「メールエンベロープ」）が削除された最終配信後に動作するように設計されています。

リモートメッセージキューの開始

リモートメッセージキュー開始（RMS）は、リモートホストが対応するコマンドを送信することで、サーバー上のメールキューの処理を開始し、自ホスト宛てのメッセージを受信できるようにするものです。元のコマンドは安全ではないと判断されたため、 RFC 1985TURNで拡張され、ドメインネームシステム情報に基づく認証方式を用いてより安全に動作するコマンドが追加されました。[ 26 ] ETRN

送信メールSMTPサーバー

メールクライアントは、最初のSMTPサーバーのIPアドレスを知る必要があり、これは設定の一部として指定する必要があります（通常はDNS名で指定します）。このサーバーは、ユーザーに代わって送信メッセージを配信します。

送信メールサーバーのアクセス制限

サーバー管理者は、どのクライアントがサーバーを利用できるかをある程度制御する必要があります。これにより、スパムなどの不正利用に対処できるようになります。一般的に使用されている解決策は以下の2つです。

場所によるアクセス制限

このシステムでは、インターネットサービスプロバイダ（ISP）のSMTPサーバーは、ISPネットワーク外のユーザーからのアクセスを許可しません。より正確には、サーバーはISPから提供されたIPアドレスを持つユーザーのみにアクセスを許可します。これは、ユーザーが同じISPを使用してインターネットに接続していることを要求するのと同じです。モバイルユーザーは、通常利用しているISPとは異なるネットワーク上にいることが多く、設定されたSMTPサーバーにアクセスできなくなったためにメールの送信に失敗することがあります。

このシステムにはいくつかのバリエーションがあります。例えば、組織のSMTPサーバーは、同一ネットワーク上のユーザーのみにサービスを提供する場合があり、ファイアウォールによってインターネット上のユーザーからのアクセスをブロックすることで、この制限を強制しています。また、サーバーがクライアントのIPアドレスの範囲チェックを行う場合もあります。これらの方法は、組織内でのみ使用する送信メール用のSMTPサーバーを提供する企業や大学などの機関で一般的に使用されていました。しかし、現在ではこれらの機関のほとんどが、以下に説明するクライアント認証方式を使用しています。

ユーザーがモバイル端末を利用し、異なるISPからインターネットに接続する場合、このような利用制限は煩雑であり、設定された送信メールSMTPサーバーアドレスを変更することは現実的ではありません。メールクライアントの設定情報を変更せずに使用できることが非常に望ましいです。

クライアント認証

現代のSMTPサーバーは、前述のように場所によるアクセス制限ではなく、アクセスを許可する前にクライアントの認証情報による認証を要求するのが一般的です。このより柔軟なシステムはモバイルユーザーにとって使いやすく、送信SMTPサーバーを固定的に選択できます。SMTP認証（ SMTP AUTHと略されることが多い）は、認証メカニズムを用いてログインするためのSMTPの拡張です。

ポート

メール サーバー間の通信では、通常、SMTP に指定された 標準TCPポート 25 が使用されます。

ただし、メールクライアントは通常これを使用せず、代わりに特定の「送信」ポートを使用します。メールサービスは通常、次のいずれかのポートを持つクライアントからのメール送信を受け入れます。

ポート 2525 などは一部のプロバイダーによって使用される可能性がありますが、公式にはサポートされていません。

多くのインターネットサービスプロバイダーは現在、顧客からのポート25番への送信トラフィックをすべてブロックしています。これは主にスパム対策として[ 27 ]、また、ポート25番を開放したままにしておくことで発生するコストの増加を補うためでもあり、おそらく、ポート25番を開放する必要がある少数の顧客からより高い料金を請求することになるのでしょう。

SMTPトランスポートの例

同じメールドメイン（example.com ）にある2つのメールボックス（ aliceとtheboss ）にSMTP経由でメッセージを送信する典型的な例を、次のセッション交換に示します。（この例では、会話部分にはそれぞれサーバーとクライアントを表すS:とC:がプレフィックスとして付けられていますが、これらのラベルは交換の一部ではありません。）

メッセージ送信者（SMTPクライアント）がメッセージ受信者（SMTPサーバー）との信頼性の高い通信チャネルを確立すると、サーバーからの挨拶メッセージでセッションが開始されます。挨拶メッセージには通常、サーバーの完全修飾ドメイン名（FQDN）（この場合はsmtp.example.com ）が含まれます。クライアントは、コマンドパラメータに自身のFQDN（またはFQDNがない場合はアドレスリテラル）を指定したコマンドで応答することで、ダイアログを開始HELOします。[ 28 ]

S: 220 smtp.example.com ESMTP Postfix C: HELO relay.example.org S: 250 こんにちは、relay.example.org、お会いできて嬉しいですC: MAIL FROM:<bob@example.org> S: 250 Ok C: RCPT TO:<alice@example.com> S: 250 Ok C: RCPT TO:<theboss@example.com> S: 250 Ok C: DATA S: 354 End data with <CR><LF>.<CR><LF> C: C: C: C : C : C:こんにちは、Alice。 C:これは、5 つのヘッダー フィールドと 4 行のメッセージ本文を含むテスト メッセージです。 C:あなたの友人、 C: Bob C: . S: 250 Ok: 12345 としてキューに登録C: QUIT S: 221 Bye {サーバーが接続を閉じます}From:"BobExample"<bob@example.org>To:"AliceExample"<alice@example.com>Cc:theboss@example.comDate:Tue, 15 Jan 2008 16:02:43 -0500Subject:Testmessage

クライアントは、コマンドでメッセージの送信元メールアドレスを受信者に通知します。これは、メッセージが配信できない場合のMAIL FROM返信先またはバウンス先でTo:もあります。この例では、メールメッセージは同じSMTPサーバー上の2つのメールボックスに送信されます。1つは、ヘッダーフィールドとCc:ヘッダーフィールドにリストされている受信者ごとに1つです。対応するSMTPコマンドはですRCPT TO。コマンドの受信と実行が成功すると、サーバーは結果コードと応答メッセージ（例250 Ok：）で確認応答します。

メールメッセージの本文の送信はDATAコマンドによって開始され、その後、本文は行ごとに逐語的に送信され、データ終了シーケンスで終了します。このシーケンスは、改行文字 ( <CR><LF>)、1つのピリオド( .)、そしてもう1つの改行文字 ( <CR><LF>) で構成されます。メッセージ本文には、テキストの一部としてピリオドのみを含む行が含まれる場合があるため、クライアントは行の先頭がピリオドで始まるたびに2つのピリオドを送信します。これに応じて、サーバーは行の先頭の2つのピリオドのシーケンスを1つのピリオドに置き換えます。このようなエスケープ方法はドットスタッフィングと呼ばれます。

例示されているように、データ終了に対するサーバーの肯定応答は、サーバーがメッセージ配信の責任を引き受けたことを意味します。この時点で通信障害（例えば停電など）が発生すると、メッセージは二重に配信される可能性があります。送信者はその250 Ok応答を受信するまで、メッセージが配信されなかったと想定しなければなりません。一方、受信者がメッセージを受け入れると決定した後は、メッセージが配信されたと想定しなければなりません。したがって、この期間中、両方のエージェントは配信を試みるメッセージのアクティブなコピーを保持しています。[ 29 ]まさにこの段階で通信障害が発生する確率は、サーバーがメッセージ本文に対して実行するフィルタリングの量（多くの場合、スパム対策目的）に正比例します。タイムアウトの制限は10分に設定されています。[ 30 ]

このQUITコマンドはセッションを終了します。メールの受信者が別の場所にいる場合、クライアントはQUIT現在の宛先がキューに登録された後、後続の受信者のために適切なSMTPサーバーに接続します。クライアントがコマンドHELOとコマンドで送信した情報は、受信サーバーによってメッセージに追加のヘッダーフィールドとして追加されます（サンプルコードには表示されていません）。それぞれ、およびヘッダーフィールドMAIL FROMが追加されます。 ReceivedReturn-Path

一部のクライアントは、メッセージが受け入れられた後（250 Ok: queued as 12345）に接続を閉じるように実装されているため、最後の2行が省略されることがあります。この場合、サーバー側で応答を送信しようとする際にエラーが発生します221 Bye。

SMTP拡張機能

拡張機能検出メカニズム

EHLOクライアントは、以下の例に示すように、元の ではなく、 という挨拶を使用して、サーバーがサポートしているオプションを学習します。サーバーが という挨拶をサポートしていない場合にのみ、HELOクライアントは にフォールバックします。[ 31 ]HELOEHLO

最近のクライアントは、ESMTP拡張キーワードを使用してSIZE、サーバーに受け入れ可能なメッセージの最大サイズを問い合わせる場合があります。古いクライアントとサーバーは、ネットワークリソース（分単位で課金されるネットワークリンクへの接続時間など）を消費した後に拒否される、過剰なサイズのメッセージを転送しようとする場合があります。[ 32 ]

ユーザーは、ESMTPサーバーが受け入れる最大サイズを事前に手動で決定できます。クライアントはHELOコマンドをコマンドに置き換えますEHLO。 

S: 220 smtp2.example.com ESMTP Postfix C: EHLO bob.example.org S: 250-smtp2.example.com Hello bob.example.org [192.0.2.201] S: 250-SIZE 14680064 S: 250-PIPELINING S: 250 HELP

したがって、smtp2.example.com は、14,680,064オクテット(8 ビット バイト) 以下の固定最大メッセージ サイズを受け入れることができると宣言します。

最も単純なケースでは、ESMTPサーバーはSIZE受信直後に最大値を宣言します。ただし、 RFC 1870EHLOによれば、応答における拡張の数値パラメータはオプションです。クライアントは代わりに、コマンドを発行する際に、転送するメッセージのサイズの推定値を数値で含めることができます。これにより、サーバーは大きすぎるメッセージの受信を拒否できます。  SIZEEHLOMAIL FROM

バイナリデータ転送

オリジナルのSMTPは単一のASCIIテキスト本文のみをサポートしていたため、バイナリデータは転送前にメッセージ本文にテキストとしてエンコードし、受信者がデコードする必要がありました。通常は、 uuencodeやBinHexなどのバイナリからテキストへのエンコードが使用されていました。

8BITMIMEコマンドはこの問題に対処するために開発されました。1994年にRFC 1652 [ 33 ]として標準化されました。このコマンドは、7ビットASCII文字セット外のオクテットを含む電子メールメッセージを、通常はBase64でエンコードされたMIMEコンテンツパーツとしてエンコードすることにより、透過的に交換することを可能にします。  

オンデマンドメールリレー

オンデマンド メール リレー( ODMR ) は、 RFC 2645で標準化された SMTP 拡張機能であり、断続的に接続される SMTP サーバーが、接続時にキューに入れられた電子メールを受信できるようにします。  

国際化拡張

オリジナルのSMTPはASCII文字のみで構成されるメールアドレスをサポートしていたため、ネイティブスクリプトがラテン語ベースではない、あるいはASCII文字セットに含まれない分音記号を使用するユーザーにとっては不便でした。この制限は、アドレス名にUTF-8を使用できるようにする拡張機能によって緩和されました。RFC 5336では実験的なコマンド[ 32 ]が導入され、後にコマンドを導入したRFC 6531に置き換えられました。これらの拡張機能により、メールアドレスにおけるマルチバイト文字や非ASCII文字（分音記号付き文字やギリシャ語、中国語などの他の言語文字など）のサポートが提供されます。[ 34 ] UTF8SMTP SMTPUTF8

現在のサポートは限られていますが、ラテン文字 (ASCII) が外国語である大規模なユーザー ベースを持つ中国などの国では、 RFC 6531および関連 RFCが広く採用されることに強い関心があります。  

拡張機能

SMTPと同様に、ESMTPはインターネットメールの転送に使用されるプロトコルです。サーバー間トランスポートプロトコルとしてだけでなく、（制限された動作を強制しながら）メール送信プロトコルとしても使用されます。

ESMTPクライアントの主な識別機能は、 (Hello、RFC 821EHLO標準)ではなく、(Extended HELLO)コマンドで送信を開始することです。サーバーは、設定に応じて、成功（コード250）、失敗（コード550）、またはエラー（コード500、501、502、504、または421）で応答します。ESMTPサーバーは、ドメインとサポートされている拡張機能を示すキーワードのリストを含む複数行の応答でコード250 OKを返します。RFC 821準拠のサーバーはエラーコード500を返し、ESMTPクライアントはまたは のいずれかを試すことができます。 HELO HELOQUIT

各サービス拡張は、後続のRFCで承認された形式で定義され、Internet Assigned Numbers Authority (IANA) に登録されます。最初の定義は、RFC 821のオプションサービスである、、SEND（SOML送信またはメール）、SAML（送信とメール）、、、EXPNおよびHELPでした。追加のSMTP動詞の形式は、およびのTURN新しいパラメータに対して設定され、になりました。 MAILRCPT

現在使用されている比較的一般的なキーワード (すべてがコマンドに対応しているわけではありません) は次のとおりです。

ESMTP 形式はRFC 2821 (RFC 821 の後継) で再定義され、2008 年にRFC 5321の最新の定義に更新されました。サーバーでのコマンドのサポートが必須となり、必要なフォールバックが指定されました。   EHLOHELO

非標準で未登録のサービス拡張は二国間協定により使用可能であり、これらのサービスはEHLO「X」で始まるメッセージ キーワードで示され、追加のパラメータや動詞も同様にマークされます。

SMTPコマンドは大文字と小文字を区別しません。ここでは強調のためだけに大文字で表記しています。特定の大文字表記方法を要求するSMTPサーバーは、標準に違反しています。[ 28 ]

8ビットマイム

少なくとも次のサーバーは 8BITMIME 拡張機能をアドバタイズします。

次のサーバーは、8BITMIME をアドバタイズするように構成できますが、8BITMIME 以外のリレーに接続するときに 8 ビット データから 7 ビットへの変換は実行されません。

  • Eximとqmailは、 RFCで要求されているように、8ビットデータを非8BITMIMEピアに中継しようとするときに、8ビットメッセージを7ビットに変換しません。[ 38 ]これは実際には問題を引き起こしません。なぜなら、事実上すべての現代のメールリレーは8ビットクリーンだからです。[ 39 ]
  • Microsoft Exchange Server 2003はデフォルトで8BITMIMEをアドバタイズしますが、8BITMIME以外のピアにリレーするとバウンスが発生します。これはRFC 6152で許可されています。[ 40 ] 

SMTP認証

SMTP-AUTH拡張はアクセス制御メカニズムを提供します。これは、メール送信プロセス中にクライアントがメールサーバーに効果的にログインするための認証ステップで構成されます。SMTP-AUTHをサポートするサーバーは通常、クライアントにこの拡張の使用を要求するように設定でき、送信者の真の身元が確実に確認されます。SMTP-AUTH拡張はRFC 4954で定義されています。  

SMTP-AUTHは、正当なユーザーによるメール中継を許可しながら、スパマーなどの権限のないユーザーによる中継を拒否するために使用できます。SMTPエンベロープの送信者やRFC 2822の「From:」ヘッダーの信頼性を必ずしも保証するものではありません。例えば、送信者が別の人物になりすますスプーフィングは、サーバー側でメッセージの送信元アドレスを、認証されたユーザーが許可されているアドレスに限定するように設定されていない限り、SMTP-AUTHを使用しても依然として可能です。  

SMTP-AUTH拡張機能は、メールを中継する際に、あるメールサーバーが別のメールサーバーに送信者が認証済みであることを示すことも可能にします。一般的に、これには受信側サーバーが送信側サーバーを信頼する必要があるため、SMTP-AUTHのこの側面はインターネットではほとんど使用されません。[ 41 ]

SMTPUTF8

サポートされるサーバーは次のとおりです:

セキュリティ拡張機能

メールの配信はプレーンテキスト接続と暗号化接続の両方で行うことができますが、通信相手が安全なチャネルを使用できるかどうかを事前に知らない場合があります。

STARTTLS または「Opportunistic TLS」

STARTTLS拡張機能により、サポートするSMTPサーバーは、接続するクライアントにTLS暗号化通信をサポートしていることを通知し、クライアントがSTARTTLSコマンドを送信することで接続をアップグレードする機会を提供します。この拡張機能をサポートするサーバーは、TLS暗号化セッションへのアップグレードは接続するクライアントがこのオプションを使用するかどうかに依存するため、拡張機能の実装自体からセキュリティ上の利点を得ることはありません。そのため、「日和見TLS」という用語が使用されています。

STARTTLSは受動的な観測攻撃に対してのみ有効である。なぜならSTARTTLSネゴシエーションはプレーンテキストで行われ、能動的な攻撃者はSTARTTLSコマンドを簡単に削除できるためである。このタイプの中間者攻撃はSTRIPTLSと呼ばれることもあり、一方の端から送信された暗号化ネゴシエーション情報はもう一方の端に届かない。このシナリオでは、双方とも無効または予期しない応答を、相手側がSTARTTLSを適切にサポートしていないことの兆候と受け止め、デフォルトで従来のプレーンテキストのメール転送になってしまう。[ 50 ] STARTTLSは他のRFCでIMAPとPOP3向けにも定義されているが、これらのプロトコルの目的は異なることに注意されたい。SMTPはメッセージ転送エージェント間の通信に使用され、IMAPとPOP3はエンドクライアントとメッセージ転送エージェント向けである。

2014年、電子フロンティア財団（EFF）は「STARTTLS Everywhere」プロジェクトを開始しました。これは、「HTTPS Everywhere」リストと同様に、証明書利用者が事前の通信なしに安全な通信をサポートする他の利用者を発見できるものでした。このプロジェクトは2021年4月29日に申請の受付を停止し、EFFはピアのTLSサポートに関する情報の発見にDANEとMTA-STSへの切り替えを推奨しました。[ 51 ]

RFC  8314では、プレーン テキストは正式に廃止され、メールの送信とアクセスには常に TLS を使用し、暗黙的な TLS を備えたポートを追加することが推奨されています。

SMTP の DANE

RFC  7672は、 DNSレコードにメールサーバーの暗号化能力を宣言する機能を導入しました。DNSSECを利用することで、メールサーバー運営者はTLS証明書のハッシュを公開することができ、暗号化されていない通信の可能性を軽減できます。[ 52 ]

マイクロソフトは、2024年末までにExchange Onlineの顧客に対して完全なSMTP DANEサポートを有効にする予定です。[ 53 ]

SMTP MTA 厳格なトランスポートセキュリティ

2018年に新たに制定されたRFC 8461「SMTP MTA Strict Transport Security（MTA-STS）」は、メールサーバーがサーバー上の特定のファイルと特定のDNS TXTレコード内のセキュアチャネルを利用できることを宣言するためのプロトコルを定義することで、アクティブな攻撃者による攻撃の問題に対処することを目的としています。証明書利用者は、このようなレコードの存在を定期的に確認し、レコードに指定された期間キャッシュし、レコードの有効期限が切れるまでセキュアでないチャネルで通信することはありません。[ 50 ] MTA-STSレコードはメールサーバー間のSMTPトラフィックにのみ適用されますが、ユーザークライアントとメールサーバー間の通信は、組織的または技術的なポリシーと組み合わせたSMTP/MSA、IMAP、POP3、またはHTTPSによるトランスポート層セキュリティによって保護されます。本質的に、MTA-STSはこのようなポリシーを第三者に拡張するための手段です。  

2019年4月にGoogleメールはMTA-STSのサポートを発表しました。[ 54 ]

SMTP TLS レポート

メッセージを安全に配信するために設計されたプロトコルは、設定ミスや意図的な干渉によって機能不全に陥る可能性があり、その結果、メッセージが配信されなかったり、暗号化されていない、あるいは認証されていないチャネルを経由して配信されたりすることがあります。RFC 8460 「 SMTP TLS レポート」は、潜在的な障害に関する統計情報や具体的な情報を受信者ドメインと共有するためのレポートメカニズムとフォーマットについて規定しています。受信者ドメインは、この情報を使用して、潜在的な攻撃を検知し、意図しない設定ミスを診断することができます。  

2019年4月にGoogleメールはSMTP TLSレポートのサポートを発表しました。[ 54 ]

なりすましとスパム

SMTP の元の設計には、送信者を認証したり、サーバーが送信者に代わって送信する権限を持っているかどうかを確認する機能がなかったため、電子メールのなりすましが可能になり、電子メールのスパムやフィッシングによく使用されていました。

SMTPを大幅に変更したり、完全に置き換えたりする提案が時折なされます。その一例がInternet Mail 2000ですが、従来のSMTPの膨大なインストールベースによるネットワーク効果を考えると、Internet Mail 2000も他の提案も大きな進展を遂げていません。

代わりに、メールサーバーは現在、RFC 5322、[ 55 ] [ 56 ] DomainKeys Identified Mail、Sender Policy Framework、DMARC、DNSBL、グレーリストなどの標準の厳格な施行など、さまざまな技術を使用して疑わしいメールを拒否または隔離しています。[ 57 ] 

実装

参照

注記

  1. ^電子メールの歴史アーカイブ2017年12月2日Wayback Machine 、Tom Van Vleck：「このプロトコルが実際に実装されたかどうかは明らかではありません」
  2. ^最初のネットワークメール、レイ・トムリンソン、BBN
  3. ^ダン・マーフィーによる「最初の電子メールコンピュータ」の写真、 PDP-10
  4. ^ Dan MurphyのTENEXとTOPS-20論文は2007年11月18日にWayback Machineにアーカイブされています。
  5. ^ RFC 524 – 提案されたメールプロトコル 
  6. ^ Crocker, David H. (1977年12月). 「MSパーソナルメッセージシステムのフレームワークと機能」(PDF) . The RAND Corporation . 2022年5月13日時点のオリジナルよりアーカイブ(PDF) . 2022年4月17日閲覧。
  7. ^ RFC 469 – ネットワークメール会議概要 
  8. ^ RFC 733、1977年11月21日、ARPAネットワークテキストメッセージのフォーマットの標準
  9. ^ 「電子メールの歴史：コラボレーション、イノベーション、そしてシステムの誕生」ワシントン・ポスト、2023年5月20日。ISSN 0190-8286。2024年7月7日閲覧。 
  10. ^ McKenzie, Alexander (2011). 「INWGとインターネットの構想：目撃証言」. IEEE Annals of the History of Computing . 33 (1): 66– 71. Bibcode : 2011IAHC...33a..66M . doi : 10.1109/MAHC.2011.9 . ISSN 1934-1547 . S2CID 206443072 .  
  11. ^ Barber, D.、および J. Laws、「EIN の基本メール スキーム」、INWG 192、1979 年 2 月。
  12. ^ IEN 85 .
  13. ^ IEN 113 .
  14. ^ 「インターネット実験ノートインデックス」 . www.rfc-editor.org . 2024年7月7日閲覧。
  15. ^ a b Postel, J. (1982年8月). Simple Mail Transfer Protocol (レポート). RFC Editor. doi : 10.17487/rfc0821 .
  16. ^ "Tldp.org" . 2007年8月17日時点のオリジナルよりアーカイブ。2007年8月25日閲覧。
  17. ^ Barber, Stan O. (2000年12月19日). 「draft-barber-uucp-project-conclusion-05 – UUCPマッピング・プロジェクトの結論」 . 2007年10月13日時点のオリジナルよりアーカイブ。 2007年8月25日閲覧。
  18. ^送信者書き換えに関する記事には、初期の SMTP の歴史とRFC 1123以前のソース ルーティングに関する技術的な背景情報が含まれています。 
  19. ^ Eric Allman (1983), Sendmail – An Internetwork Mail Router (PDF) , BSD UNIX documentation set, Berkeley: University of California, archived (PDF) from the original on May 20, 2013 , retrieved June 29, 2012
  20. ^ Craig Partridge (2008), The Technical Development of Internet Email (PDF) , IEEE Annals of the History of Computing, vol. 30, IEEE Computer Society, pp.  3– 29, Bibcode : 2008IAHC...30b...3P , doi : 10.1109/MAHC.2008.32 , S2CID 206442868 , 2011年5月12日時点のオリジナル(PDF)からアーカイブ 
  21. ^ Paul Hoffman (1998年2月1日). 「SMTPにおけるリレーの許可：概要」 . Internet Mail Consortium . 2016年3月5日時点のオリジナルよりアーカイブ。 2010年5月30日閲覧。
  22. ^ Paul Hoffman (2002年8月). 「SMTPにおけるリレーの許可：一連の調査」 . Internet Mail Consortium . 2007年1月18日時点のオリジナルよりアーカイブ。2010年5月30日閲覧。
  23. ^ 「Unixにおけるオープンメールリレーとは何ですか？ - ナレッジベース」 2007年6月17日。 2007年6月17日時点のオリジナルよりアーカイブ。2021年3月15日閲覧。
  24. ^「MAIL、RCPT、DATA動詞」 2014年2月22日アーカイブ、 Wayback Machine、[DJ Bernstein]
  25. ^ RFC 5321セクション7.2 
  26. ^ Systems、Message。「Message Systems、API駆動型の新機能を搭載したMomentumの最新バージョンを発表」 www.prnewswire.com （プレスリリース）。2020年7月19日時点のオリジナルよりアーカイブ。 2020年7月19日閲覧。
  27. ^ Cara Garretson (2005). 「ISPがスパム対策に協力」 . PC World . 2015年8月28日時点のオリジナルよりアーカイブ。2016年1月18日閲覧。Yahoo !、America Online、EarthLink、Microsoftが昨年設立したAnti-Spam Technical Allianceは先月、ポート25のフィルタリングを含むスパム対策推奨事項のリストを発表しました。
  28. ^ a b J. Klensin (2008年10月). Simple Mail Transfer Protocol . IETFネットワークワーキンググループ. doi : 10.17487/RFC5321 . RFC 5321 .ドラフト標準。RFC 7504 により更新。RFC 2821を廃止。RFC 1123を更新。   
  29. ^ RFC 1047 
  30. ^ Klensin, John C. (2008年10月). 「DATA Termination: 10 Minutes.」 . Simple Mail Transfer Protocol . sec. 4.5.3.2.6. doi : 10.17487/RFC5321 . RFC 5321. 2010年6月7日閲覧.
  31. ^ John Klensin; Ned Freed; Marshall T. Rose; Einar A. Stefferud; Dave Crocker (1995年11月). SMTPサービス拡張. IETF . doi : 10.17487/RFC1869 . RFC 1869 .
  32. ^ a b「MAILパラメータ」。IANA。2020年2月14日。2019年5月28日時点のオリジナルよりアーカイブ。2019年5月28日閲覧。
  33. ^これは2011年に当時の新しいSTD 71に対応するRFC 6152によって廃止されました。 
  34. ^ Jiankang Yao (2014年12月19日). 「中国のメールアドレス」 . EAI (メーリングリスト). IETF . 2015年10月2日時点のオリジナルよりアーカイブ。2016年5月24日閲覧。
  35. ^ 「SMTPサービス拡張パラメータ」 IANA。2019年5月28日時点のオリジナルよりアーカイブ。2013年11月5日閲覧。
  36. ^ James Server - ChangeLog 2020年2月20日アーカイブ、 Wayback Machine . James.apache.org. 2013年7月17日閲覧。
  37. ^ gmail-smtp-in.l.google.com ポート 25 の EHLO に応答して宣伝された 8BITMIME サービス、2011 年 11 月 23 日に確認
  38. ^ Qmailのバグとウィッシュリスト。Home.pages.de。2013年7月17日閲覧。
  39. ^ 8BITMIME拡張機能 。 2011年6月7日アーカイブ。Wayback Machine。Cr.yp.to。2013年7月17日閲覧。
  40. ^ 「8ビットMIMEトランスポートサービス拡張」 . 8ビットMIMEトランスポート用SMTPサービス拡張. 2011年3月. sec. 3. doi : 10.17487/RFC6152 . RFC 6152 .
  41. ^ヘイゼル、フィリップ(2007). Exim SMTPメールサーバー（第2版）. ケンブリッジ: UITケンブリッジ. p. 418. ISBN 978-0-9544529-7-5。{{cite book}}:チェック|isbn=値: チェックサム (ヘルプ)
  42. ^「Postfix SMTPUTF8サポートはデフォルトで有効になっています」 2020年8月7日アーカイブ、 Wayback Machine、2015年2月8日、postfix.org
  43. ^ 「Message Systems、API駆動型の新機能を搭載したMomentumの最新バージョンを発表」（プレスリリース）。2020年9月15日時点のオリジナルよりアーカイブ。 2020年9月17日閲覧。
  44. ^ 「バージョン6.2改訂履歴」 . CommuniGate.com . 2020年10月29日時点のオリジナルよりアーカイブ。2020年9月17日閲覧。
  45. ^ Sam Varshavchik (2018年9月18日). 「Courierパッケージの新リリース」 . courier-announce (メーリングリスト). 2021年8月17日時点のオリジナルよりアーカイブ。 2020年9月17日閲覧。
  46. ^ 「Halon MTA changelog」 . GitHub . 2021年11月9日. 2020年9月18日時点のオリジナルよりアーカイブ。2020年9月17日閲覧。v4.0 : 新しいSMTPUTF8サポート新しいバージョンに更新されました
  47. ^ “MS-OXSMTP: Simple Mail Transfer Protocol (SMTP) Extensions” . 2018年7月24日. 2021年8月16日時点のオリジナルよりアーカイブ。 2020年9月17日閲覧。
  48. ^ 「TLDにおけるEAIの準備状況」(PDF) 2019年2月12日. 2021年1月24日時点のオリジナルよりアーカイブ(PDF) 2020年9月17日閲覧。
  49. ^ 「Communications Messaging Serverリリースノート」。ora ​​cle.com。2017年10月。2020年11月24日時点のオリジナルよりアーカイブ。 2020年9月17日閲覧。
  50. ^ a b「MTA Strict Transport Security (MTA-STS) の紹介 | Hardenize Blog」www.hardenize.com。2019年4月25日時点のオリジナルよりアーカイブ。2019年4月25日閲覧。
  51. ^ 「STARTTLS Everywhere」 EFF。2019年8月9日時点のオリジナルよりアーカイブ。2021年12月4日閲覧。
  52. ^ v-mathavale (2023年7月21日). 「SMTP DNSベース認証（DANE）による電子メール通信のセキュリティ確保の仕組み」 . learn.microsoft.com . 2024年3月5日閲覧。
  53. ^ 「Exchange Online メールフローに DNSSEC を使用した受信 SMTP DANE を実装する」 techcommunity.microsoft.com . 2024 年3 月 5 日閲覧。
  54. ^ a b Cimpanu, Catalin. 「GmailがMTA-STSとTLSレポートをサポートする初の大手メールプロバイダーに」 ZDNet . 2019年4月29日時点のオリジナルよりアーカイブ。 2019年4月25日閲覧。
  55. ^ 「RFC 5322に準拠していないメッセージ」。2023年1月17日時点のオリジナルよりアーカイブ。2021年1月20日閲覧。
  56. ^ 「メッセージを配信できませんでした。メッセージがRFC 5322に準拠していることを確認してください」。2021年1月28日時点のオリジナルよりアーカイブ。2021年1月20日閲覧。
  57. ^ 「なぜMicrosoftアカウントに送信されたメールはポリシー上の理由で拒否されるのか？」 2021年2月14日時点のオリジナルよりアーカイブ。2021年1月20日閲覧。

参考文献

さらに読む

  • RFC  1123 – インターネットホストの要件 - アプリケーションとサポート (STD 3)
  • RFC  1870 – メッセージサイズ宣言のための SMTP サービス拡張 (廃止: RFC 1653 ) 
  • RFC  2505 – SMTP MTA のスパム対策推奨事項 (BCP 30)
  • RFC  2821 – シンプルメール転送プロトコル
  • RFC  2920 – コマンドパイプラインのための SMTP サービス拡張 (STD 60)
  • RFC  3030 – 大容量およびバイナリMIMEメッセージの送信のためのSMTPサービス拡張
  • RFC  3207 – セキュアなSMTP over Transport Layer SecurityのためのSMTPサービス拡張（RFC 2487は廃止） 
  • RFC  3461 – 配信状態通知のための SMTP サービス拡張 ( RFC 1891は廃止) 
  • RFC  3463 – SMTP の拡張ステータスコード ( RFC 1893は廃止され、 RFC 5248によって更新されました)  
  • RFC  3464 – 配信状態通知のための拡張メッセージ形式（RFC 1894は廃止） 
  • RFC  3798 – メッセージ処理通知（RFC 3461 の更新） 
  • RFC  3834 – 電子メールへの自動応答に関する推奨事項
  • RFC  3974 – IPv4/v6 混在環境における SMTP 運用経験
  • RFC  4952 – 国際化電子メールの概要とフレームワーク（ RFC 5336により更新） 
  • RFC  4954 – 認証のための SMTP サービス拡張 ( RFC 2554を廃止、RFC 3463を更新、 RFC 5248で更新)   
  • RFC  5068 – 電子メール送信操作：アクセスとアカウンタビリティの要件（BCP 134）
  • RFC  5248 – SMTP拡張メールシステムステータスコードのレジストリ（BCP 138）（RFC 3463の更新） 
  • RFC  5321 – シンプルメール転送プロトコル（RFC 821（別名STD 10）、RFC 974、RFC 1869、RFC 2821を廃止、RFC 1123を更新）     
  • RFC  5322 – インターネット メッセージ フォーマット (廃止されたRFC 822別名 STD 11、およびRFC 2822 )  
  • RFC  5504 – 電子メールアドレスの国際化のためのダウングレードメカニズム
  • RFC  6409 – メールのメッセージ送信（STD 72）（RFC 4409、RFC 2476は廃止）  
  • RFC  6522 – メールシステム管理メッセージの報告のためのマルチパート/レポートコンテンツタイプ（RFC 3462、そしてRFC 1892を廃止）  
  • RFC  6531 – 国際化電子メールアドレスの SMTP 拡張 ( RFC 2821、RFC 2822、RFC 4952、およびRFC 5336 の更新)    
  • RFC  8314 – クリアテキストは廃止される：電子メールの送信とアクセスにおけるトランスポート層セキュリティ（TLS）の使用
「 https://en.wikipedia.org/w/index.php?title=Simple_Mail_Transfer_Protocol&oldid=1335080419」から取得