要約
- RFC 5233 は Sieve のアドレス比較に
:userと:detailを加えたが、区切り記号やプラスアドレスの世界共通形式を標準化しなかった。 - ローカルな符号化を決めるのは受信側メールシステムである。目に見えるヘッダーにない宛先情報が、エンベロープの
toに残る場合もある。
記号はローカル、解釈の境界が契約
アドレスの詳細部分は、メールを特定のフォルダーへ振り分けたり、メーリングリストの購読を区別したり、ボイスメールの宛先を示したりできる。よく知られるプラス記号はその一例にすぎない。2008年1月の RFC 5233 は Sieve に :user と :detail という二つのアドレス部分を追加した。比較対象となる部分を定義したのであって、全メールシステムに通用するアドレス文法を作ったのではない。
ローカル部の意味は、受信するメールシステムで解釈される。RFC 5233 はユーザーの後ろに + を置く形だけでなく、 に続けて詳細を置く形も示す。同じ区切り列が複数回現れるときの分割は実装定義で、通常はシステム固有の形式に依存する。実装は、そのメールシステムが採用または許可する符号化と一致させなければならない。その方式を定義・照会する仕組みは RFC の対象外だ。ある事業者が + を詳細の境界に使うからといって、別のシステムも同じとは限らない。
詳細部分が符号化されていないアドレスでは、:user はローカル部全体を指し、Sieve の :localpart と同じ意味になる。その場合、:detail は指定されたキーに一致しない。一方、詳細部分が存在していて長さゼロなら、値は空文字列である。部分がない状態と、空の部分がある状態は区別される。
この RFC はアドレスの出どころも分けて考える。address テストは構造化されたメールヘッダーを調べ、任意の envelope テストは配送時のエンベロープを調べる。特定の受信者に届いた宛先情報で振り分けたい場合、RFC 5233 は多くの場合にエンベロープ to を勧める。メーリングリスト、エイリアス、仮想ドメインでは、その受信者固有の詳細が残る唯一の場所かもしれない。送信元などの外部アドレスを自組織の形式で解釈すれば、一貫しない、または誤った結果になり得る。
RFC 5233 は RFC 3598 の改訂版であり、変更履歴は符号化の説明を一般化し、エンベロープと外部アドレスに関する注意を加えたと記す。IANA の subaddress 登録は拡張名を知らせるもので、各システムが特定形式のアドレスを受け入れる保証ではない。Sieve は提供されたローカル解釈を照合できるが、その解釈自体を定めたり、メールボックスの設定を証明したりはしない。
出典
- RFC 5233、RFC Editor の記録、Datatracker の履歴、検証済み訂正表 3079。
- RFC 3598、RFC 5228、RFC 5322、IANA Sieve 拡張レジストリ、関連する RFC 5230、RFC 5231、RFC 5232。
- 登録・標準メタデータ:Datatracker RFC 5233、Datatracker RFC 3598、RFC Editor の RFC 2119、RFC 2822、RFC 3598、RFC 5228、RFC 5230、RFC 5231、RFC 5232、RFC 5322。
- 後年の解釈上の視点であり、執筆者の意図・実装・採用の証拠ではない:Heng Lu、ノート65、ノート20、ノート64。
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
