← RFC Reference

RFC 6854: FromおよびSenderヘッダーフィールドのグループ構文

これが存在する理由

RFC 5322ではFromヘッダーに1つ以上のメールボックスアドレスを含めることが必須です。しかし、一部のメッセージは本当に単一の人間の著者を持ちません：

• 自動化されたシステムメッセージ——監視アラート、ビルド通知、スケジュール済みレポート。これらを書いた人はいません。
• メーリングリストダイジェスト——ダイジェストは複数の著者からのメッセージを集約します。「From」アドレスは誰ですか？
• グループで作成されたドキュメント——チームで共同で起案されたメッセージ。
• Noreplyアドレス——一部の組織は、実際のアドレスを公開せずに、返信が期待されないことを示したいと考えています。

RFC 6854はRFC 5322を更新し、FromおよびSenderヘッダーでグループ構文を許可します。グループ構文は0個以上のメールボックスアドレスを含むことができます。つまり、説明的な名前を持つが実際のアドレスを含まないFromヘッダーを持つことができます。

仕組み

グループ構文の基本

グループ構文は既にRFC 5322でToおよびCcなどのヘッダーに対して定義されています。次のようになります：

; グループ構文：display-name ":" [mailbox-list] ";"

; メンバー付きグループ（既にTo/Ccで許可）
To: Engineering Team: alice@example.com, bob@example.com;

; 空のグループ——アドレスなし（RFC 6854の重要なイノベーション）
From: Engineering Team:;

重要な新機能はFromの空のグループです：説明的な名前の後ろにコロンとセミコロン間にアドレスがありません。

Fromでグループ構文使用時の必須項目

RFC 6854は厳密な条件を設定します：

1. Senderヘッダーが必須です。Fromフィールドがグループ構文（特に空のグループ）を使用する場合、メッセージに有効なメールボックスアドレスを含むSenderヘッダーを含める必要があります。これにより、メッセージに対して常に責任のあるアドレスが存在することが保証されます。
2. Senderアドレスは実際に配信可能なメールボックスである必要があります。返信と配信不可を受信できる必要があります。
3. 控えめに使用してください。RFCは明示的に、これが単一の著者を特定できない場合のためのものであると述べています。通常の人から人へのメールは、FromでStandardメールボックス構文を使い続けるべきです。

実践的な例

; 自動化された監視アラート——人間の著者なし
From: Monitoring System:;
Sender: noc@example.com
To: ops-team@example.com
Subject: [ALERT] Database connection pool exhausted

; メーリングリストダイジェスト——複数の著者を集約
From: Dev List Digest:;
Sender: dev-list-owner@lists.example.org
To: dev-list@lists.example.org
Subject: Dev List Digest, Vol 42, Issue 7

; メンバー付きグループ——チームの代わりに指名された著者
From: Security Team: security-lead@example.com;
To: all-staff@example.com
Subject: Mandatory password rotation notice

標準Fromとの違い

重要な技術的詳細

DKIMとの相互作用

DKIMはFromヘッダーに署名します。Fromがグループ構文を含む場合、DKIMはリテラルヘッダー値に対して動作します。DKIM署名のd=ドメインは、Fromグループ内のアドレスと一致する必要はありません（そのようなアドレスがない可能性があるため）。代わりに、DMARCのDKIM整列はSenderヘッダーまたはエンベロープ送信者にフォールバックします。

DMARCとの相互作用

DMARC整列では、Fromドメインがエンベロープ送信者ドメインの認証されたSPFドメインまたはDKIMのd=ドメインと一致する必要があります。Fromに空のグループがある場合、整列する対象のドメインはありません。実際には、これは以下を意味します：

• DMARCは空グループFromヘッダーの整列を評価できません。
• ほとんどのDMARC実装はこれを非該当結果として扱います。
• Senderヘッダーまたはエンベロープ送信者が実際の認証アンカーを提供します。

これにより、DMARC整列がないため、インターネット向けメールでは空グループFromヘッダーが一般的ではありません。DMARCは現在広く展開されています。

クライアント表示動作

メールクライアントはFromのグループ構文を一貫性がなく処理します：

• Gmail：グループ表示名を無視して、SenderアドレスをFromとして表示します。
• Outlook：バージョンに応じて、グループ名またはSenderアドレスを表示する場合があります。
• Apple Mail：通常、Senderアドレスを表示します。
• Thunderbird：括弧内のSenderアドレスを持つグループ表示名を表示します。

一貫性のない表示がこの機能の主な実践的な制限です。

ABNF文法更新

RFC 6854はfromおよびsenderフィールドのRFC 5322文法を更新します：

; RFC 5322オリジナル
from = "From:" mailbox-list CRLF

; RFC 6854更新
from = "From:" (mailbox-list / address-list) CRLF

; address-listはグループ構文を許可
; group = display-name ":" [group-list] ";"

よくある間違い

• Senderヘッダーなしで空グループFromを使用する。RFC 6854では、Fromがメールボックスアドレスのないグループ構文を使用する場合、Senderヘッダーが必須です。Senderがないと、配信不可と返信に責任のあるアドレスがなく、厳密なパーサーはメッセージを拒否します。
• クライアント表示の一貫性を期待する。ほとんどのメールクライアントはFromのグループ構文用に設計されていません。展開前にGmail、Outlook、Apple Mailで テストしてください。表示は受信者にとって混乱を招く可能性があります。
• インターネット向けマーケティングまたはトランザクションメールにこれを使用する。DMARC整列の問題により、空グループFromはメール認証チェックに合格する必要があるメールに対して実用的ではありません。配信可能性を確保するには、標準的なメールボックスFromに固執してください。
• セミコロン終端を忘れる。グループ構文には閉じる;が必須です。なしでは、ヘッダーが不正です：From: Team:は無効です。From: Team:;が正しいです。
• グループ構文と表示名を混同する。From: Team <team@example.com>は表示名を持つメールボックスです。From: Team:;は空のグループです。これらは全く異なる構造で、異なるセマンティクスと要件があります。
• noreplyアドレスで十分な場合にこれを使用する。ほとんどの自動化されたメッセージの場合、From: noreply@example.comはグループ構文よりも簡潔で、より互換性があり、受信者とスパムフィルターにも理解されています。

配信可能性への影響

• 空グループFromはDMARC整列を破壊します。Fromアドレスにドメインがないため、DMARCに整列するものがありません。このスタイルに依存するメッセージは、ほとんどの受信者でDMARC確認に失敗し、送信者ドメインが厳密なDMARCポリシーを持つ場合は拒否またはキューに入ります。
• スパムフィルターは馴染みのないFrom構文にフラグを立てる可能性があります。グループ構文はFromでは珍しいです。通常のメールパターンで訓練されたスパムフィルターは、それを異常として扱い、スパムスコアを上げる可能性があります。
• すべての外部メールで標準From アドレスを優先します。noreply@example.comまたはnotifications@example.comのような実際のメールボックスを使用してください。これはユニバーサルに互換性があり、DMARCに合格し、すべてのクライアントで正しくレンダリングされます。
• グループ構文は制御された環境に適しています。メールインフラストラクチャとクライアントを管理する組織内では、グループ構文は意味のあるチームまたはシステムの著者を表現できます。インターネット向けメールの場合、配信可能性のトレードオフは価値がありません。
• 常に有効なSenderヘッダーを含めてください。テストで配信がなくても機能する場合でも、Senderヘッダーは配信不可、返信、認証のためのフォールバックです。これを省略すると、大規模で静かな失敗のリスクがあります。

Related RFCs