hoge+fuga@example.com は「エイリアス」ではない
はじめに
先日、このような投稿を見かけました。
メールサーバをセルフホストして、サービスごとに別々のアドレスを割り当てている方のところに、とあるお寿司チェーンにしか教えていないはずのアドレス宛にフィッシングメールが届いたそうです。おかげで、どこから漏れたのかが一発でわかった、という話でした。アドレスの出どころを切り分けられる運用自体はすごく良いと思います。
問題はそのあとです。反応には「Gmailのエイリアスを使えばいい」という声が並び、投稿主ご本人も「厳密にはCatch-Allではなくエイリアスで運用している、区切り文字をピリオドにしているので弾かれにくい」と補足していました。
このエイリアスという一語が、私にはどうしても飲み込めません。
hoge@example.comに対してhoge+fuga@example.comやhoge+spam@example.comを使い分ける。文字列の上では別物ですが、届く先は同じhoge@example.comになる。多くのメールプロバイダにあるこの挙動を「エイリアス」と呼んでいる人を、私はちょくちょく見かけます。そのたびに、違うんだよなあ、と思い、内心では冷笑しています。
初めに言っておくと、これは明確な誤りです。この機能をエイリアスと呼んではなりません。もしこう書いている人(組織)がいたら、メールまわりの理解が明らかに不足しているので、一度お勉強し直してきてほしいところです。
先に断っておくと、これから「エイリアスではない」と何度も言いますが、対象はあくまで受信側、つまりメールサーバの挙動の話であって、メールクライアントに存在している機能の話はしていません。
メールアドレスの構造
アドレスの形式は、RFC 5322(RFC 2822を引き継いだもの)に定義があります。骨格だけ抜き出すとこうです。
addr-spec = local-part "@" domain
仕様ではもっと細かく分解されていますが、肝心なのはここです。@の右側、domain部は、広義のインターネット上で、メッセージをどのサーバへ運ぶかを決める部分とし、@の左側であるlocal-partは、そのサーバに届いてから、そのサーバが自分の流儀で解釈する文字列でしかありません。RFC 5321/5322が言っているのも結局これで、local-partはドメイン(=受信ホスト)に依存する文字列であって、受け取ったホストが特定のメールボックスを指す名前として解釈する、という以上のことは決めていない。文法上の縛りこそありますが、中身の意味づけは丸ごとサーバ側に任されています。
アドレスの形式という観点では、+に特別な規定なんてものはなく、+がlocal-partの中でどう扱われるかは、受信サーバの設定次第でしかないのです。
+を含むアドレスについてはRFC 5233も触れていますが、これは形式を規定したものではなく、Sieveのフィルタリングでsubaddressを扱うためのtestを定義するついでに、世間でよくある慣習を後から言葉にしたものに近いです。決まりというより観察記録だと思ったほうがいいでしょう。
なお、本来の意味でのエイリアスはSendmail由来の/etc/aliasesを指します。が、これは話が逸れるので後で触れます。
+の呼ばれ方
エイリアスでないなら何なのか。実装ごとに名前が異なります。Postfixではaddress extension(拡張アドレス)と呼び、ユーザー名と拡張部分を区切る文字はrecipient_delimiterで設定できます。
マッチしなかった拡張部分(+foo)を結果に引き継ぐかどうかも、同じくPostfixのpropagate_unmatched_extensionsで制御できます。Eximのほうはlocal_part_suffixを使い、配布される標準設定だと+* : -*のようになっていて、+だけでなく-以降も拡張部分として扱われることが多いようです。
Sendmailはもっと込み入った形で+を特別扱いしますが、どの実装でも+以降が拡張部分になるという結果は変わりません。
昔はSendmailが、いまはPostfixが、+をデフォルトの区切りとしているので、だいたいの環境では+以降が拡張部分になる、という共通の感覚ができあがっただけのことかと思います。
subaddress
RFC 5233はそもそもメールアドレスの規格ではありません。Sieveでフィルタを書くときに、+から後ろは無視して本体だけ見たい、といった操作をやれるようにするための拡張です。
そのためにlocal-partをUserとDetailに割って眺め、両者の継ぎ目をseparator character sequenceと名づけています。foo+abc@example.comならfooがUser、abcがDetail(Sieveでは:detailで取り出せます)、全体がsubaddress、という具合ですね。
separator character sequenceと言われると、区切りがきっちり定義されていて構造もそのとおりに割れる、という規格上の取り決めがあるように聞こえますが、中身はそんなに立派なものではありません。RFC 5233が言っているのは、せいぜいuser+detailの形で届いたメールをuser本体に結びつけて扱える、という程度のことです。区切りにどの文字を当てるか、そもそもこの分解をやるのかどうかは、頭から終わりまで受信側の実装に任されています。
裏を返せば、これは+の意味を定めた条文ではなく、local-partをどう解釈するかは受け手のソフトウェア次第、というのがRFC 5321/5322の立場で、RFC 5233はそこに何も足していません。
local-partが必ずしもUserそのものと一致しないという形を一例として挙げ、すでに広まっている習慣をSieveから触れるように後から言葉にした、それだけです。
故に、RFCにこう書いてあるから、を盾に+の素性を断じることはできません。言えるのはひとつ、+は拡張アドレスの区切りとして広く使われている文字だ、ということに尽きます。
呼ぶなら、実装に寄せて拡張アドレス、概念に寄せてsubaddressとするのが妥当でしょう。どう間違ってもエイリアスではありません。
エイリアスとの違い
そもそもの話、メールでいうエイリアスは既に別の機能として存在しています。
Sendmailの/etc/aliasesを思い出してください。あそこに書くhoge: taro, jiro, hanakoのような行は、hoge宛のメールをtaroとjiro, hanakoに転送する、という対応づけをひとつ定義しています。エイリアスというのは、こういう明示的に張った別名のことです。
subaddressのほうは、別名を一個ずつ定義しているわけではありません。separator character sequenceより後ろを機械的に切り落として、元のメールボックスに合流させているだけ。無限に湧いてくるfoo+hoge@example.comのどれもが、事前登録なしにfoo@example.comへ落ちます。そもそもが別物です。
面白いことに、この二つは混ぜることもできます。/etc/aliasesのuser部には+を書けるので、
hoge+fuga: foo
としておけば、拡張アドレスの仕組みではなくエイリアスとしてhoge+fugaをfooと同じに扱えます。同じ宛先に着地しても、通ってきた経路はまったくの別物であり、両者が別物だというのがわかるかと思います。
ところで、+を弾くサービスのこと
+がsubaddressに使われがちだという理由で、local-partに+を含むアドレスの登録を拒むサービスがそこそこあります。アカウントの本物のアドレスを出せ、というわけですね。気持ちは分からなくもないのですが、対応としてはかなり杜撰だと思います。
+はsubaddress専用の記号でもなんでもなく、ただlocal-partの一文字として使われているだけ、ということも普通にあるわけで。
もっとも、自分でメールサーバを持っているなら、こんなものは区切り文字を+から-や_に振り替えてやれば片付く話です。冒頭の投稿主がピリオドを使っていたのも同じ発想で、.なんてlocal-partにいくらでも出てくる字ですから、まず弾かれようがありません。とはいえ、こういう回避テクを並べたくてこれを書いているわけではないんですよね。
私がこれを書いている理由は、最初から最後までひとつです。
subaddressをエイリアスと呼ぶべきではない。
人に勧めたり、知識として披露したりするのなら、まずは正しく理解しておくべきですし、わかってもいないのに得意げに広めるのは傲慢でしかありません。もっとも、人は間違えるものですから、誤解そのものを責めるつもりはありません。少なからず恥じるべきだとは思いますが。
今後、これをエイリアスとは呼ばないように気をつけていきましょう。
知識を正しくアップデートしていくきっかけになれば幸いです。
Discussion
エイリアスという言葉の正しい定義はさておき、
Gmail公式でその手法を[Gmailエイリアス]と呼称しているので
サービスユーザー視点では特に間違ってはいねーのです。
ありがとうございます、たしかに公式でそう呼ばれていますね。
少しだけ補足させてください。
本エントリで取り上げたのはGmailのユーザではなく、自分でメールサーバを建てて運用している方の例でして。「区切り文字をピリオドにしている」とご本人がおっしゃっている時点で、これはGmailの機能ではなく、その方自身のサーバ上のsubaddressingです。なので「Gmail公式がそう呼んでいる」というお話とは、少しレイヤが違うのかなと思っています。
Gmail公式の呼称についても言及しておくと、あのヘルプではSend mail asの送信用アドレスやWorkspaceの(順当な)エイリアス, +表記まで含め、仕組みの違うものを全部エイリアスでまとめてしまっていて、正直かなり雑で不適切な表現をしているように思えます。ですので、公式の語をそのまま借りているユーザを責める意図はなかったのですが、あれを根拠に「であるから正しい」とまでは言うのは違うのではないかと考えています。
Plus AddressingはExchange Onlineにも存在するのですが、こちらではPlus Addressingはsubaddressingであり、メールボックスに構成されているエイリアスではないと明確に記載されています。
RFCに基づき執筆されたExplained from First PrinciplesのEmailにおいても、subaddressingとalias addressは明確に区別されています。
GoogleでググったらGmailに関する情報がトップに出てくるのは至極当然であり、皆さん一種のフィルターバブルに陥っているように思えます。
他人のミスに対しては求められてもいない投稿をするほど厳しいのに、いざ自分のミスを指摘されると決して間違いを認めることもなく言い訳を続ける人間はどこにいても見るに堪えないな、と再確認できる良い記事でした👍