簡易メール転送プロトコル

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

SMTP の起源は 1980 年に始まり、1971 年以来ARPANETに実装された概念に基づいて構築されました。SMTPは、何度も更新、変更、拡張されてきました。今日一般的に使用されているプロトコル バージョンは、認証、暗号化、バイナリ データ転送、国際化された電子メール アドレスなど、さまざまな拡張機能を備えた拡張可能な構造になっています。SMTP サーバーは、通常、ポート番号25 (サーバー間) および 587 (認証されたクライアントからの送信用)で、暗号化の有無にかかわらず、 伝送制御プロトコルを使用します。

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

ARPANET 上のメールの起源は 1971 年に遡ります。メールボックス プロトコルは実装されませんでしたが^{[1] 、} RFC  196で議論されています。また、 SNDMSGプログラムは、BBNのRay Tomlinson がその年に採用し、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を通じて、ARPANET上のFTPメールサーバーを使用した「電子メール」の標準化されたフレームワークが開発されました。^{[8] [9]}

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

1980 年、Postel と Suzanne Sluizer はRFC  772 を公開し、メールに FTP を使用する代わりにメール転送プロトコルを使用することを提案しました。1981年 5 月のRFC 780 では、FTP への参照がすべて削除され、 TCPとUDP にポート 57 が割り当てられました( ^{[引用が必要]) 。この割り当てはその後}IANAによって削除されました。1981 年 11 月、Postel はRFC 788「Simple Mail Transfer Protocol」を公開しました 。

SMTP 標準は、いくつかの類似点を持つ 1 対多の通信ネットワークであるUsenetとほぼ同時期に開発されました。 ^{[引用が必要]}

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

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

オリジナルのSMTPプロトコルは、認証されていない暗号化されていない7ビットASCIIテキスト通信のみをサポートしていたため、単純な中間者攻撃、スプーフィング、スパムの影響を受けやすく、バイナリデータは送信前に読み取り可能なテキストにエンコードする必要がありました。適切な認証メカニズムがないため、設計上、すべてのSMTPサーバーはオープンメールリレーでした。インターネットメールコンソーシアム（IMC）は、1998年にはメールサーバーの55％がオープンリレーであったと報告しましたが、^[20] 2002年には1％未満でした。^[21]スパムの懸念から、ほとんどの電子メールプロバイダーはオープンリレーをブロックリストに登録しており、^[22]オリジナルの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 サーバーを使用してメールを送信したい場合など)。この問題は、World Wide Webの急速な拡大と普及の結果であり、迷惑メール (スパム)の中継などの悪用を防ぐために、SMTP にメールの中継とユーザーの認証に関する特定のルールと方法を組み込む必要があったことを意味しました。メッセージ送信 ( RFC  2476) の作業は、もともと、一般的なメール サーバーが、たとえば、非修飾アドレスにドメイン名を追加するなど、メール内の問題を修正するためにメールを書き換えることが多かったために開始されました。この動作は、修正対象のメッセージが最初の送信である場合は役立ちますが、メッセージが他の場所で発信され、リレーされている場合は危険で有害です。メールを送信とリレーに明確に分離することは、書き換え送信を許可および奨励しながら、書き換えリレーを禁止する方法と見なされていました。スパムが蔓延するにつれて、組織から送信されるメールの承認と追跡可能性を提供する方法と見なされるようになりました。リレーと送信のこの分離は、すぐに現代の電子メール セキュリティ プラクティスの基礎となりました。

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

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

電子メールは、メール クライアント (メール ユーザー エージェント、MUA)によって、 TCPポート 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コマンドは、返信先アドレスを確立します。これは、リターンパス、^[23]リバースパス、^[24] バウンスアドレス、mfrom、またはエンベロープ送信者とも呼ばれます。
2. RCPTコマンドは、メッセージの受信者を確立します。このコマンドは、受信者ごとに 1 回ずつ、複数回発行できます。これらのアドレスもエンベロープの一部です。
3. 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 への接続の場合はポート 587 で、サーバーへのTCP接続を開始します。MTA と MSA の主な違いは、MSA への接続にはSMTP 認証が必要であることです。

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

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

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

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

• これまで、多くのシステムではクライアントの場所によって使用制限が課され、サーバー管理者が管理する IP アドレスを持つクライアントのみの使用が許可されていました。その他のクライアント IP アドレスからの使用は許可されません。
• 最近の SMTP サーバーは通常、アクセスを許可する前に資格情報によるクライアントの認証を要求する代替システムを提供します。

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

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

ユーザーが移動中であり、インターネットへの接続に異なる ISP を使用する場合、このような使用制限は煩わしく、構成された送信メール SMTP サーバー アドレスを変更することは非現実的です。変更する必要のないメール クライアント構成情報を使用できることが非常に望まれます。

最近の SMTP サーバーでは、通常、前述のように場所によってアクセスを制限するのではなく、アクセスを許可する前にクライアントの認証を資格情報によって行う必要があります。このより柔軟なシステムはモバイル ユーザーにとって使いやすく、設定された送信 SMTP サーバーを固定的に選択できます。SMTP認証(SMTP AUTH と略されることが多い) は、認証メカニズムを使用してログインするための SMTP の拡張機能です。

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

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

• 587 (提出)、 RFC  6409 (旧RFC  2476)で正式に規定されている
• 465 このポートは、RFC 2487 以降、 RFC 8314 が発行されるまで非推奨でした 。

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

現在、多くのインターネットサービスプロバイダーは、顧客からのポート25の送信トラフィックをすべてブロックしています。これは主にスパム対策として行われていますが、^[26]また、ポートを開いたままにしておくとコストが高くなるため、ポートを開くことを必要とする少数の顧客からより高い料金を請求するなどの対策も取られています。

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

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

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: C:こんにちは、Alice。
 C:これは、5 つのヘッダー フィールドと 4 行のメッセージ本文を含むテスト メッセージです。
 C:あなたの友人、
 C: Bob
 C: .
 S: 250 Ok: 12345 としてキューに登録C: QUIT
 S: 221 Bye {サーバーは接続を閉じます}From: "Bob Example" <bob@example.org>
 To: "Alice Example" <alice@example.com>
 Cc: theboss@example.com
 Date: Tue, 15 Jan 2008 16:02:43 -0500
 Subject: Test message

 
 

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

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

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

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

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

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

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

ユーザーは、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を受信した直後に最大値を宣言しますEHLO。ただし、 RFC  1870 によれば、応答内の拡張に対する数値パラメータはオプションです。代わりに、クライアントはコマンドを発行するときに、転送するメッセージのサイズの数値推定値を含めることができます。これにより、サーバーは大きすぎるメッセージの受信を拒否できます。 SIZEEHLOMAIL FROM

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

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

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

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

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

SMTP と同様に、ESMTP はインターネット メールの転送に使用されるプロトコルです。サーバー間転送プロトコルとしても、(制限された動作を強制して) メール送信プロトコルとしても使用されます。

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

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

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

• 8BITMIME – 8ビットデータ伝送、RFC  6152
• ATRN –オンデマンドメールリレーTURNの認証、RFC  2645
• AUTH – 認証済み SMTP、RFC  4954
• CHUNKING – チャンキング、RFC  3030
• DSN – 配信ステータス通知、RFC  3461（可変エンベロープリターンパスを参照）
• ETRN – リモートメッセージキュー開始コマンドの拡張バージョンTURN、RFC  1985
• HELP – 役立つ情報を提供する、RFC  821
• PIPELINING – コマンドパイプライン、RFC  2920
• SIZE – メッセージサイズ宣言、RFC  1870
• STARTTLS –トランスポート層セキュリティ、RFC  3207 (2002)
• SMTPUTF8 –メールボックス名とヘッダーフィールドでUTF-8エンコードを許可する(RFC  6531)
• UTF8SMTP –メールボックス名とヘッダーフィールドでUTF-8エンコードを許可する、RFC  5336（非推奨^[34]）

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

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

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

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

• Apache James（2.3.0a1以降）^[36]
• シタデル（7.30以降）
• 宅配メールサーバー
• Gメール^[37]
• アイスワープ
• IIS SMTP サービス
• Kerio コネクト
• ロータスドミノ
• Microsoft Exchange Server (Exchange Server 2000 以降)
• ノベルグループワイズ
• オープンSMTPD
• Oracle コミュニケーション メッセージング サーバー
• ポストフィックス
• Sendmail (6.57 以降)

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

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

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

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

SMTP-AUTH 拡張機能により、メールを中継する際に、あるメール サーバーが別のメール サーバーに送信者が認証されていることを示すこともできます。通常、これには受信側サーバーが送信側サーバーを信頼する必要があるため、SMTP-AUTH のこの側面はインターネットではほとんど使用されません。^{[引用が必要]}

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

• Postfix（バージョン3.0以降）^[40]
• Momentum（バージョン4.1 ^[41]および3.6.5以降）
• Sendmail (8.17.1 での実験的サポート)
• Exim (4.86 リリース時点では実験的でしたが、4.96 ではかなり成熟しました)
• CommuniGate Proバージョン6.2.2以降^[42]
• Courier-MTAバージョン1.0 ^[43]
• ハロンバージョン4.0 ^[44]
• Microsoft Exchange Serverプロトコルリビジョン14.0以降^[45]
• ハラカと他のサーバー。^[46]
• Oracle Communications Messaging Serverリリース8.0.2以降。^[47]

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

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

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

2014年に電子フロンティア財団は「STARTTLS Everywhere」プロジェクトを開始しました。これは「HTTPS Everywhere」リストと同様に、事前の通信なしに安全な通信をサポートする他のリライアブルパーティを発見できるものでした。このプロジェクトは2021年4月29日に提出の受け付けを停止し、EFFはピアのTLSサポートに関する情報を発見するためにDANEとMTA-STSに切り替えることを推奨しました。^[49]

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

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

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

2018 年の新しいRFC  8461「SMTP MTA Strict Transport Security (MTA-STS)」は、メール サーバーがサーバー上の特定のファイルと特定のDNS TXT レコードで安全なチャネルを使用する能力を宣言するためのプロトコルを定義することにより、アクティブな敵対者の問題に対処することを目的としています。依存当事者は、そのようなレコードの存在を定期的に確認し、レコードで指定された期間キャッシュし、レコードの有効期限が切れるまで安全でないチャネルを介して通信することはありません。^[48] MTA-STS レコードはメール サーバー間の SMTP トラフィックにのみ適用されますが、ユーザーのクライアントとメール サーバー間の通信は、組織または技術ポリシーと組み合わせたSMTP/MSA、IMAP、POP3、またはHTTPSによるトランスポート層セキュリティによって保護されることに注意してください。基本的に、MTA-STS はそのようなポリシーを第三者に拡張する手段です。

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

メッセージを安全に配信するように設計されたプロトコルは、誤った設定や意図的なアクティブな干渉により失敗し、メッセージが配信されなかったり、暗号化されていないチャネルや認証されていないチャネルで配信されたりすることがあります。RFC 8460「 SMTP  TLS レポート」では、統計情報や潜在的な障害に関する特定の情報を受信者ドメインと共有するためのレポート メカニズムと形式について説明しています。受信者ドメインは、この情報を使用して、潜在的な攻撃を検出し、意図しない誤った設定を診断することができます。

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

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

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

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

• バウンスアドレス
• CRAM-MD5 (ESMTPA の SASL メカニズム) RFC  2195
• メール
  • メールの暗号化
• DKIM
• アイデンティティ
• メールサーバーソフトウェアの一覧
• SMTP サーバーの戻りコードのリスト
• POP before SMTP / SMTP after POP
• インターネット メッセージ アクセス プロトコルバイナリ コンテンツ拡張RFC  3516
• 送信者ポリシーフレームワーク(SPF)
• 簡易認証およびセキュリティ層(SASL) RFC  4422
• SMTP認証
• 可変エンベロープリターンパス
• SMTP サポートに関する情報については、電子メール クライアントの比較を参照してください。

• ヒューズ、L (1998)。インターネット電子メール: プロトコル、標準、実装。Artech House Publishers。ISBN 978-0-89006-939-4。
• Hunt, C (2003). sendmail Cookbook . O'Reilly Media. ISBN 978-0-596-00471-2。
• Johnson, K (2000)。インターネット電子メールプロトコル: 開発者ガイド。Addison -Wesley Professional。ISBN 978-0-201-43288-6。
• Loshin, P (1999)。Eメールの基本標準: 実用的な RFC とプロトコル。John Wiley & Sons。ISBN 978-0-471-34597-8。
• Rhoton, J (1999)。インターネットメールプログラマガイド: SMTP、POP、IMAP、 LDAP。Elsevier。ISBN 978-1-55558-212-8。
• Wood, D (1999)。インターネットメールのプログラミング。O'Reilly。ISBN 978-1-56592-479-6。

• 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 のための 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 – メール システム管理メッセージのレポート用の Multipart/Report コンテンツ タイプ ( RFC  3462 およびRFC  1892 は廃止)
• RFC  6531 – 国際化電子メール アドレスの SMTP 拡張 ( RFC  2821、RFC  2822、RFC  4952、およびRFC  5336 の更新)
• RFC  8314 – クリアテキストは廃止: 電子メールの送信とアクセスにトランスポート層セキュリティ (TLS) を使用する

• RFC  1869 SMTP サービス拡張
• RFC  5321 シンプルメール転送プロトコル
• RFC  4954 認証のための SMTP サービス拡張 ( RFC  2554 は廃止)
• RFC  3848 SMTP およびLMTP送信タイプ登録 (ESMTPA を使用)
• RFC  6409 メールのメッセージ送信 ( RFC  4409 は廃止され、RFC  2476 は廃止されます)