RFC 5598 – インターネットメールアーキテクチャ
このRFCが存在する理由
RFC 5598以前、メールコミュニティは「MTA」「リレー」「ゲートウェイ」といった用語を曖昧で矛盾した使い方をしていました。異なるRFCが同じコンセプトに対して異なる用語を使用していました。特にSPF、DKIM、DMARCのような認証メカニズムがメッセージパス内で誰が何をしているのかについて正確な定義を必要とするようになると、これは実際の混乱を招きました。
Dave Crockerによって2009年に発行されたRFC 5598は、インターネットメールの包括的なアーキテクチャモデルを提供します。プロトコル仕様ではありません。新しいワイヤフォーマットやコマンドを定義していません。代わりに、メールエコシステムのすべてのアクタ、ロール、機能に名前を付けて定義する参照フレームワークです。ほぼすべての現代的なメールRFCがRFC 5598の用語を参照しています。
動作方法
RFC 5598はメールシステムを異なる機能コンポーネントに分割し、著者から受信者へのメッセージの旅路に沿って編成します。
4つのメイン環境
このアーキテクチャはメッセージが通過する4つの運用環境を定義します：
- メールユーザーエージェント（MUA）環境： ユーザーがメッセージを作成し読む場所。メールクライアント（Gmail、Outlook、Thunderbird、またはAPIを呼び出すアプリ）。
- メールサブミッションエージェント（MSA）環境： メールシステムへの配信のためにMUAからメッセージを受け入れるサービス。RFC 6409に従ってポート587で動作し、認証が必要。
- メール転送エージェント（MTA）環境： コアルーティングインフラストラクチャ。MTAはポート25のRFC 5321（SMTP）を使用してインターネット上でメッセージをリレーします。
- メール配信エージェント（MDA）環境： メッセージを受信者のメールボックスに配置し、IMAP、POP3、またはウェブメール経由でアクセス可能にする最終システム。
メッセージフロー
主要なアクタとロール
| アクタ | 略称 | ロール |
|---|---|---|
| メールユーザーエージェント | MUA | ユーザーのためにメッセージを作成し表示します。メールクライアント。 |
| メールサブミッションエージェント | MSA | 認証されたMUAからメッセージを受け入れ、ポリシーを強制し、MTAインフラストラクチャに注入します。 |
| メール転送エージェント | MTA | SMTPを使用してドメイン間でメッセージをルーティングおよびリレーします。メールの「バックボーン」。 |
| メール配信エージェント | MDA | 受信者のメールボックスへの最終配信。フィルタリングルールを適用する場合があります。 |
| メールストア | MS | メッセージを保存し、IMAP/POP3/JMAP経由でアクセスを提供します。 |
アイデンティティタイプ
RFC 5598はメッセージに関連付けられたさまざまなアイデンティティを慎重に区別します：
| アイデンティティ | どこに表示されるか | 意味 |
|---|---|---|
| 著者 |
From:ヘッダ |
メッセージを作成した個人またはエンティティ |
| 送信者 |
Sender:ヘッダ |
実際にメッセージを送信したエージェント（著者と異なる場合） |
| Return-Path |
MAIL FROMエンベロープ / Return-Path:ヘッダ |
バウンスが送信される場所。転送に責任を持つパーティ |
| 受信者 |
RCPT TOエンベロープ / To:/Cc:ヘッダ |
意図した受信者 |
この区別は認証にとって非常に重要です。SPFはReturn-Pathアイデンティティを検証します。DKIMは著者または仲介者に代わって署名できます。DMARCは著者アイデンティティをSPFおよびDKIM結果に合致させます。
主要な技術詳細
メディエーター
RFC 5598はメッセージを受信してから再投稿するメディエーターと呼ばれるアクタの重要なカテゴリを識別します。その過程で潜在的に変更します：
-
メーリングリスト： メッセージを受信し、リストヘッダを追加し、件名またはボディを変更する可能性があり、購読者に再配布します。リストが新しい
MAIL FROM送信者になります。 - ゲートウェイ： メールと別のメッセージングシステム（例：メールからSMS、メールからファックス）間で変換します。
- 再送信者/再配布者： 同窓生転送アドレスなど、メールを転送または再配布します。
メディエーターはメール認証が複雑である主な理由です。メーリングリストがエンベロープ送信者を変更してメッセージを変更すると、SPFが壊れます（新しい送信者IPは元のドメインに対して承認されていません）。DKIMも壊れる可能性があります（ボディが変更されました）。これはまさにARC（RFC 8617）が解決するために設計された問題です。
ADMD：管理管理ドメイン
RFC 5598はADMDの概念を導入しています。これは単一の管理当局の下で1つ以上のメールサービスを運用する組織の管理上の境界です。例：
- 独自のExchangeサーバーを実行している企業は1つのADMDです。
- Gmail/Google Workspaceは1つのADMDです。
- MailerToGoのようなトランザクションメールサービスは1つのADMDです。
メッセージはあるorganizationのメールインフラストラクチャを離れて別のorganizationに入るときにADMD境界を越えます。認証と信頼決定はこれらの境界で発生します。
エンベロープとコンテンツ
このアーキテクチャはすべてのメールメッセージの2つのレイヤーを公式化します：
-
エンベロープ： ルーティングに使用されるSMTPレベル情報（
MAIL FROM、RCPT TO）。サブミッション中に作成され、各ホップで変更されます。 - コンテンツ： RFC 5322で定義されているメッセージヘッダとボディ。作成後は不変であることを意図していますが、メディエーターが変更する場合があります。
一般的な間違い
- MTAとMSAを混同する。 MSA（ポート587、認証）とMTA（ポート25、サーバー間）は異なる目的を果たします。MSAをバイパスしてリモートMTAにポート25でアプリケーションメールを直接送信すると、認証とポリシー強制がスキップされます。ほとんどのクラウドプロバイダーがこの理由でアウトバウンドポート25をブロックしています。
-
メディエーター問題を無視する。 メッセージがメーリングリストを通過する可能性を考慮せずに厳密なDMARC（
p=reject）を強制すると、転送されたメッセージは宛先で拒否されます。メディエーター概念を理解すると、これを計画するのに役立ちます。 -
From:を送信者として扱う。
From:ヘッダは著者を識別し、転送送信者ではありません。SPFはFromヘッダではなくエンベロープ送信者をチェックします。この区別はDMARC整合の基礎全体です。 - フラットなトポロジーを仮定する。 メッセージは常に送信者から受信者に直接進むわけではありません。複数のMTA、メーリングリスト、転送サービス、ゲートウェイを通過する場合があります。各ホップはエンベロープを変更し、潜在的にコンテンツも変更できます。
- ADMD境界を理解していない。 メール送信をメールサービスに委任すると、メッセージはADMD境界を越えます。SPF、DKIM、DMARCはこの委任を考慮するために設定する必要があります。
配信可能性への影響
- 適切なサブミッションアーキテクチャ。 MTAに直接注入するのではなくMSA（認証付きポート587）を使用すると、メッセージは最初から適切に認証され、ポリシーに準拠していることが保証されます。MailerToGoのようなサービスはMSAとして機能します。
- 認証の整合。 各認証メカニズムがどのアイデンティティをチェックするかを理解する（SPFはReturn-Pathをチェック、DKIMはドメインに代わって署名、DMARCはこれらをFromヘッダに整合させる）には、RFC 5598のアイデンティティモデルを理解する必要があります。
- 転送とリスト処理。 受信者が転送サービスやメーリングリスト（メディエーター）を使用している場合、メッセージは最終宛先で認証に失敗する可能性があります。メディエーターロールを理解すると、「なぜDMARCパスメッセージが拒否されたのか」を診断するのに役立ちます。
- バウンス処理。 アーキテクチャは著者（Fromヘッダ）と返信経路（MAIL FROM）を区別します。バウンスは返信経路に送信されます。返信経路を正しく設定すると、著者への返信と混同することなく、自動的にバウンスを処理できます。