序
メールアドレスの仕様でよくあるものとして、foo@example.comというメールアドレスに対してfoo+1@example.comやfoo+2@example.comといったメールアドレスが文字列上別のメールアドレスでありながら、foo@example.comというメールアドレスとして扱えるという機能があったりする。
(この機能が有効かどうかはメールサービスによって異なる。)
で、この話題になったときにこれを「エイリアス」と呼ぶ人が多かった。 のだが。
絶対に違う。
この機能を「エイリアス」と呼んではならないし、もしこれを「エイリアス」と呼んでいるサービスがあるとしたら、そのドキュメントを作った人にメールに関する知識が足りていない。
これをここまで「エイリアスと呼んではならない」と言う理由は、「メールのエイリアスというのは、明確に別のものにつけられている名前だから」である。
しかも、単にエイリアスという名前がついたものが存在しているだけでなく、「エイリアス」という言葉においてかなり語源に近い存在なのである。 このため、メールアドレスにおいて「エイリアス」という言葉を誤用するのは、他の文脈によるところと比べ事が大きい。
なお、予め明確にしておくが、この「エイリアス」という名称は受け取る側、つまりメールサーバーの話であり、メールクライアントはまた別の機能に「エイリアス」という名称を用いている可能性があり、かつそれは何も問題がない。 例えば、ひとつのメールアカウント設定で複数の差出人情報を設定できる、などだ。
メールアドレスの構造
メールアドレスの構造は、RFC2822に次のように記載されている。
addr-spec = local-part "@" domain仕様ではさらに細かく分解して規定されているが、重要なのはこの部分
The local-part portion is a domain dependent string. In addresses, it is simply interpreted on the particular host as a name of a particular mailbox.
つまり、ドメインパートはインターネット上の配送に使う部分、ローカルパートは受け取ったメールサーバーが扱う部分で、ローカルパートの扱い方は(使用文字の規定はあるが)メールサーバーに完全に任されており、仕様としては何も決まってない。
よって、メールアドレスの形式としては+に関する規定は存在しない。
ちなみに、+を含むメールアドレスの内容はRFC5233において規定されているが、実際のところ「規定」というのとはちょっと違う内容になっている。
aliases
eメールはeメールが規定されるよりも前から、そしてインターネットが誕生するよりも前から存在していたもので、当時UUCPでやりとりされていた。
UUCP(Unix to Unix Copy Protocol)はその名の通りUnixが下地になっているプロトコルである。 そしてメールサーバーもまた、基本的にはUnix上に構築されていた。
eメールの規格がきちんと決まる前は、十分に合意のとれたeメールプロトコル/仕様が存在していなかった。 そんな中で登場したSendmailは、eメールサーバーソフトウェアのデファクトスタンダードとなることでeメールの仕様たろうとし、実際そうなった。
そんなSendmailの設定ファイルとして存在するのが/etc/aliasesである。
このファイルはエイリアスのソースファイルであり、newalias(1)コマンドを用いてDBMファイルにコンパイルされる。
そして作られたDBMファイルがメールエイリアスとして機能する。
メールエイリアスは、基本的には
name: addrという構造をしている。
このnameはそのUnixシステムのユーザーである。
そして、name宛のメールはaddrに展開される。
このaddrはユーザー名以外に展開することもできるし、そもそもこの部分にaddr以外を指定することも可能なのだが、話が複雑化してしまうので、とりあえずこのaddrは別のシステムユーザー名であると考えて良い。
Sendmailにはaddrはgetpwnam(3)によって取得可能である(つまり有効なシステムユーザー名である)という制約がある。
現在のPostfixにはこの制約はなく、架空のユーザーを指定しても構わない。
つまり、これは「ユーザーXに送られたメールはユーザーYに転送する」という機能である。
なぜこのような機能が必要か。 これは主に、システム上のユーザー宛のメールを実ユーザーが受け取るためである。
古典的Unixシステムでは、なにか問題が起きたときにメールを送信する。 このメールはローカルパートしかない宛先を持っており、つまり外には送信せずそのホストの内部で処理される。 そしてだいたいその宛先は、そのソフトウェアが動作しているユーザーである。
このため、ウェブサーバーになにか問題があったとしたら、httpユーザー、あるいはwwwユーザーに対してメールを送信するというイメージだ。
だが、それはシステム的なユーザーであり、httpユーザーやwwwユーザーとしてログインすることはない。結果的に、問題があってメールを送信されたとしても実際に確認する機会がない。
そこで、/etc/aliasesに
http: johnのように書いておけば、実際にウェブサーバーの面倒を見ているjohnがメールを受け取ることになる、という仕組みだ。
発展的に言えば、インターネットでメールを受け取るメールサーバー視点だと
foo: john
bar: johnという設定をしておくことで、john@example.comだけでなく、foo@example.comやbar@example.comも有効なアドレスとして使うことができる。
同様の機能として.forwardという機能もあり、これは~/.forwardというユーザー自身のファイルとして書く。
これもおよそaliasesと同じように動作し、ユーザーが自分宛のメールを別ユーザーに転送できる。
これは、システムに複数のアカウントを持っているユーザーにとって、まとめられるという意味で便利だ。
aliasesは誰が扱うのか
aliases(5)はMDAによって扱われる。
SendmailはSendmailの一部だが、Postfixの場合はlocal(8)である。
local(8)は古典的なように、メールアドレスをシステムのユーザーとして扱う。
「自分(サーバー)宛メールアドレス」の識別はmydestinationによって判別する。
もしそのPostfixサーバーが
mydestination = example.com, example.netとしていたとしたら、foo@example.comとfoo@example.netはどちらもfooユーザー宛メールとして扱われる。
local(8)はドメインパートによって処理を分けることをしない。
これに対して、複数のドメインを個別に扱えるのがvirtual(8)である。
virtualは仮想マルチドメインのための……と言われることが多いが、実際のところvirtualの機能自体はシステムユーザーとメールユーザーを分離するためのものだと言って良い。
aliases(5)を扱うのはlocal(8)であるため、virtual(8)を使う宛先、つまりはvirtual_mailbox_domainsで設定されているドメインに対しては機能しない。
virtual(8)はvirtual(8)で、virtual_alias_mapsで設定されたファイルをaliases(5)と同じようなものとして扱う機能を持っているが、これは/etc/aliasesとは別物であり、あくまでvirtual(8)用の設定ファイルである。
ただ、Postfixにとっては「virtual(8)用のaliases」という扱いなので、virtual_alias_mapsに設定されているファイルによって設定されている宛先置き換えの機能も「エイリアス」と呼んでいる。
ただ、これはUnixシステム的な名称というより、メールサーバーソフトウェアであるPostfixの名称であると考えて良い。
/etc/aliasesはメールサーバーソフトウェアが扱う設定ファイルではあるが、Unixシステムの設定ファイルの一部であると考えられる場合が多い。
Systemd環境の大抵のLinuxシステムではそもそもシステムメールというものを使う機会がほとんどないため空気だし、メールサーバーを運営しない限り(~/.forwardを含め)扱うことはほとんどないものになっているが。
また、aliases(5)を扱うのがMDA(Postfixではlocal(8))である以上、Postfixであってもlocal(8)を使わないようにしている場合は無視されることもある。
例えばaltpostlocalはlocal(8)を置き換えるものであり、なおかつ/etc/aliases相当の機能を大幅に拡張することを目的としたものであるため、aliases(5)を見ない。
プラスの正体
さて、ではfoo+abc@example.comのようなメールアドレスで使われる+はエイリアスでなければ何なのかというと、PostfixではExtensionと呼ばれている。
The recipient_delimiter parameter specifies the separator between user names and address extensions (user+foo).
この解釈はcanonical(5)のManpageに記載がある。
When a mail address localpart contains the optional recipient delimiter (e.g., user+foo@domain), the lookup order becomes: user+foo@domain, user@domain, user+foo, user, and @domain.
The
propagate_unmatched_extensionsparameter controls whether an unmatched address extension (+foo) is propagated to the result of table lookup.
これの設定自体はmain.cfでrecipient_delimiterという項目で存在する。
これのデフォルトが
recipient_delimiter = +となっており、+以降が拡張アドレス(ADDRESS EXTENSION)として扱われる。
Eximの場合はlocal_part_suffixという設定を用いる。
これはPostfixよりは柔軟な設定が可能で、デフォルト設定が
local_part_suffix = +* : -*であるため、Eximの場合はデフォルトで+だけでなく-以降も拡張アドレスとして扱うようになっている。
Sendmailはもっと複雑に+を特別扱いする。
かつてのデファクトスタンダードであるSendmailは+を特別扱いする仕様だし、現在最も一般的なPostfixも+がrecipient_delimiterのデフォルトだから、「一般的な挙動」として+以降が拡張アドレスになる。
この+以降の部分をRFC5233では:detailとして定義しているが、用語として定義されているものではない。
例えばfoo@example.comに対するfoo+abc@example.comはsubaddressとして定義されている。
RFC5233などはこの「一般的な機能」を解説しようとがんばっているのだが、そもそもRFC2822が言うように「ローカルパートはドメイン(サーバー)次第」であるため、「それはこういうものです」という言い方はしようがない。
結局+は拡張アドレスに一般的に使われる文字であるということでしかないのだ。
例えばPostfixで
recipient_delimiter = -というふうにしたら、foo@example.comとfoo-abc@example.comが同じアドレスとみなされるようになり、foo+abc@example.comは別のアドレスとして扱われるようになる。
ちなみに、/etc/aliasesのユーザーパートに+を含めることはできるため、
foo+abc: fooみたいに書いておくと「拡張アドレスではなくエイリアスによって」メールアドレスを実質同一として扱うことができるようになる。
+がサブアドレスを構成するために使われることが多いことから、サブアドレスを登録することを嫌う(つまり、「お前のアカウントとして使われているメールアドレスを登録しろ」という意味で)サービスが+をローカルパートに含めさせないようなことが結構よくある。
が、これは+がサブアドレスのためではなく、純粋にローカルパート構成要素になっている場合に困るからサービスがやっていることとしてはだいぶ不適切であり、ユーザー側からするとそのようなメールサービスにおいてローカルパートに+を含むアカウントを作ると困る場合があるから避けたほうが良い。
自分が運営しているメールサーバーで受け取るのであれば、デリミタをより一般的な記号(例えば-や_)に変更することで、このようなサブアドレスを拒否するサービスの問題を解消することができる。
Eximの場合はより複雑なパターンを用いることが可能なので、サブアドレスかどうかを推測させづらくなることも可能だ。
AltPostLocalはデリミタを正規表現で指定できるためPostfixよりは柔軟に設定可能だが、Eximのように「サブアドレス構成要素のほうが手前にある」みたいな作りにすることはできない。
まとめ
- eメールアドレスにおいて「エイリアス」と言った場合、基本的に(
/etc/aliasesを用いた)MDAが扱う機能を指す - このエイリアスはUnixシステムの構成要素の一部である
+はサブアドレスを表現する上で一般的に用いられる記号である+が一般的なのは、各種eメールサーバー実装のデフォルト設定で使われているためである+を用いてアカウントとは異なるメールアドレスを構成するものは「サブアドレス」と呼ばれている+自体の正式な名称はないが、+などを含む付加要素は「拡張アドレス」と呼ばれることが多い