Loading article…
シンプルメール転送プロトコル（SMTP）は、電子メール送信のためのインターネット標準通信プロトコルです。メールサーバーやその他のメッセージ転送エージェントは、SMTPを使用してメールメッセージを送受信します。ユーザーレベルのメールクライアントは通常、リレーのためにメールサーバーにメッセージを送信する場合にのみSMTPを使用し、 RFC 8314に従って、送信メールをポート465または587でメールサーバーに送信します。メッセージの受信には、IMAPとPOPが広く使用されていますが、独自のサーバーでは、 Exchange ActiveSyncなどの独自のプロトコルを実装している場合もよくあります。
SMTPの起源は1980年に遡り、 1971年以来ARPANETで実装されてきた概念に基づいています。その後、何度も更新、修正、拡張が行われてきました。現在一般的に使用されているプロトコルバージョンは、認証、暗号化、バイナリデータ転送、国際化電子メールアドレスなど、さまざまな拡張機能を備えた拡張可能な構造になっています。SMTPサーバーは通常、ポート番号25（サーバー間）と587（認証済みクライアントからの送信用）で送信制御プロトコルを使用し、暗号化の有無は問いません。また、送信には暗号化付きのポート465も使用します。
1960年代には、さまざまな形式の1対1の電子メッセージングが利用されていた。ユーザーは、特定のメインフレームコンピュータ向けに開発されたシステムを使用して通信していた。コンピュータの相互接続が進むにつれ、特に米国政府のARPANETにおいて、異なるオペレーティングシステム間でのメッセージ交換を可能にするための標準規格が開発された。
ARPANET 上のメールは 1971 年に遡ります。実装されなかった Mail Box Protocol [ 1 ]ですが、 RFC 196で議論されています。また、BBNのRay Tomlinsonがその年に ARPANET 上の 2 台のコンピュータ間でメッセージを送信するために改良したSNDMSGプログラムもあります。 [ 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 年代に開発されたこれらの標準から発展しました。Ray Tomlinson は、1974 年 9 月に書かれたINWG プロトコル ノート 2で、国際ネットワーク ワーキング グループ内でのネットワーク メールについて議論しました。 [ 10 ] INWG は 1979 年に電子メールのプロトコルについて議論し、[ 11 ]これはJon Postelがインターネット メールに関する初期の研究で参照しました。Postel は、インターネット実験ノート(IEN) シリーズの一部として、1979 年にインターネット メッセージ プロトコルを初めて提案しました。[ 12 ] [ 13 ] [ 14 ]
1980年、ポステルとスザンヌ・スライザーは、メール転送プロトコル（MPTP）をFTPの代替として提案したRFC 772を公開した。1981年5月のRFC 780では、FTPへの言及がすべて削除され、 TCPとUDPにポート57が割り当てられた[ 15 ]。この割り当てはその後IANAによって削除された。1981年11月、ポステルはRFC 788「Simple Mail Transfer Protocol」を公開した。
SMTP規格は、類似点のある一対多の通信ネットワークであるUsenetとほぼ同時期に開発されました。 [ 15 ]
SMTP は 1980 年代初頭に広く使われるようになりました。当時、SMTP は断続的に接続されるマシン間の電子メール転送の処理に適したUnix to Unix Copy Program (UUCP) の補完的な役割を果たしていました。一方、SMTP は送信マシンと受信マシンの両方が常にネットワークに接続されている場合に最も効果的に機能します。どちらもストアアンドフォワード方式を使用しており、プッシュ技術の例です。Usenet のニュースグループはサーバー間で UUCP を使用して伝播されていましたが[ 16 ] 、メール転送手段としての UUCP は、メッセージルーティング ヘッダーとして使用されていた「バン パス」とともに事実上消滅しました[ 17 ]。[ 18 ]
1983年に4.1cBSDとともにリリースされたSendmailは、 SMTPを実装した最初のメール転送エージェント（MTA ）の1つでした。 [ 19 ]時が経つにつれ、BSD Unixがインターネット上で最も人気のあるオペレーティングシステムになるにつれて、Sendmailは最も一般的なメール転送エージェントになりました。[ 20 ]
オリジナルの SMTP プロトコルは、認証も暗号化もされていない 7 ビット ASCII テキスト通信のみをサポートしており、簡単な中間者攻撃、なりすまし、スパム送信に弱く、バイナリ データは送信前に読み取り可能なテキストにエンコードする必要がありました。適切な認証メカニズムがなかったため、設計上、すべての SMTP サーバーはオープン メール リレーでした。インターネット メール コンソーシアム(IMC) は、1998 年にメール サーバーの 55% がオープン リレーであったと報告しましたが[ 21 ]、2002 年に 1% 未満になりました[ 22 ]。スパムの懸念から、ほとんどのメール プロバイダはオープン リレーをブロックリストに追加しており[ 23 ]、オリジナルの SMTP はインターネットでの一般的な使用には実質的に実用的ではありませんでした。
1995年11月、RFC 1869は拡張シンプルメール転送プロトコル（ESMTP）を定義しました。これは、元のSMTPに欠けていた機能を追加することを目的とした、既存および将来のすべての拡張機能のための一般的な構造を確立するものでした。ESMTPは、ESMTPクライアントとサーバーを識別し、サーバーがサポートする拡張機能を示すための、一貫性があり管理しやすい手段を定義しています。
メッセージ送信（RFC 2476）とSMTP-AUTH（RFC 2554）は、1998 年と 1999 年に導入され、どちらも電子メール配信の新しい傾向を説明しています。当初、SMTP サーバーは通常組織の内部にあり、組織宛ての外部からのメールを受信し、組織から外部へメッセージを中継していました。しかし、時が経つにつれて、SMTP サーバー（メール転送エージェント）は、実際にはその役割を拡大し、メール ユーザー エージェントのメッセージ送信エージェントとなり、その一部は組織の外部からのメールを中継するようになりました（たとえば、会社の役員が出張中に社内 SMTP サーバーを使用してメールを送信したい場合など）。この問題は、ワールド ワイド ウェブの急速な拡大と普及の結果であり、SMTP には、迷惑メール（スパム）の中継などの悪用を防ぐために、メールの中継とユーザーの認証に関する特定のルールと方法を含める必要がありました。メッセージ送信（RFC 2476）に関する取り組みは、もともと、一般的なメールサーバーが、例えば修飾されていないアドレスにドメイン名を追加するなど、メール内の問題を修正しようとしてメールを書き換えることが頻繁にあったことから始まりました。この動作は、修正対象のメッセージが初回送信の場合は有効ですが、メッセージが別の場所から送信され、中継されている場合は危険で有害です。メールを送信と中継に明確に分離することは、送信の書き換えを許可・促進する一方で、中継の書き換えを禁止する方法として考えられました。スパムが蔓延するにつれて、組織から送信されるメールの認証と追跡可能性を提供する方法としても考えられました。この中継と送信の分離は、すぐに現代のメールセキュリティ対策の基盤となりました。
このプロトコルは当初、純粋にASCIIテキストベースであったため、バイナリファイルや多くの非英語言語の文字をうまく処理できませんでした。そのため、SMTP経由でバイナリファイルを転送するために、MIME （Multipurpose Internet Mail Extensions）などの標準が開発されました。Sendmail以降に開発されたメール転送エージェント（ MTA ）も8ビットクリーンで実装される傾向があり、代替の「just send eight」戦略を使用して、任意のテキストデータ（任意の8ビットASCIIライクな文字エンコーディング）をSMTP経由で送信できるようになりました。ベンダー間で文字セットのマッピングが異なるため、文字化けは依然として問題でしたが、電子メールアドレス自体は依然としてASCIIのみを許可していました。今日の8ビットクリーンMTAは8BITMIME拡張機能をサポートする傾向があり、一部のバイナリファイルをプレーンテキストとほぼ同じくらい簡単に送信できます（行の長さと許可されるオクテット値の制限は依然として適用されるため、ほとんどの非テキストデータと一部のテキスト形式にはMIMEエンコーディングが必要です）。 2012年にUTF-8SMTPUTF8テキストをサポートするために拡張機能が作成され、キリル文字や中国語などのラテン文字以外の文字を使用した国際的なコンテンツや住所が可能になった。
SMTPのコア仕様には、ジョン・ポステル、エリック・オールマン、デイブ・クロッカー、ネッド・フリード、ランドール・ゲレンズ、ジョン・クレンシン、キース・ムーアなど、多くの人々が貢献しました。
メールは、メールクライアント（メールユーザーエージェント、MUA）によって、 TCPポート465または587のSMTPを使用してメールサーバー（メール送信エージェント、MSA）に送信されます。ほとんどのメールボックスプロバイダは、従来どおりポート25での送信も引き続き許可しています。MSAは、メールをメール転送エージェント（MTA）に配信します。多くの場合、これら2つのエージェントは、同じマシン上で異なるオプションで起動された同じソフトウェアのインスタンスです。ローカル処理は、単一のマシンで行うことも、複数のマシンに分割して行うことも可能です。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メールファイル形式を使用するポストオフィスプロトコル（POP）もしくはMicrosoft Exchange/OutlookやLotus Notes / Dominoなどの独自システムを使用して、メールクライアントと呼ばれるエンドユーザーアプリケーションによって取得されます。Webメールクライアントはどちらの方法も使用できますが、取得プロトコルは正式な標準規格ではない場合が多いです。
SMTPはメッセージの転送方法を定義するものであり、メッセージの内容を定義するものではありません。したがって、メールのエンベロープとそのパラメータ（エンベロープの送信者など）を定義しますが、ヘッダー（トレース情報を除く）やメッセージ本文自体は定義しません。STD 10とRFC 5321はSMTP（エンベロープ）を定義し、STD 11とRFC 5322はメッセージ（ヘッダーと本文）を定義します。メッセージは正式にはインターネットメッセージフォーマットと呼ばれます。
SMTPは、接続指向型のテキストベースのプロトコルであり、メール送信者は、信頼性の高い順序付きデータストリームチャネル（通常はTCP（ Transmission Control Protocol）接続）を介してコマンド文字列を発行し、必要なデータを提供することで、メール受信者と通信します。SMTPセッションは、 SMTPクライアント（開始エージェント、送信者、または送信機）によって生成されたコマンドと、SMTPサーバー（リスニングエージェント、または受信者）からの対応する応答で構成され、セッションが開かれ、セッションパラメータが交換されます。セッションには、0個以上のSMTPトランザクションが含まれる場合があります。SMTPトランザクションは、3つのコマンド/応答シーケンスで構成されます。
DATAに対する中間応答の他に、各サーバーの応答は肯定応答（2xx応答コード）または否定応答のいずれかになります。否定応答は永続的なもの（5xxコード）または一時的なもの（4xxコード）のいずれかです。拒否は永続的な失敗であり、クライアントはそれを受信したサーバーにバウンスメッセージを送信する必要があります。ドロップは肯定応答の後にメッセージが配信されずに破棄されることを意味します。
開始ホストである SMTP クライアントは、エンドユーザーの電子メール クライアント（機能的にはメール ユーザー エージェント(MUA)として識別される）か、リレー サーバーのメール転送エージェント(MTA)（関連するセッションで SMTP クライアントとして動作する SMTP サーバー）のいずれかであり、メールをリレーするために使用されます。完全な機能を備えた SMTP サーバーは、一時的な障害が発生したメッセージ送信を再試行するためのメッセージ キューを保持します。
MUA は、設定から送信メールSMTP サーバーを認識します。リレー サーバーは通常、各受信者のドメイン名のMX (Mail eXchange) DNSリソース レコードを検索して、接続するサーバーを決定します。MX レコードが見つからない場合、準拠リレー サーバー (すべてではありません) は代わりにA レコードを検索します。リレー サーバーは、スマート ホストを使用するように構成することもできます。リレー サーバーは、SMTP の場合は「よく知られたポート」であるポート25、MSA に接続する場合はポート 465 または 587でサーバーへのTCP接続を開始します。MTA と MSA の主な違いは、MSA に接続するにはSMTP 認証が必要であることです。
SMTPは配信プロトコルに過ぎません。通常の使用では、メールは到着すると宛先メールサーバー（またはネクストホップメールサーバー）に「プッシュ」されます。メールは宛先サーバーに基づいてルーティングされ、宛先の個々のユーザーに基づいてルーティングされるわけではありません。Post Office Protocol（POP）やInternet Message Access Protocol（IMAP）などの他のプロトコルは、個々のユーザーがメッセージを取得してメールボックスを管理するために特別に設計されています。断続的に接続されるメールサーバーがリモートサーバーからオンデマンドでメッセージを取得できるようにするために、SMTPにはリモートサーバーでメールキュー処理を開始する機能があります（下記の「リモートメッセージキューの開始」を参照）。POPとIMAPは、断続的に接続されるマシンによるメールのリレーには適していません。これらは、メールリレーの正しい動作に不可欠な情報（「メールエンベロープ」）が削除された最終配信後に動作するように設計されています。
リモートメッセージキュー開始機能を使用すると、リモートホストは対応するコマンドを送信することで、サーバー上のメールキューの処理を開始し、自分宛てのメッセージを受信できるようになります。元のTURNコマンドは安全でないと判断され、RFC 1985でドメインネームシステム情報に基づく認証方法を使用してより安全に動作するコマンドが追加されました。[ 26 ] ETRN
メールクライアントは、最初の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 ]また、ポートを開放しておくとコストが高くなるためでもあります。
同じメールドメイン（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 Hello relay.example.org, I am glad to meet you 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: 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: . S: 250 OK: queued as 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:ヘッダーフィールドにリストされている各受信者用です。対応する SMTP コマンドは ですRCPT TO。コマンドの受信と実行が成功すると、サーバーは結果コードと応答メッセージ(例: 250 Ok) でそれを確認します。
メール本文の送信はDATAコマンドで開始され、その後、一行ずつそのまま送信され、データ終了シーケンスで終了します。このシーケンスは、改行（<CR><LF>）、ピリオド（.）、そして別の改行（<CR><LF>）で構成されます。メッセージ本文にはピリオドのみを含む行が含まれる可能性があるため、クライアントは行の先頭にピリオドがあるたびにピリオドを2つ送信します。これに対応して、サーバーは行の先頭にある2つのピリオドのシーケンスを1つのピリオドに置き換えます。このようなエスケープ方法はドットスタッフィングと呼ばれます。
例示されているように、サーバーがデータ終了に対して肯定的な応答を返すと、サーバーがメッセージの配信責任を引き受けたことを意味します。この時点で通信障害が発生した場合（例えば停電など）、メッセージは二重になる可能性があります。送信者はその250 Ok応答を受け取るまで、メッセージが配信されなかったと想定する必要があります。一方、受信者がメッセージを受け入れることを決定した後は、メッセージが配信されたと想定する必要があります。したがって、この期間中、両方のエージェントは配信を試みるメッセージのアクティブなコピーを保持しています。[ 29 ]通信障害がまさにこの段階で発生する確率は、サーバーがメッセージ本文に対して実行するフィルタリングの量に直接比例します。フィルタリングは、多くの場合、スパム対策の目的で行われます。制限タイムアウトは10分に設定されています。[ 30 ]
このQUITコマンドはセッションを終了します。メールに他の宛先がある場合、クライアントはQUIT現在の宛先がキューに登録された後、後続の宛先に対して適切な SMTP サーバーに接続します。クライアントが およびHELOコマンドで送信する情報はMAIL FROM、受信サーバーによってメッセージに追加のヘッダー フィールドとして追加されます (サンプル コードには表示されません)。それぞれReceivedおよびReturn-Pathヘッダー フィールドが追加されます。
クライアントによっては、メッセージが受信された後に接続を閉じるように実装されている場合250 Ok: queued as 12345があるため、最後の 2 行が省略されることがあります。この場合、サーバーが応答を送信しようとしたときにエラーが発生します221 Bye。
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を受信した直後に最大値を宣言しますEHLO。ただし、 RFC 1870によると、応答の拡張に対する数値パラメータはオプションです。クライアントは、コマンドを発行する際に、転送するメッセージのサイズの数値見積もりを含めることができ、サーバーは大きすぎるメッセージの受信を拒否できます。 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で承認された形式で定義され、インターネット割り当て番号機関（IANA）に登録されます。最初の定義は、RFC 821のオプションサービスである、、SEND（SOML送信またはメール）、SAML（送信とメール）、、、EXPNおよびHELPでした。追加のSMTP動詞の形式は、およびのTURN新しいパラメータに対して設定されました。MAILRCPT
今日よく使われるキーワード（すべてがコマンドに対応するわけではない）には、以下のようなものがある。
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 (非推奨[ 35 ] ) ESMTPフォーマットはRFC 2821 （RFC 821に取って代わるもの）で再定義され、2008年にRFC 5321で最新の定義に更新されました。サーバーにおけるこのコマンドのサポートは必須となり、必須のフォールバックとして指定されました。 EHLOHELO
非標準で未登録のサービス拡張機能は、二者間の合意により使用できます。これらのサービスは、EHLO「X」で始まるメッセージキーワードと、同様にマークされた追加のパラメータまたは動詞によって示されます。
SMTP コマンドは大文字と小文字を区別しません。ここでは強調のためにのみ大文字で表示しています。特定の大文字小文字の区別を要求する SMTP サーバーは標準に違反しています。[ 28 ]
少なくとも以下のサーバーは8BITMIME拡張子を宣伝しています。
以下のサーバーは8BITMIMEをアドバタイズするように設定できますが、8BITMIME非対応のリレーに接続する際に8ビットデータを7ビットに変換する処理は行いません。
SMTP-AUTH拡張機能は、アクセス制御メカニズムを提供します。これは、クライアントがメール送信プロセス中にメールサーバーに実際にログインするための認証ステップで構成されています。SMTP-AUTHをサポートするサーバーは通常、クライアントにこの拡張機能の使用を要求するように構成でき、送信者の真の身元が確実に把握されます。SMTP-AUTH拡張機能はRFC 4954で定義されています。
SMTP-AUTH を使用すると、正当なユーザーがメールをリレーできるようにしつつ、スパマーなどの不正なユーザーにはリレーサービスを拒否できます。ただし、SMTPエンベロープの送信者またはRFC 2822の「From:」ヘッダーの正当性を必ずしも保証するものではありません。たとえば、送信者が他人のふりをするなりすましは、サーバーがメッセージの送信元アドレスをこの認証済みユーザーに許可されたアドレスに制限するように設定されていない限り、SMTP-AUTH を使用しても依然として可能です。
SMTP-AUTH拡張機能は、メールを中継する際に、送信者が認証されたことをメールサーバーが別のサーバーに通知することも可能にします。一般的に、これには受信サーバーが送信サーバーを信頼する必要があるため、SMTP-AUTHのこの側面はインターネット上ではほとんど使用されていません。[ 41 ]
サポート対象サーバーは以下のとおりです。
メール配信は平文接続と暗号化接続の両方で行われる可能性があるが、通信当事者は相手が安全な通信チャネルを使用できるかどうかを事前に知ることはできない。
STARTTLS拡張機能により、対応するSMTPサーバーは、接続するクライアントに対し、TLS暗号化通信をサポートしていることを通知し、クライアントがSTARTTLSコマンドを送信することで接続をアップグレードする機会を提供できます。この拡張機能をサポートするサーバーは、その実装自体からセキュリティ上のメリットを本質的に得るわけではありません。TLS暗号化セッションへのアップグレードは、接続するクライアントがこのオプションを使用するかどうかを決定することに依存するため、「オポチュニスティックTLS」と呼ばれます。
STARTTLS は、STARTTLS ネゴシエーションが平文で行われるため、能動的な攻撃者が STARTTLS コマンドを簡単に削除できるため、受動的な監視攻撃に対してのみ有効です。この種の中間者攻撃は、STRIPTLSと呼ばれることもあり、一方の端から送信された暗号化ネゴシエーション情報がもう一方の端に届きません。このシナリオでは、両方の当事者が無効または予期しない応答を、相手が STARTTLS を適切にサポートしていないことを示すものとみなし、従来の平文メール転送にデフォルト設定します。[ 50 ] STARTTLS は他の RFC でIMAPおよびPOP3についても定義されていますが、これらのプロトコルは異なる目的で使用されます。SMTP はメッセージ転送エージェント間の通信に使用され、IMAP および POP3 はエンド クライアントとメッセージ転送エージェントに使用されます。
2014年に電子フロンティア財団は「STARTTLS Everywhere」プロジェクトを開始しました。これは「HTTPS Everywhere」リストと同様に、事前の通信なしに、依拠当事者が安全な通信をサポートする他の当事者を発見できるようにするものでした。このプロジェクトは2021年4月29日に提出の受付を終了し、EFFはピアのTLSサポートに関する情報を発見するためにDANEとMTA-STSに切り替えることを推奨しました。[ 51 ]
RFC 8314は、プレーンテキストを正式に廃止し、メールの送信とアクセスには常に TLS を使用することを推奨し、暗黙的に TLS を使用するポートを追加しました。
RFC 7672では、 DNS レコードでメールサーバーの暗号化機能を宣言する機能が導入されました。DNSSEC を利用することで、メールサーバーのオペレーターは TLS 証明書のハッシュを公開することができ、暗号化されていない通信の可能性を軽減できます。[ 52 ]
マイクロソフトは、2024年末までにExchange Onlineの顧客向けに完全なSMTP DANEサポートを有効にする予定です。[ 53 ]
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 MailはMTA-STSのサポートを発表した。[ 54 ]
メッセージを安全に配信するように設計されたプロトコルは、設定ミスや意図的な妨害によって失敗する可能性があり、その結果、メッセージが配信されなかったり、暗号化されていないチャネルや認証されていないチャネルで配信されたりすることがあります。RFC 8460 「 SMTP TLSレポート」では、潜在的な障害に関する統計情報や具体的な情報を受信ドメインと共有するためのレポートメカニズムとフォーマットについて説明しています。受信ドメインはこの情報を使用して、潜在的な攻撃を検出したり、意図しない設定ミスを診断したりすることができます。
2019年4月、GmailはSMTP TLSレポートのサポートを発表しました。[ 54 ]
SMTPの当初の設計では、送信者を認証したり、サーバーが送信者の代理として送信する権限を持っているかどうかを確認したりする機能がなかったため、メールのなりすましが可能であり、メールスパムやフィッシングでよく利用されている。
SMTPを大幅に変更したり、完全に置き換えたりする提案が時折なされる。その一例がInternet Mail 2000だが、これも他のどの提案も、従来のSMTPの膨大なインストールベースが生み出すネットワーク効果の前には、大きな進展を見せていない。
その代わりに、メールサーバーは現在、RFC 5322 [ 55 ] [ 56 ] DomainKeys Identified Mail、Sender Policy Framework、DMARC、DNSBL、グレイリスティングなどの標準のより厳格な適用といったさまざまな技術を使用して、疑わしいメールを拒否または隔離しています。[ 57 ]
先月、Yahoo、America Online、EarthLink、Microsoftによって昨年設立されたアンチスパム技術アライアンスは、ポート25のフィルタリングを含むアンチスパム推奨事項のリストを発表しました。
{{cite book}}:値の確認|isbn=: チェックサム (ヘルプ): 新しいSMTPUTF8サポート新バージョンに合わせて更新