情報処理安全確保支援士 2009年 秋期 午前2 問03
問題文
SMTP-AUTH認証はどれか。
選択肢
ア：SMTPサーバに電子メールを送信する前に、電子メールを受信し、その際にパスワード認証が行われたクライアントのIPアドレスに対して、一定時間だけ電子メールの送信を許可する。
イ：クライアントがSMTPサーバにアクセスしたときに利用者認証を行い、許可された利用者だけから電子メールを受け付ける。（正解）
ウ：サーバはCAの公開鍵証明書をもち、クライアントから送信されたCAの署名付きクライアント証明書の妥当性を確認する。
エ：電子メールを受信する際の認証情報を秘匿できるように、パスワードからハッシュ値を計算して、その値で利用者認証を行う。
🔒 解説は解答すると表示されます
SMTP-AUTH認証【午前2解説】
正解の理由
本問は、SMTPプロトコルにおける「送信クライアントの認証」を問うています。SMTPの拡張であるSMTP-AUTHは、SMTPセッション中にサーバ側がクライアントの利用者認証を行い、認証済み利用者のみメール送信（サブミッション）を許可する仕組みです。したがって、クライアントがサーバに接続したときに利用者認証を行う内容を示す イ が正解です。
補足として重要な点を述べると、SMTP-AUTHはSASL（Simple Authentication and Security Layer）を通じて様々な認証機構（PLAIN／LOGIN：平文、CRAM-MD5：チャレンジ応答、SCRAM、XOAUTH2など）を利用できます。したがって「ハッシュベースのチャレンジ応答がSMTP-AUTHと排他的である」という誤解は成り立ちません（CRAM-MD5等はSMTP-AUTHで利用可能）。一方で本問の選択肢エは「電子メールを受信する際の…」と受信プロセスを指しており、SMTP-AUTHの目的（送信側の認証）とずれているため不正解です。
解法ステップ
- 問題が問う対象を把握：SMTPに関する「認証」の目的は送信（サブミッション）か受信かを確認する。
- 各選択肢の動作をキーワードで照合：
- 「利用者認証を行い、許可された利用者だけから電子メールを受け付ける」→ SMTP-AUTHの定義に合致（送信を受け付ける＝サブミッション）。
- 「受信時に認証」や「CA証明書／クライアント証明書の検証」などは別技術（POP-before-SMTPやTLS相互認証）かを判定。
- SASLやSTARTTLSなどの知識で、ハッシュ方式の可否（CRAM-MD5 等が利用可能）を判断して選択肢を絞る。
- よって イ を正答とする。
選択肢別の誤答解説
-
ア: 「SMTPサーバに電子メールを送信する前に、電子メールを受信し、その際にパスワード認証が行われたクライアントのIPに送信を許可する」
→ これは「POP before SMTP（POP認証による送信許可）」を示す記述です。受信（POP/IMAP）での認証を利用して送信を許可する運用であり、SMTPプロトコルのAUTH拡張（SMTP-AUTH）とは別物です。 -
イ: （正解）「クライアントがSMTPサーバにアクセスしたときに利用者認証を行い、許可された利用者だけから電子メールを受け付ける」
→ SMTP-AUTHはSMTP拡張で、AUTHコマンド（SASL機構）を用いてクライアント認証を行い、認証済み利用者だけに送信を許可します。送信（サブミッション）制御が目的です。 -
ウ: 「サーバはCAの公開鍵証明書をもち、クライアントの署名付きクライアント証明書の妥当性を確認する」
→ これはTLSの相互認証（クライアント証明書）を説明しています。SMTPセッションをTLSで保護しつつクライアント証明書検証を行う運用はあり得ますが、SMTP-AUTH（SASLベースのAUTHコマンド）とは別の認証レイヤです。 -
エ: 「受信する際の認証情報を秘匿するため、パスワードからハッシュ値を計算してその値で認証を行う」
→ 説明が曖昧で誤導を招きます。まずSMTP-AUTHは送信（サブミッション）時に用いる仕組みであり、本選択肢が「受信時」を指す点で不適切です。ただし技術的にはSMTP-AUTHはCRAM-MD5のようなハッシュベースのチャレンジ応答（HMAC系）をSASL経由で使えるため、「ハッシュ方式自体がSMTP-AUTHと排他的である」という誤りは避ける必要があります。さらに受信プロトコル（POP/IMAP）での認証と混同している点も誤りです。
よくある誤解
- POP before SMTP と SMTP-AUTH を同じ仕組みだと考える。
→ POP before SMTP は受信（POP）での認証を用いて送信を許可する運用であり、SMTP-AUTHはSMTPセッション内で直接認証を行う拡張です。 - SMTP-AUTH が常にパスワードを安全に保護すると思い込む。
→ PLAIN／LOGIN は平文で送信されるため、TLS（STARTTLS／SMTPS）なしでは盗聴される危険があります。チャレンジ応答やTLSの併用が必要です。 - クライアント証明書での検証をSMTP-AUTHの一部と混同する。
→ クライアント証明書はTLS層の認証であり、SASLベースのSMTP-AUTHとは別の仕組みです（併用は可能）。
補足コラム
- SMTP-AUTHの実運用では、ポート587（submission）でSTARTTLSを用い、SASLの安全な機構（例：SCRAM系やOAuth2/XOAUTH2）を利用するのが現代的ベストプラクティスです。古いCRAM-MD5やDIGEST-MD5は既知の問題や互換性の観点からあまり推奨されません。
- 代表的なSMTPセッションの流れ（単純化）：
C: EHLO mail.example.com S: 250-STARTTLS C: STARTTLS S: 220 Ready to start TLS (TLSハンドシェイク) C: EHLO mail.example.com C: AUTH SCRAM-SHA-1 ... S: 235 Authentication successful C: MAIL FROM:<user@example.com> C: RCPT TO:<dst@example.org> C: DATA - セキュリティ対策：SMTP-AUTHを有効にする場合は必ずTLSで保護し、強力な認証機構（可能ならOAuth2やSCRAM）を選択してください。
FAQ
Q: SMTP-AUTHは受信（POP/IMAP）の認証にも使われますか？
A: いいえ。SMTP-AUTHはSMTPセッション（主に送信／中継の認証）向けの拡張です。受信はPOP/IMAP側で別途認証を行います。
A: いいえ。SMTP-AUTHはSMTPセッション（主に送信／中継の認証）向けの拡張です。受信はPOP/IMAP側で別途認証を行います。
Q: ハッシュベースの認証（CRAM-MD5）はSMTP-AUTHで使えますか？
A: はい。CRAM-MD5のようなチャレンジ応答型認証はSASLメカニズムとしてSMTP-AUTHで利用可能です。ただし暗号的な強度や実装状況を踏まえ、より安全な機構に置き換えるのが望ましいです。
A: はい。CRAM-MD5のようなチャレンジ応答型認証はSASLメカニズムとしてSMTP-AUTHで利用可能です。ただし暗号的な強度や実装状況を踏まえ、より安全な機構に置き換えるのが望ましいです。
Q: STARTTLSを使えばPLAINでも安全ですか？
A: STARTTLS（またはSMTPS）でTLSによりセッションが保護されていればPLAINやLOGINを使っても平文がネットワーク上で露出するリスクは低減します。しかし、TLSの確実な運用（証明書管理や中間者対策）が前提です。
A: STARTTLS（またはSMTPS）でTLSによりセッションが保護されていればPLAINやLOGINを使っても平文がネットワーク上で露出するリスクは低減します。しかし、TLSの確実な運用（証明書管理や中間者対策）が前提です。
関連キーワード: SMTP-AUTH、SASL、CRAM-MD5、POP-before-SMTP、STARTTLS、SCRAM、SMTPサブミッション
\ せっかくなら /
情報処理安全確保支援士を
クイズ形式で学習しませんか？
クイズ画面へ遷移する→
すぐに利用可能！