SMTP認証(略称SMTP AUTH)は、シンプルメール転送プロトコル(SMTP)の拡張機能であり、クライアントはサーバーがサポートする任意の認証メカニズムを使用してログインできます。これは主に認証が必須となる送信サーバーで使用されます。[ 1 ]
1970年代にジョン・ポステルが規定したSMTPでは、電子メールメッセージの送信にパスワードを使用する機能は提供されていませんでした。各サーバーは設計上、オープンなメールリレーでした。その結果、スパムやワームは当初は問題ではなかったものの、90年代後半には深刻な問題となっていました。[ 2 ] SMTP AUTHが登場する前は、リレークライアントはIPアドレスで識別する必要がありましたが、これは接続を提供するインターネットサービスプロバイダ(ISP)が提供する電子メールサービスにのみ実用的であり、そうでなければSMTP以前のPOPのような特定のハックを使用するしかありませんでした。
ジョン・ガーディナー・マイヤーズは1995年にSMTP認証の最初の草案を公開し[ 3 ] 、その後、 IETFでメール送信プロトコルである拡張SMTP(ESMTP)や簡易認証セキュリティ層(SASL)とともに開発・議論が続けられてきた。ESMTP認証のための古いSASLメカニズム(ESMTPA)はCRAM-MD5であり、 HMAC (ハッシュベースのメッセージ認証コード)におけるMD5アルゴリズムの使用は依然として健全であると考えられている[ 4 ]。
インターネットメールコンソーシアム(IMC)は、1998年にはメールサーバーの55%がオープンリレーであったが[ 5 ]、2002年には1%未満であったと報告した[ 6 ]。
メール送信エージェント(MSA) をポート 587 で使用すると、SMTP 認証が行われます。MSA の使用はほとんどのソフトウェア[ 7 ]でサポートされており、特に、ネットワーク ハブのいくつかがポート 25 をブロックするかSMTP プロキシを使用するため、移動ユーザーをサポートする場合に推奨されます。MSA は、メッセージ エンベロープに有効なアドレスが含まれていることを保証し、ヘッダー フィールドのローカル ポリシーを適用する場合があります。SPF に使用されるエンベロープ送信者(別名)とFromアドレスが認証されたユーザー IDFromと一致することを確認することは、DKIMを使用してメッセージに署名するドメインにとって特に重要です。Return-Path
SMTP AUTH でメッセージを受信した場合、ヘッダー フィールドの句には、ESMTPAなどの「A」で終わるキーワードESMTPSAが提供されます。 [ 8 ]「キーワードは統計または診断目的で提供されます」 (RFC 3848)。Spamassassin などの一部のクライアントによってチェックされます。withReceived
すべての SMTP 拡張機能と同様に、SMTP AUTH は、サポートされている認証方法のリストとともに EHLO レスポンスで通知されます。これらの方法は、STARTTLS の発行後に変更される可能性があり、通常は後者の場合のみ平文パスワードが許可されます。RFC 4954 には次の例が示されています (「C:」と「S:」はプロトコルの一部ではなく、それぞれクライアントとサーバーから送信される行を示します)。
S: 220 smtp.example.com ESMTPサーバー C: EHLO client.example.com S: 250-smtp.example.com こんにちは client.example.com S: 250-AUTH GSSAPI DIGEST-MD5 S: 250-ENHANCEDSTATUSCODES S: 250 STARTTLS C: STARTTLS S: 220 TLSを開始する準備ができました ...TLSネゴシエーションが進行します。TLSレイヤーによって保護された以降のコマンド... C: EHLO client.example.com S: 250-smtp.example.com こんにちは client.example.com S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN C: AUTH PLAIN aWxvdmV3aWtpcGVkaWE= S: 235 2.7.0 認証成功
SMTP AUTH はポート 25 でも使用できます。通常、サーバーは認証資格情報が受け入れられない限り、リレーを意味する RCPT TO コマンドを拒否します。仕様では、サーバーが認証を要求するように構成されていて、クライアントがまだ認証を行っていない場合に、ほとんどのコマンドに対してサーバーが530 5.7.0 認証が必要という応答を発行することを推奨しています。ポート 587 でリッスンしているサーバー、またはプライベート サーバーのみがそのように構成されるべきであり、メッセージ交換 (MX) はそうではありません。ただし、SMTP がデフォルトで認証されないという歴史的な特性により、場合によってはアクセス プロトコルに関して異なる動作が発生します。たとえば、STARTTLS の後に AUTH EXTERNAL を使用する場合などです。[ 9 ]
AUTHコマンドに加えて、この拡張機能はMAIL FROMコマンドにAUTHパラメータも提供し、認証と認可を区別できるようにします。これにより、送信者は自身を識別し、同じセッション中に複数のメッセージを送信できます。認証は必ずしも変更する必要はありませんが、一度確立されると、異なる合意に基づいて異なるメッセージを送信できるため、異なる認可が必要になります。たとえば、異なるユーザーに代わってメッセージを中継することができます。このパラメータの使用は、コマンドを使用して中継権限を付与する場合に比べてはるかに一般的ではありません。
SMTP認証はSMTP用語でいう「拡張機能」であるため、サーバーとクライアントは、廃止されたHELO挨拶ではなく、拡張機能のサポートを示すために挨拶にEHLO動詞を使用する必要があります。[ 10 ]下位互換性のために、拡張機能が使用されていない場合はHELO挨拶が受け入れられる場合があります。
AUTHコマンドの後に続く大文字のテキストは、SMTPサーバーが受け入れる認証タイプのリストです。
認証プロトコルの例としては、以下のようなものがあります。
フォールバックとして元のHELOメカニズムをサポートする必要があります。