投稿とドメイン間配送

社員アリスがalice@example.comから取引先bob@partner.exampleへメールを送るとします。投稿用サーバMSA-1、外向きMTA-1、取引先のMXで何が違い、どこでTLS・認証・中継許可を判断するのでしょうか。SMTP、SMTP AUTH、STARTTLS、SMTPS、メールリレー、オープンリレーを一通の配送で追います。以下のアドレス、時刻、ログ、設定は架空です。

読む順序は、投稿と配送の役割→SMTPコマンド→TLS・認証→中継ポリシー→異常ログと復旧→演習です。科目B（午後）では、TCP接続、TLS確立、SMTP AUTH成功、RCPT受理、キュー投入、最終配送を別の事実として答えます。

1. 投稿とMTA間配送の境界を決める

用語	この例での役割と限界
SMTP	メール転送に使うアプリケーション層のプロトコル。EHLO、MAIL FROM、RCPT TO、DATAなどを交換する。TCP接続に成功しただけでは本文を受理していない。
MUA / MSA	MUAはアリスのメールクライアント。MSA-1は投稿を受け、認証や送信ポリシーを適用するMessage Submission Agent。通常は587番、または465番で受け付ける。
MTA / MX	MTA-1はメールを次のMTAへ転送する。取引先のMXはpartner.example宛てを受けるメール交換先。MTA間のSMTPは通常25番を用いる。MXは送信者を認証する仕組みではない。
SMTP AUTH	投稿者がMSAへSASLで認証する拡張。認証済みの主体と、送信を許可するFrom・宛先・量は別途判定する。受信側のSPF・DKIM・DMARCとは役割が異なる。
STARTTLS	平文のSMTP接続でSTARTTLS拡張を合意し、その接続をTLSへ切り替える。587番投稿では成功を必須にできる。MTA間25番で任意TLSなら未暗号化へのフォールバックも起こり得る。
SMTPS / implicit TLS	465番の投稿で、接続開始時からTLSを開始する方式の通称。587番STARTTLSも、TLSを必須に正しく設定すれば送信時保護を実現できる。465番はMTA間の通常ポートではない。
メールリレー	受けたメールを別ドメインへ転送すること。認証済み投稿者や許可した内部MTAには必要な機能。外部の無認証利用者へ無制限に許すとオープンリレーになる。

アリスのMUAはMSA-1へ587番で接続し、TLSの後に認証します。MSA-1は社内のMTA-1へ渡し、MTA-1はpartner.exampleのMXを調べて25番へ配送します。認証済みアリスによる外部宛て投稿は許可しますが、インターネットの無認証ホストから別の外部ドメインへの中継は拒否します。

投稿とドメイン間配送

MSAへの投稿と、MTA間のリレーを別の区間として示す。

図の最後の応答はMXがその接続で受理したかを示し、ボブのメールボックスへの最終格納や開封までは証明しません。MSA-1が`250 queued`を返しても、その後のMTA-1から先で一時失敗や恒久拒否が起こり得ます。キューIDをつないで追います。

2. 587番STARTTLSとSMTP AUTHの実際の順序

次は587番の架空の簡略トランスクリプトです。応答の複数行形式は省き、認証情報と本文は伏せます。STARTTLSの後に新しいEHLOを送り、TLS後に提示される拡張を再取得します。認証方式に平文パスワード相当の値を使う場合、TLSが成功する前に送らせません。

text

C: EHLO client.example
S: 250-STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
    [TLS handshake; certificate and name verified]
C: EHLO client.example
S: 250-AUTH PLAIN
C: AUTH PLAIN <redacted>
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<alice@example.com>
S: 250 2.1.0 Ok
C: RCPT TO:<bob@partner.example>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CRLF>.<CRLF>
C: From: Alice <alice@example.com>
C: To: Bob <bob@partner.example>
C: Subject: Monthly report
C:
C: <body redacted>
C: .
S: 250 2.0.0 queued as Q-41

`MAIL FROM`は配送エラーの戻り先に関わるエンベロープ送信者、`RCPT TO`は配送先です。`DATA`以降の`From:`と`To:`はヘッダで、特に`To:`だけでは実際の配送先を確定できません。エンベロープとヘッダの値は異なり得ます。SMTP AUTH成功も`Header From`が本人のものと証明するわけではなく、MSAの送信者許可設定が必要です。

応答・状態	観測できる事実と次の確認
220 TCP上の挨拶	SMTPサーバが応答した。TLS確立でも認証成功でもない。
220 Ready to start TLS	TLSへ切り替える準備ができた。TLSハンドシェイクと証明書名の検証成功を別に見る。
235 AUTH成功	MSAが資格情報を受け入れた。送信元アカウントの正当な利用かは認証ログや利用状況で調べる。
250 RCPT受理	その宛先を現時点のポリシーで受け付けた。DATAの後のキュー投入はまだ分からない。
354 DATA開始	本文入力を要求した。メッセージの受理は終端ドット後の最終応答を見る。
250 queued as Q-41	MSA-1が配送責任を引き受けキューに入れた。MXへの配送、受信者の格納、開封は未確認。

3. 465番implicit TLSと25番配送の違い

465番ではTCP接続後すぐにTLSハンドシェイクを開始し、暗号化された中でSMTPの挨拶やAUTHを行います。587番はSMTPの挨拶後にSTARTTLSでTLSへ移ります。両方式とも、証明書の検証とTLSを必須とする設定が重要です。465番だから送信者認証不要、587番だから平文パスワードを流してよい、とは言えません。

MTA-1から取引先MXへの25番は、一般にMTA間配送の区間です。相手のMXがSTARTTLSを提示する場合もありますが、配送側が任意TLSとしていると、TLSに失敗した際に平文へ戻る構成があり得ます。必須TLSを要求する相手・経路は別のポリシーで明示し、実際に合意したTLSと証明書検証結果をログで確認します。

区間	この構成の要件
MUA→MSA-1:587	STARTTLS成功、証明書名検証、SMTP AUTH成功、投稿権限と送信量の制限を必須にする。
MUA→MSA-1:465	代替投稿口。接続直後にTLSを行い、その中でAUTHする。587番と同じ投稿者・宛先ポリシーを適用する。
MSA-1→MTA-1	内部経路でも送信元を限定し、再中継を許す主体を明示する。内部IPであれば誰でも送信可能としない。
MTA-1→取引先MX:25	宛先のMXへ配送する。TLS方針、接続元IP、キュー、再試行、最終応答を記録する。SMTP AUTHの有無だけで評価しない。

4. メールリレーの許可条件とオープンリレー

中継可否は『送信元IPが信頼できるか』『SMTP AUTH済みか』『RCPT TOが自組織宛てか』『外部宛てを許す資格か』などで決まります。外部から自組織の受信者宛てを受けることは通常の受信です。外部の無認証ホストから外部の別ドメイン宛てまで転送することがオープンリレーの典型です。

接続元と宛先	この例の判断
外部・未認証→自組織example.com	受信メールとして処理する。迷惑メール対策などは別に評価する。これだけでオープンリレーではない。
外部・未認証→partner.example	中継を拒否する。`RCPT TO`段階の`550 5.7.1 Relay denied`などで識別する。
アリス・認証済み→partner.example	投稿を許可する。ただしalice@example.comとして送ってよいか、送信量・宛先制限・不正ログインを確認する。
内部の許可済みMTA→外部	必要な中継のみ許可。広い内部ネットワーク全体を信頼すると侵害端末が送信口になる。

オープンリレーを調べるとき、所有する試験用の外部アドレス二つで、未認証かつ外部→外部の`RCPT TO`が受理されるかを管理された環境で確認します。第三者へ実際に大量送信する必要はありません。RCPTで250が返っても、DATA後の受理、後段の配送まで確認したかを区別して記録します。

5. 異常ログから原因を切り分ける

観測	原因候補と追加証拠
STARTTLS不提示	587番のMSA設定誤り、プロキシや中間者による拡張の除去、接続先違いを確認する。投稿クライアントはTLS必須なら認証情報を送らず停止する。
TLS証明書エラー	名前、有効期間、チェーン、接続先を確認する。『暗号化された』だけでは相手の真正性を保証しない。
535 AUTH失敗	資格情報、認証方式、アカウント停止、MFA・アプリパスワードの要件などを調べる。`535`から漏えいを断定しない。
530 AUTH required	MSAへの未認証投稿を拒否した。受信MTAが自組織宛てを受ける動作と混同しない。
550 5.7.1 Relay denied	その宛先への中継を恒久拒否した。正規送信者なら認証・許可IP・ポリシーを確認する。
451等の一時失敗	キューに残して再試行する可能性がある。即座に不達確定とせず、次の試行と最終DSN・バウンスを追う。

架空ログではQ-41がMSA-1からMTA-1へ渡り、取引先MXが最終的に受け付けます。`auth=alice`は投稿時だけの事実で、取引先MXがアリスを認証した意味ではありません。

text

09:00:01 msa=MSA-1 peer=10.20.1.41:51522
  tls=ok auth=alice mail_from=alice@example.com
  rcpt_to=bob@partner.example queue=Q-41 accepted=250
09:00:03 mta=MTA-1 queue=Q-41 next=mx.partner.example:25
  tls=ok peer_reply=250 remote_queue=R-27
09:00:04 queue=Q-41 state=delivered-to-next-hop

このログだけではボブが読んだか分かりません。取引先MXでの受理後に配送不能となる場合もあり、後続のDSNや相手側ログが必要です。`tls=ok`もTLS版、証明書検証、必須ポリシーの適用を全て示すとは限らず、製品の項目定義を確認します。

5-1. MAIL FROMとHeader Fromを別々に制限する

MSA-1でアリスを認証した後、`MAIL FROM:<ceo@example.com>`を無条件に許せば、同じ組織内の別人を装う投稿ができます。認証主体が使えるエンベロープ送信者とHeader Fromを、代理送信や共有メールボックスの例外も含めて明示的に許可します。送信後にDKIM署名が付いても、送信者権限を誤っていれば正規ドメインの署名付き偽メールが生まれます。

正規の業務システムが複数の送信元アドレスを使う場合、個人アカウントの資格情報を共用せず、用途別のサービス主体、許可するFrom、宛先、時間帯、送信量を定義します。アカウント侵害を調べる際は`auth_user`、エンベロープ送信者、Header From、接続元端末を一通ごとに突き合わせます。

5-2. TLSが失敗したときの方針

587番の投稿ではTLSが成立しなければAUTHを始めず、送信も停止する設定とします。取引先MXへの25番では、相手がTLSに対応しない場合の配送方針を宛先ごとに決めます。機密度の高い取引先に必須TLSを指定したなら、失敗時に平文へ戻して配送してはいけません。キューに保持し、原因を通知して再試行または別経路を選びます。

障害調査では、接続できない、EHLOにSTARTTLSがない、TLSハンドシェイクが失敗する、証明書の名前が合わない、AUTHに失敗する、RCPTを拒否される、DATA後に一時失敗する、という順に分解します。各段階で対応するログと再試行可否が異なるため、単に『メールが送れない』とまとめません。

6. 誤設定の影響と復旧

異常な送信量を検知したら、キューID、認証主体、接続元、MAIL FROM、RCPT TO、TLS結果、受理・拒否の時刻を保全する。資格情報をログへ残さない。
外部未認証から外部宛てへの中継を閉じる。許可元IP・認証主体・宛先ドメインを最小化し、RCPT段階とDATA後の動作を確認する。
認証済みアカウントの悪用なら、資格情報・トークンの失効、セッション調査、送信量制限、MFAや端末調査を行う。リレー設定だけ直しても不正投稿は止まらない。
キューに残る不正メールと正規メールを区別し、誤配信の影響、バウンス、送信元レピュテーションを調査する。正規宛先への再送は重複送信にならないようキュー状態で決める。
587・465・25の各経路で、TLS、認証、許可・拒否、キュー投入、MX受理を試験する。設定変更後の正常メールと拒否すべき中継の双方を確認して復旧とする。

`250 queued`が大量に出た場合、その時点で受理したメールは後から拒否ポリシーを変えても自動で取り消せません。キュー内の対象IDを特定し、未送信分を停止し、既に次ホップが受理した分は相手先との連絡が必要です。認証成功ログだけで『オープンリレー』と断定しないことも重要です。

7. 科目B（午後）の判断と演習

演習1：587と25

条件：アリスのMUAが587へ、MTA-1が取引先MXの25へ接続。質問：SMTP AUTHを要求する主な区間はどちらか。解答：投稿用587。誤答『全25番でAUTH必須』はMTA間配送と投稿を混同する。

演習2：STARTTLS応答

条件：サーバは`220 Ready to start TLS`を返した。質問：パスワードを送ってよいか。解答：まだ早い。TLSハンドシェイクと証明書検証が成功し、必要な拡張を再EHLOで確認する。誤答は切替準備とTLS成立を混同する。

演習3：AUTH成功

条件：`235 Authentication successful`。質問：alice@example.comのFromを必ず使えるか。解答：別途送信者権限を確認する。誤答『認証済みなら任意From可』は投稿者認証と送信許可を混同する。

演習4：RCPT受理

条件：RCPTに250が返り、DATAは送っていない。質問：メールは受信者へ届いたか。解答：届いたとは言えない。DATA後の受理と後段配送が必要。誤答『250だから到着』は段階を飛ばしている。

演習5：外部から自組織宛て

条件：外部未認証ホストがbob@example.com宛てを送信。質問：受理したらオープンリレーか。解答：違う。自組織宛ての通常受信。誤答は外部→外部の中継と取り違える。

演習6：認証済み悪用

条件：盗まれたアリスの資格情報で大量投稿。質問：リレー拒否設定だけで止まるか。解答：止まらない。認証済み投稿を許可しているので、資格情報失効とアカウント・端末調査、送信制限が必要。誤答は開放中継と資格情報侵害を混同する。

8. 一次資料

RFC 5321：SMTPのコマンドと応答

RFC 6409：メール投稿とリレーの分離

RFC 3207：SMTP STARTTLS

RFC 4954：SMTP AUTH

RFC 8314：465番implicit TLSと587番STARTTLS

SMTP・SMTP AUTH・STARTTLSとメールリレー