SMTP認証

1970年代にジョン・ポステルによって仕様化されたSMTPは、電子メールメッセージを送信するためのパスワードの使用を提供していなかった。各サーバーは設計上オープンリレーであった。その結果、スパムやワームは、当初は問題にならなかったものの、90年代後半までには深刻な問題となっていた^[3]。SMTP AUTH以前は、「リレークライアント」はIPアドレスによって識別される必要があったが、これは接続を提供する同じISPによって提供される電子メールサービスでのみ実用的であった。それ以外の場合、POP before SMTPなどの特定のハックを使用する必要があった。

ジョン・ガーディナー・マイヤーズは1995年にSMTP AUTHの最初のドラフトを公開し^[4]、その後、メールサブミッションプロトコル、拡張SMTP (ESMTP)、およびSimple Authentication and Security Layer (SASL) とともに、IETFで継続的に開発と議論が行われてきた。ESMTP認証 (ESMTPA) のための古いSASLメカニズムはCRAM-MD5であり、HMAC (ハッシュベースのメッセージ認証コード) におけるMD5アルゴリズムの使用は依然として健全であると考えられている^[5]。

Internet Mail Consortium (IMC) は、1998年にメールサーバーの55%がオープンリレーであったと報告したが^[6]、2002年には1%未満になったと報告している^[7]。

2022年5月30日以降、Googleはパスワードのみでログインするサードパーティアプリのアクセスを遮断した^[8]。

2026年12月末、Microsoft Exchange Onlineは、セキュリティ強化のため、IDとパスワードのみのSMTP AUTHを正式に廃止・デフォルト無効化する予定である^[9]。

一般的にポート587を使用するMail submission agent (MSA) の利用は、SMTP AUTHを暗黙のうちに意味する。MSAの使用はほとんどのソフトウェアでサポートされており^[10]、いくつかのネットワークハブがポート25をブロックするか、SMTPプロキシを使用しているため、特にノマドユーザーをサポートするために推奨されている。MSAは、メッセージエンベロープに適切なアドレスが含まれていることを保証する責任があり、`From`ヘッダーフィールドのローカルポリシーを適用する場合がある。Sender Policy Framework (SPF) に使用されるエンベロープ送信者（別名 `Return-Path`）と `From` アドレスが、認証されたユーザーIDと一致することを確認することは、DomainKeys Identified Mail (DKIM) を使用してメッセージに署名するドメインにとって特に重要である。

SMTP AUTHを使用してメッセージを受信した場合、`Received`ヘッダーフィールドの `with` 句には `ESMTPA` や `ESMTPSA` などの「A」で終わるキーワードが提供される^[11]。「これらのキーワードは統計的または診断的な目的のために提供されている」（RFC 3848）。これらは、SpamAssassinなどの一部のクライアントによってチェックされる。

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

S: 220 smtp.example.com ESMTP Server
C: EHLO client.example.com
S: 250-smtp.example.com Hello client.example.com
S: 250-AUTH GSSAPI DIGEST-MD5
S: 250-ENHANCEDSTATUSCODES
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
    ... TLS negotiation proceeds. 
     Further commands protected by TLS layer ...
C: EHLO client.example.com
S: 250-smtp.example.com Hello client.example.com
S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN
C: AUTH PLAIN aWxvdmV3aWtpcGVkaWE=
S: 235 2.7.0 Authentication successful

SMTP AUTHはポート25でも使用できる。通常、サーバーは認証情報が受け入れられない限り、リレーを意味するRCPT TOコマンドを拒否する。仕様では、サーバーが認証を必要とするように構成されており、クライアントがまだ認証を行っていない場合、ほとんどのコマンドの応答として `530 5.7.0 Authentication required` を発行することを推奨している。そのように構成すべきなのは、ポート587でリッスンしているサーバーやプライベートサーバーのみであり、Message eXchange (MX) ではない。しかし、デフォルトではSMTPが認証されないという歴史的な特徴により、一部のケースではアクセスプロトコルに関する動作が異なる結果をもたらす。例えば、STARTTLSの後にAUTH EXTERNALを使用する場合などである^[12]。

`AUTH` コマンドに加えて、この拡張機能は認証と認可を区別できるようにするために、`MAIL FROM` コマンドに対する `AUTH` パラメータも提供する。これにより、送信者は自身を識別し、同じセッション中に複数のメッセージを送信できる。一度確立されると認証を変更する必要はないが、異なる合意に従って異なるメッセージが送信される可能性があり、したがって異なる認可が必要になる場合がある。例えば、メッセージが異なるユーザーに代わってリレーされる場合などである。このパラメータの使用は、リレー権限を付与するためにコマンドを使用するよりもはるかに普及していない。

SMTP認証はSMTPの用語において「拡張機能」であるため、時代遅れのHELO挨拶とは対照的に、拡張機能のサポートを示すためにサーバーとクライアントが挨拶としてEHLO動詞を使用する必要がある^[13]。後方互換性のため、拡張機能が使用されない場合にはHELO挨拶が受け入れられることがある。

`AUTH` コマンドに続く大文字のテキストは、SMTPサーバーが受け入れる認可の種類のリストである。

認可プロトコルの例は以下の通りである。

• PLAIN (Base64エンコーディングを使用)
• LOGIN (Base64エンコーディングを使用)^[14] (PLAINの採用により廃止)
• GSSAPI (Generic Security Services Application Program Interface)
• DIGEST-MD5 (Digest access authentication)
• MD5
• CRAM-MD5
• OAUTH10A (RFC 5849で定義されているOAuth 1.0a HMAC-SHA1トークン)
• OAUTHBEARER (RFC 6750で定義されているOAuth 2.0ベアラートークン)
• XOAUTH2^[15]

SMTP認証では、Basic認証が用いられている。このため、リスト型攻撃やブルートフォース攻撃への脆弱性が指摘されている。また、暗号化通信に非対応のため、通信の傍受に弱いという脆弱性も指摘されている。Microsoft（Exchange Online / Microsoft 365）やGoogle（Google Workspace）は、基本認証を段階的に廃止し、OAuth 2.0やAPIを利用する方法への移行を強制している^[8][9]。

自社開発のWebアプリケーション等からメールを自動送信する場合、SMTPプロトコル自体から脱却し、各クラウドベンダーが提供するAPIを利用する方法が推奨されている。MicrosoftのMicrosoft Graph API、Google WorkspaceのGmail APIなどが例としてあげられる。セキュリティが強固であり、メール送信以外の機能への拡張も容易であるというメリットがある。

アプリケーション側が対応している場合、SMTPプロトコルは維持したまま、認証方式のみをOAuth 2.0に切り替える方法である。パスワードの代わりに有効期限付きのアクセストークンを用いて認証を行う。既存のSMTP送信ライブラリ（JavaMail、PHPMailerなど）が対応していれば、比較的少ない変更で導入可能である^[16]。

アプリケーションから、APIキーを用いSendGrid、Amazon SES、MailgunなどのSMTPリレーサービスを利用し、外部へメールを配信する方法がある。大量配信に強く、到達率の管理も委託できる利点がある。

OAuth 2.0やAPIに対応できない古いシステムやオフィスの複合機を利用している場合の代替案である。認証にIDやパスワードを使わず、「自社の固定IPアドレスからの通信であれば許可する」という設定を管理画面で行う。機器側の設定変更を最小限に抑えられるが、固定IPアドレスが必須となる。

• RFC 3207, SMTP Service Extension for Secure SMTP over Transport Layer Security, Paul Hoffman, February 2002.
• RFC 3848, ESMTP and LMTP Transmission Types Registration, Chris Newman, July 2004.
• RFC 6409, Message Submission for Mail, Randall Gellens and John C. Klensin, November 2011 (2006年のRFC 4409を廃止し、それは1998年12月のRFC 2476を置き換えた).
• RFC 4422, Simple Authentication and Security Layer (SASL), Alexey Melnikov and Kurt D. Zeilenga, June 2006.
• RFC 4616, The PLAIN SASL Mechanism, K. Zeilenga, Ed., August 2006.
• RFC 4954, SMTP Service Extension for Authentication, Robert Siemborski and Alexey Melnikov, July 2007.
• RFC 7628, A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth, W. Mills, T. Showalter and H. Tschofenig, August 2015.