RFC 4954: SMTP AUTH 拡張
このツールが存在する理由
元のSMTP（RFC 5321）には送信者認証の概念がありませんでした。どのクライアントからでも任意のサーバーに接続し、誰にでもなりすましてメールを送信できました。この設計は初期のインターネットでは機能していましたが、スパム問題の基礎となりました。
RFC 4954はSMTPへのAUTH拡張機能を定義しており、クライアントがメッセージを送信する前にメールサーバーに対して認証する標準的な方法を提供します。SASL（Simple Authentication and Security Layer）フレームワークを使用して、SMTPプロトコル自体を変更することなく、複数の認証メカニズムをプラグインすることができます。
このRFCはRFC 2554（1999年）を廃止にし、セキュリティの問題を修正し、AUTHとSTARTTLSなどの他のSMTP拡張機能との相互作用を明確にしました。
仕組み
AUTH交渉
- クライアントが接続して
EHLOを発行します。 - サーバーが
250-AUTHとサポートされているSASLメカニズムのリストを返します。 - クライアントがメカニズムを選択して
AUTH <mechanism>を送信します。初期レスポンスをオプションで含めることができます。 - サーバーとクライアントが1回以上のチャレンジ/レスポンスラウンドを交換します（メカニズムに依存）。
- サーバーが
235（認証成功）または535（認証失敗）で応答します。
SMTPトランスクリプト：AUTH PLAIN
PLAINメカニズムは、認可アイデンティティ、認証アイデンティティ、パスワードを含む単一のBase64エンコード文字列で認証情報を送信します。
SMTPトランスクリプト：AUTH LOGIN
LOGINメカニズムはユーザー名とパスワードに別々のチャレンジ/レスポンスを使用します。
SMTPトランスクリプト：AUTH失敗
重要な技術詳細
SASLメカニズム
RFC 4954は認証メカニズムを直接定義していません。フレームワークを提供しており、メカニズムはSASLレジストリから来ます。SMTPで最も一般的に使用されるもの：
| メカニズム | 動作方法 | セキュリティに関する注記 |
|---|---|---|
PLAIN |
単一のBase64文字列：\0authzid\0password
|
シンプルで広くサポートされています。TLSの上でのみ使用してください。 |
LOGIN |
ユーザー名とパスワード用の2ステップチャレンジ/レスポンス | 非標準ですが普遍的です。TLSの上でのみ使用してください。 |
XOAUTH2 |
フォーマット済み文字列内のOAuth 2.0ベアラートークン | パスワードは送信されません。トークンベース。GmailとMicrosoft 365で使用されます。 |
SCRAM-SHA-256 |
チャネルバインディング付きのソルト付きチャレンジ/レスポンス | パスワードは送信されません。相互認証。最高のセキュリティですが、SMTPでの採用は限定的です。 |
CRAM-MD5 |
MD5 HMACを使用したチャレンジ/レスポンス | 非推奨。MD5は脆弱と考えられています。パスワード送信を回避しますが、リプレイ攻撃から保護しません。 |
AUTH PLAIN認証情報フォーマット
PLAINメカニズムはヌルバイト（\0）で区切られた3つのフィールドをエンコードした後、Base64エンコードします。
初期レスポンス最適化
RFC 4954はクライアントが初期SASLレスポンスをAUTHコマンドと同じ行で送信することを許可しています（上記のPLAINの例に示されているように）。サーバーが最初に空のチャレンジを送信する古い2ステップアプローチと比較して、1往復の通信が削減されます。PLAINのようなクライアントが先に話すメカニズムでは、この最適化は標準的です。
STARTTLSとの相互作用
RFC 4954は、サーバーがTLSが確立されるまでAUTHをアドバタイズしないことを強く推奨しています。これにより、クライアントが誤ってプレーンテキストで認証情報を送信することを防ぎます。典型的な流れは：
- 接続 → EHLO → サーバーはSTARTTLSをアドバタイズしますがAUTHはしません
- STARTTLS → TLSハンドシェイク
- もう一度EHLO → サーバーがAUTHをアドバタイズします（STARTTLSはリストされていません）
- AUTH → メッセージを送信
レスポンスコード
| コード | 意味 |
|---|---|
235 |
認証成功 |
334 |
サーバーチャレンジ（SASLexchangeの継続） |
432 |
パスワード変更が必要（サーバーはパスワード変更を要求） |
454 |
一時的な認証失敗（後で再度試してください） |
500 |
AUTHコマンド認識なし（サーバーはAUTHをサポートしていません） |
534 |
認証メカニズムが弱すぎます（サーバーはより強力なメカニズムを要求） |
535 |
認証認証情報無効 |
AUTHとMAIL FROMアイデンティティ
認証に成功した後、サーバーは接続を認証されたアイデンティティに関連付けます。MSAはその後、MAIL FROMとヘッダーFrom:アドレスが認証されたユーザーと一致する（または認可される）ことを強制できます。これにより、認証されたユーザーが任意の送信者アドレスになりすまし失敗します。
一般的な過ち
- STARTTLSの前にAUTHを送信する。サーバーがプレーンテキスト接続でAUTHをアドバタイズする場合（一部の設定が間違ったサーバー）でも、認証情報は平文で送信されます。認証する前に必ずTLSを確立してください。ポート465での暗黙的TLSでは、これは自動です。
-
Base64エンコーディングを暗号化と混同する。Base64はエンコーディングで、暗号化ではありません。
AUTH PLAINは簡単にデコード可能な形式で認証情報を送信します。保護はBase64レイヤーではなくTLSレイヤーから来ます。 - 535エラーを処理しない。AUTHが失敗したということは、サーバーが認証情報を拒否したということです。同じ認証情報をループで再試行するとIPがレート制限されるかブロックされます。認証情報を確認してエレガントに失敗してください。
- PLAINが利用可能な場合にAUTH LOGINをハードコーディングする。LOGINは非標準メカニズムで、実装が一貫性がありません。サーバーがPLAINをサポートしている場合は、それを優先します。XOAUTH2またはSCRAMをサポートしている場合は、それらを優先します。
- STARTTLS後にEHLOを再発行しない。TLS確立後に機能リストが変更されます。AUTHはpost-TLS EHLOレスポンスにのみ表示される場合があります。2番目のEHLOをスキップするということは、クライアントがAUTHサポートを発見することはないということです。
-
初期レスポンス最適化を無視する。インライン認証情報なしで
AUTH PLAINを送信すると、不要な追加往復が強制されます。ほとんどの最新のサーバーは初期レスポンスをサポートしています。 - 「セキュリティ」のためにCRAM-MD5を使用する。CRAM-MD5はプレーンテキストパスワード送信を回避しますが、MD5（破壊）を使用し、リプレイ攻撃から保護しないため、サーバーはパスワードを回復可能な形式で保存する必要があります。PLAIN over TLSは厳密に優れています。
配信可能性への影響
- メッセージ送信に必須。すべての最新の電子メールサービスは送信（RFC 6409）にSMTP AUTHを要求します。認証なしでは、サーバーはメッセージを530（認証が必要）レスポンスで拒否します。
- 送信者アイデンティティバインディングを有効化。認証は各メッセージを既知のアカウントに関連付けます。これにより、メールサービスは送信ポリシーを強制し、DKIM署名を適用し、認証された送信者ごとに評判を追跡できます。
- オープンリレー悪用を防止。配信のためのメッセージを受け入れる前に認証を要求することにより、サーバーはオープンリレーとして悪用されることを回避します。これはサーバー上のすべてのユーザーのIPブラックリスト化と配信失敗に素早く結果します。
- 最新の統合向けOAuth2。GmailとMicrosoft 365などのサービスはパスワードベースのAUTHを廃止し、XOAUTH2を優先しています。トークンベース認証への移行は、基本認証が無効化されるときのサービス中断を回避します。
- レート制限と悪用防止。認証されたセッションは、ユーザーごとのレート制限を許可します。1つのアカウントが侵害された場合、サービスは同じインフラストラクチャ上の他の送信者に影響を与えることなく、そのアカウントをスロットルまたは無効化できます。