← RFC Reference

RFC 1869 – SMTP サービス拡張（ESMTP）

このRFCが存在する理由

元々のSMTPプロトコル（RFC 821、1982年）には新機能を追加するメカニズムがありませんでした。クライアントがサーバーの対応内容を検出する方法もなく、サーバーが機能をアドバタイズする方法もありませんでした。拡張機能のたびに新しい互換性のないプロトコルバージョンが必要でした。

1995年に公開されたRFC 1869は、SMTP拡張機能の汎用フレームワークを定義することでこれを解決しました。HELOの代わりとなるEHLOコマンド（Extended HELLO）を導入しました。クライアントがEHLOを送信すると、サーバーはサポートしている拡張機能のリストで応答します。クライアントは両者が理解できる拡張機能を使用できます。

このフレームワークは非常に基本的なため、後にRFC 5321の基本SMTP仕様に直接組み込まれました。今日のほぼすべてのSMTPセッションはESMTPを使用しており、プレーンなHELOは事実上廃止されました。

仕組み

1. クライアントが接続してサーバーのグリーティングバナーを受け取ります。
2. クライアントがEHLO client.example.comを送信します（古いHELOの代わり）。
3. サーバーが250で応答してからホスト名、続いて各行に1つの拡張機能キーワードで応答します。最後の行以外は250-（継続）を使用し、最後は250 （終了）を使用します。
4. クライアントが拡張機能リストを検査し、サーバーがアドバタイズした機能のみを使用します。
5. サーバーがEHLOを理解しない場合（今日では非常にまれ）、500エラーを返し、クライアントはHELOにフォールバックします。

SMTP例

典型的なESMTP機能ネゴシエーション：

主要な技術的詳細

拡張機能レジストリ

ESMTP拡張機能はIANAに登録されています。各拡張機能はキーワード（例：STARTTLS、AUTH、PIPELINING）を定義し、オプションでパラメータを定義します。電子メール用の最も重要な拡張機能：

EHLO対HELO

HELOは1982年からの元々のSMTPグリーティングです。機能検出を提供しません。EHLOは厳密なスーパーセット：同じグリーティング機能を実行しますが、機能リストもトリガーします。サーバーは両方をサポートする必要がありますが、クライアントは常に最初にEHLOを使用し、EHLOが拒否された場合にのみHELOにフォールバックすべきです。

状態変更後の再EHLO

機能リストはセッション中に変わる可能性があります。STARTTLSハンドシェイク後、クライアントは新しいEHLOを送信する必要があります。サーバーは暗号化接続を通じて異なる拡張機能をアドバタイズする可能性があるためです（例えば、AUTHはしばしばTLSの後にのみ利用可能）。RSETの後、機能リストは有効なままです。

拡張機能パラメータ

一部の拡張機能はEHLO応答行にパラメータを含めます。例えば、SIZE 52428800は50 MB制限を宣言し、AUTH PLAIN LOGINは利用可能な認証メカニズムをリストアップします。拡張機能はMAIL FROMおよびRCPT TOコマンドにパラメータを追加することもできます。例えばMAIL FROM:<user@example.com> SIZE=1048576のように。

一般的なミス

• HELOの代わりにEHLOを使用しない。一部のレガシアプリケーションはまだHELOを送信します。これはすべてのSMTP拡張機能（認証と暗号化を含む）を無効にします。常にEHLOを使用してください。
• EHLO応答をチェックしない。サーバーがアドバタイズしたか確認せずに拡張機能を盲目的に使用するクライアントはエラーが発生します。拡張機能を使用する前に常に機能リストを解析してください。
• セッション間で機能をキャッシュする。サーバーがサポートしている拡張機能は接続間で変わる可能性があります。新しい接続ごとに常に新しいEHLOを実行してください。
• STARTTLS後に再EHLOするのを忘れる。TLSにアップグレードした後、TLS前の機能リストは無効です。更新された機能を取得するために新しいEHLOが必須です。
• 無効なEHLOホスト名を送信する。EHLOへの引数はサーバーのFQDNまたは、ホスト名が利用できない場合は[192.0.2.1]のようなアドレスリテラルである必要があります。空のまたは不正なホスト名を送信すると拒否される可能性があります。
• セキュリティのためにEHLOドメインを無視する。