SMTP認証

SMTP認証はSMTP AUTHと略されることが多く、シンプルメール転送プロトコル（SMTP）の拡張であり、クライアントはサーバーがサポートする任意の認証メカニズムを使用してログインすることができます。主に認証が必須である送信サーバーで使用されます。 ^[1]

1970年代にジョン・ポステルによって規定されたSMTPは、電子メールメッセージを送信するためのパスワードの使用を提供していませんでした。各サーバーは設計上、オープンメールリレーでした。その結果、スパムやワームは、当初は問題ではありませんでしたが、90年代後半には蔓延するようになりました。^[2] SMTP AUTH以前は、リレークライアントはIPアドレスで識別する必要がありましたが、これは、接続を提供する同じインターネットサービスプロバイダー（ISP）によって提供される電子メールサービス、またはPOP before SMTPなどの特定のハックを使用する場合にのみ現実的でした。

ジョン・ガーディナー・マイヤーズが1995年にSMTP AUTHの最初のドラフトを公開し^{[3] 、その後、メール送信プロトコル、拡張SMTP (ESMTP)、}簡易認証セキュリティ層(SASL)とともにIETFで開発と議論が続けられてきました。ESMTP認証(ESMTPA)用の古いSASLメカニズムはCRAM-MD5であり、HMAC (ハッシュベースのメッセージ認証コード)でのMD5アルゴリズムの使用は今でも健全であると考えられています。^[4]

インターネットメールコンソーシアム（IMC）は、1998年にはメールサーバーの55%がオープンリレーであったが、 ^[5] 2002年には1%未満であったと報告した。^[6]

メール送信エージェント（MSA）を（一般的にはポート587で）使用すると、SMTP AUTHが使用されます。MSAの使用はほとんどのソフトウェア^[7]でサポートされており、特に移動の多いユーザーをサポートするために推奨されます。これは、いくつかのネットワークハブがポート25をブロックするか、SMTPプロキシを使用するためです。MSAは、メッセージエンベロープに適切なアドレスが含まれていることを確認する役割を担い、ヘッダーフィールドにローカルポリシーを適用する場合があります。SPFに使用されるエンベロープ送信者（別名）と送信元アドレスが認証されたユーザーIDと一致することをFrom確認することは、 DKIMを使用してメッセージに署名するドメインにとって特に重要です。 Return-Path

ESMTPAやなどの「A」で終わるキーワードは、メッセージがSMTP AUTHで受信されたときに、ヘッダーフィールドの句ESMTPSAに提供されます。 ^[8] 「キーワードは統計または診断の目的で提供されます」 （RFC 3848）。これらは、 Spamassassinなどの一部のクライアントによってチェックされます。 withReceived

すべての SMTP 拡張機能と同様に、SMTP AUTH は、サポートされている認証方法のリストとともに、EHLO 応答で通知されます。これらの方法は、STARTTLS の発行後に変更される可能性があり、通常は後者の場合にのみプレーン テキスト パスワードが許可されます。RFC 4954 では、次の例が提供されています (「C:」と「S:」はプロトコルの一部ではなく、それぞれクライアントとサーバーによって送信された行を示します)。

S: 220 smtp.example.com ESMTP サーバー
C: EHLO クライアント.example.com
S: 250-smtp.example.com こんにちは client.example.com
S: 250-AUTH GSSAPI ダイジェスト-MD5
S: 250-拡張ステータスコード
S: 250 スタートル
C: スタートルス
S: 220 TLSを開始する準備ができました
    ... TLS ネゴシエーションが続行されます。 
     以降のコマンドは TLS レイヤーによって保護されます...
C: EHLO クライアント.example.com
S: 250-smtp.example.com こんにちは client.example.com
S: 250 AUTH GSSAPI DIGEST-MD5 プレーン
C: AUTH プレーン aWxvdmV3aWtpcGVkaWE=
S: 235 2.7.0 認証成功

SMTP AUTH はポート 25 でも使用できます。通常、サーバーは認証資格情報が受け入れられない限り、中継を意味する RCPT TO コマンドを拒否します。仕様では、サーバーが認証を要求するように設定されていて、クライアントがまだ認証していない場合に備えて、ほとんどのコマンドに対してサーバーが530 5.7.0認証が必要を発行することを推奨しています。ポート 587 でリッスンしているサーバー、またはプライベート サーバーのみをそのように設定する必要があります。Message eXchange (MX) はそうではありません。ただし、SMTP はデフォルトで認証されないという歴史的特徴により、アクセス プロトコルに関して異なる動作が発生する場合があります。たとえば、STARTTLS の後に AUTH EXTERNAL を使用する場合などです。^[9]

AUTHコマンドの他に、拡張機能はMAIL FROMコマンドにAUTHパラメータも提供し、認証と承認を区別できるようにします。これにより、送信者は自分自身を識別し、同じセッション中に複数のメッセージを送信できます。認証は変更する必要はありませんが、いったん確立されると、異なるメッセージがさまざまな合意に従って送信されるため、さまざまな承認が必要になります。たとえば、メッセージはさまざまなユーザーに代わって中継される場合があります。このパラメータの使用は、コマンドを使用して中継権限を付与するよりもあまり一般的ではありません。

SMTP認証はSMTP用語では「拡張機能」であるため、サーバーとクライアントは、廃止されたHELOグリーティングではなく、拡張機能のサポートを示すためにグリーティングにEHLO動詞を使用する必要があります。^{[10]下位互換性のため、}拡張機能が使用されていない場合はHELOグリーティングが受け入れられる場合があります。

AUTHコマンドの後の大文字のテキストは、SMTP サーバーが受け入れる認証の種類のリストです。

認証プロトコルの例には次のようなものがあります。

• PLAIN (Base64 エンコードを使用)
• LOGIN（Base64エンコードを使用）^[11]（PLAINに置き換えられた）
• GSSAPI (汎用セキュリティ サービス アプリケーション プログラム インターフェイス)
• DIGEST-MD5 (ダイジェストアクセス認証)
• MD5
• CRAM-MD5
• OAUTH10A ( RFC 5849 で定義されているOAuth 1.0a HMAC-SHA1 トークン)
• OAUTHBEARER ( RFC 6750 で定義されているOAuth 2.0 ベアラー トークン)
• XOAUTH2 ^[12]

• RFC 3207、トランスポート層セキュリティを介した安全な SMTP のための SMTP サービス拡張、Paul Hoffman、2002 年 2 月。
• RFC 3848、ESMTP および LMTP 伝送タイプの登録、Chris Newman、2004 年 7 月。
• RFC 6409、メールのメッセージ送信、Randall Gellens およびJohn C. Klensin、2011 年 11 月 (2006 年の RFC 4409 は廃止され、1998 年 12 月の RFC 2476 に取って代わりました)。
• RFC 4422、Simple Authentication and Security Layer (SASL)、Alexey Melnikov および Kurt D. Zeilenga、2006 年 6 月。
• RFC 4616、PLAIN SASL メカニズム、K. Zeilenga 編、2006 年 8 月。
• RFC 4954、認証のための SMTP サービス拡張、Robert Siemborski および Alexey Melnikov、2007 年 7 月。
• RFC 7628、OAuth 用の一連のシンプルな認証およびセキュリティ層 (SASL) メカニズム、W. Mills、T. Showalter、H. Tschofenig、2015 年 8 月。

• Erwin Hoffmann、SMTP 認証 [チュートリアル]、最終編集 2017-01-10。

• 電子メール認証
• 簡易メール転送プロトコル
• メール送信エージェント
• 電子メールクライアントのポート番号
• シンプルな認証とセキュリティレイヤー
• オープンメールリレー
• POP ビフォア SMTP