用語辞典・メール

SMTP AUTH

SMTP AUTHとは

SMTP AUTHは、SMTPでメールを送信する利用者を、ユーザー名やパスワードなどで認証する仕組みです。正式にはSMTP Service Extension for Authentication(エスエムティーピー・サービス・エクステンション・フォー・オーセンティケーション)で、一般に「エスエムティーピー・オース」と読みます。

SMTPの拡張としてAUTH命令と利用できるSASL機構を追加します。主にメールアプリが投稿サーバーへ「このアカウントとして送信を依頼できる」と示すために使います。

SMTP AUTHが確認するのは投稿クライアントの資格です。メール画面の差出人が本人か、送信ドメインが正当か、受信者が安全かを単独で保証しません。

投稿サーバーの入口で、保護された接続を通じて利用者資格を確認し、許可された送信キューへ受け入れる認証成功後も、送信元・宛先・送信量などの認可規則を適用する
メールアプリの利用者が閉じた投稿ゲートで資格を提示し、保護された通信路で確認後にゲートが開いて封筒を送信キューへ預けるSMTP AUTHのピクトグラム図解
図1認証を通過しても、別人のアドレスをFromへ自由に設定できるかはサーバーの認可ポリシー次第です。

接続、暗号化、認証、認可、投稿を順に分ける

一つの送信操作を、通信路と利用者資格と送信許可の検査へ分解するパスワードが正しくても、認可条件に合わなければ送信は拒否される
  1. EHLO
    サーバー機能を確認する

    応答のAUTH広告から、その接続で利用できるSASL機構を知る

  2. TLS
    資格情報を守る通信路を確立する

    証明書を検証し、平文相当の資格情報を盗聴・改ざんから保護する

  3. AUTH
    認証交換を行う

    選んだSASL機構で認証ID、証明、必要なら認可IDを提示する

  4. Policy
    許可された操作を判断する

    差出人、宛先、送信量、サイズ、組織規則に基づいて認可する

  5. Submit
    配送キューへ受け入れる

    SMTPトランザクションを完了し、以後の中継責任を投稿サーバーへ渡す

図2認証前後でサーバーが広告する機構一覧は変わり得ます。TLS確立後はEHLOから機能確認をやり直します。

SMTP AUTHはSASLの枠組みを使う

SASL(Simple Authentication and Security Layer/シンプル・オーセンティケーション・アンド・セキュリティ・レイヤー)は、アプリケーションプロトコルへ認証機構を組み込む枠組みです。SMTP AUTHはSASLの機構名と応答交換をSMTPへ載せます。

サーバーはEHLO応答でAUTHと利用可能な機構を広告します。クライアントは対応機構を一つ選び、AUTH命令で交換を始めます。成功応答は認証完了を示しますが、メッセージがまだ受理されたわけではありません。

認証IDと認可IDは同じとは限らない

authentication identity(認証ID)は資格情報で証明する主体、authorization identity(認可ID)はその資格で操作したい主体です。通常は同じですが、代理送信や管理機能では異なる場合があります。

メールアドレス全体をユーザー名にするサービスも、@より前だけや別のアカウントIDを使うサービスもあります。受信設定のユーザー名から推測せず、提供者の送信設定を一字ずつ確認します。

PLAINはBase64にしただけでは秘密にならない

SASL PLAINでは、認証情報を規定形式で送り、SMTP上ではBase64表現になることがあります。Base64は暗号化ではなく、誰でも元へ戻せる符号化です。TLSなしで送れば盗聴者に資格情報を読まれます。

RFC 4954は、平文パスワード機構を許すならSTARTTLSなどの盗聴保護を要求します。クライアントはSTARTTLSまたは暗黙的TLSを確立し、証明書のホスト名と信頼性を検証してから認証します。

パスワード以外の機構でも、サーバーと通信路の確認が必要

SASLにはチャレンジ応答、外部証明書、OAuth系トークンなど複数の機構を組み込めます。トークンは権限と有効期間を絞れますが、盗まれてよい情報ではありません。TLSと正しい接続先確認が必要です。

機構名だけで安全性を決めず、相互認証、リプレイ耐性、資格情報の保存、失効、ログへの露出を評価します。古い機構を互換性だけで有効にし続けないようにします。

認証成功とFromの利用許可を分ける

認証済み利用者が設定できるヘッダーFromエンベロープFromは、投稿サーバーの認可規則で制限できます。本人の別名、共有メールボックス、代理権限などを登録して許可します。

制限が弱いサーバーでは認証者が任意のFromを書ける場合があります。そのメッセージがSMTP AUTH済みでも、表示された差出人の真正性は証明しません。受信側はSPFDKIMDMARCなどを別に評価します。

失敗回数とログを安全に扱う

繰り返し失敗はパスワード違いだけでなく、ユーザー名形式、TLS要件、機構非対応、アカウント停止、二要素認証用アプリパスワード不足が原因になります。むやみに試すとロックや不正アクセス検知を起こします。

接続先、ポート、TLS方式、証明書結果、広告されたAUTH機構、SMTP応答コード、アカウント状態を記録し、パスワードやトークン自体はログ・画面共有へ残さないことが基本です。

認証拡張の確認資料:RFC 4954「SMTP Service Extension for Authentication」RFC 4422「SASL」RFC 6409「Message Submission for Mail」

関連用語