hoge+fuga@example.com は「エイリアス」ではない（壁打ちまとめ）
hoge+fuga@example.com は「エイリアス」ではない（まいさん、2026/06/28）
hoge+fuga@example.com のような + 記法は「エイリアス」ではなく subaddress（拡張アドレス） である。
両者は仕組みも経路もセキュリティ特性も異なる、まったくの別物である。
/etc/aliases（本来のエイリアス） | subaddress（+記法） | |
|---|---|---|
| 仕組み | 事前に明示登録された別名対応 | 区切り文字以降を機械的に切り落として本体に合流 |
| 必要な権限 | root / サーバ管理者 | ユーザー本人のみ（送信側で決めるだけ） |
| 変更コスト | サーバ設定ファイルの変更が必要 | 即時かつ無制限に使い分け可能 |
| 本体アドレスの秘匿性 | 文字列上のつながりを持たない名前を登録できる（本体が割れない） | + より前を見れば本体が機械的にわかる |
| 規格上の位置づけ | Sendmail由来の実装機能 | 「ローカルパートの意味づけは受信側に委ねる」というRFC 5321/5322を背景に、各MTAが慣習的に実装 |
理解したこと（壁打ちの流れ）
Section titled “理解したこと（壁打ちの流れ）”Q1. subaddressを知らずに使っていると、何を見誤る？
→ + より前がそのまま本体のメールボックスになる。
この「隠されていない」事実を知らずに使うと、過信が事故につながる。
Q2. 「本体アドレスがわかる」だけで実害はあるか？
→ 単発ではほとんどない。
ただし複数サービスで hoge+A@、hoge+B@ と使い分けていると、漏洩データセットをまたいで同一の本体アドレスで名寄せ（相関）される。
どのサービスを使っているかという利用実態が割れる。
Q3. 本来のエイリアス（/etc/aliases）ならこの問題を避けられるか？
→ 避けられる。
エイリアス名を本体と無関係な文字列（例: sushi-chain-alias: hoge）で登録すれば、漏洩しても本体への逆算も名寄せも機械的にはできない。
Q4. それでもなぜ + 記法が使われ続けるのか？
→ コスト構造が違うから。
エイリアス追加にはサーバ管理者権限と設定変更が必要だが、subaddressはユーザーが自分の裁量で即時かつ無制限に使い分けられる。
利便性とセキュリティ特性のトレードオフになっている。
Q5. なぜRFCは + の意味を規格として固定しなかったのか？
→ メールは1980年代から多数の独立実装が相互運用してきたシステムだから。
各実装がすでに思い思いの解釈で動いている前提では、後から中央集権的に意味を固定するコストが高すぎる。
RFC 5321/5322は「ローカルパートの意味づけは受信ホストに委ねる」とし、相互運用性の保証だけに専念した。
規格、慣習、観察記録の三層構造
Section titled “規格、慣習、観察記録の三層構造”この件は一般化すると三つの層に分けてとらえられる。
- 規格：RFC 5321/5322。相互運用のための最低限の取り決めで、ローカルパートの意味づけには関与しない。
- 慣習：PostfixやSendmailなど各MTAによる
+の採用。変更コストの低さから自然発生し、デファクトスタンダードになった。 - 観察記録：RFC 5233。後から「だいたいこうなっている」を言葉にしたもので、強制力はない。
すでに分散して運用が始まったシステムに、後から中央集権的に意味を固定するコストは非常に高い。 この構造はメール以外でも繰り返し現れる。 Web標準とブラウザ実装や、HTTPの非標準拡張ヘッダにも同じパターンが見られる。
残った気づき
Section titled “残った気づき”- 「呼び方の正確さ」は言葉尻の問題ではなく、運用判断（過信のリスク）に直結する。
- この三層のフレームは、別の技術領域を学ぶときのメタ視点として再利用できそうだ。