電子メールボックス
電子メールボックス (email box、email mailbox、またはe-mailbox) は、電子メールメッセージの配送先である。郵便システムの郵便受けに相当する。
定義
[編集]メールボックスはメールアドレスによって識別される。ただし、すべてのメールアドレスに保管場所が紐付いているわけではない。pseudo-mailbox (偽メールボックス) という用語は、明確なメール保存場所に紐付いていないアドレスを指すために使われることがある。そのようなアドレスにおける送受信を実現するため、メール転送が使用される場合がある。メーリングリストとメールエイリアスは典型例である。
RFC 5321では、メールアドレスはメールの宛先となるユーザー、またはメールをしまっておく場所を識別する文字列として定義されている。[1] 「メールボックス」という用語は、その保管先を指す。その意味では、「メールボックス」と「アドレス」という用語は、入れ替えて使うことができる。
RFC 5322では、メールボックスは次のように定義されている。「メールボックスはメールを受信する。それは『概念上の存在』であり、必ずしもファイルストレージとは関係がない。」[2] 続けて、サイトによっては従来のファックス伝送のようにメールを印刷して名宛人の机に配達するという選択をし得る例が示されている。
アクセス
[編集]メールボックスへのアクセスは、メールボックスプロバイダーによって制御される。通常、メールボックスへのメッセージ送信は誰でも行えるが、メールボックスでの読み出しまたは削除は権限のあるユーザーにしかできない。メールクライアントは、1つまたは複数のメールボックスからメッセージを取得する。クライアントがメッセージを保存するためのデータベース (ファイル、ディレクトリ、記憶装置) は「ローカルメールボックス」という。
読み取りアクセス
[編集]メッセージ取得用の一般的なクライアントサーバープロトコルには以下のものがある。
- POP: 単一のクライアントコンピュータからのメッセージ読み取りにもっとも適した方法。通常、メッセージは取得された後、サーバーのメールボックスから削除され、ローカルメールボックス内のメッセージがマスターコピーとなる。
- IMAP: サーバーメールボックスの遠隔管理を可能にすることで、複数のクライアントからメッセージを取得することを想定している。マスターコピーはサーバー上に残るが、ローカルにコピーを保存できる。
- HTTP経由のウェブメール: メッセージはサーバー側が定義するフォーマットでユーザーのブラウザーに送られる。マスターコピーはサーバー上に残るが、元々のフォーマットでダウンロードできる場合もある。
IMAPとウェブメールは、ほぼシームレスに共存できる。POPはサーバー上にメッセージを残すように構成しておけば、IMAPおよびウェブメールと同時に利用できる。
現在RFC 5322で定義されているインターネットメッセージフォーマットは、1982年にまで遡る (RFC 822)。POPクライアントとIMAPクライアントは、これを取得することになっている。
書き込みアクセス
[編集]メールボックスに送信されたメッセージは、メール配送エージェントによってサーバーのローカルメールボックスに書き込まれるが、サーバーのローカルメールボックスは、リモートユーザーがそのサーバー上に所有しているリモートメールボックスである。IMAPクライアントは、リモートメールボックス内のメッセージのコピー、移動、そして削除を行うことができる。
サイズクオータ
[編集]メールボックスには、利用可能なメモリ容量によって暗黙に決定される、あるいはメールボックスまたはそのフォルダーに定義されているクオータによって決定される容量制限がある。クオータは管理上のトリビアとしてだけでなく、メールボム攻撃の緩和にも役立つ。[3]
クオータ用のIMAP拡張機能は1997年に標準化された。[4]
保存用フォーマット
[編集]メールメッセージの保存には、任意の種類のデータベースが使用できる。しかし、一定の標準化の結果、様々なコンピュータープログラムで所与のメールボックスにアクセスできる、よく知られたファイルフォーマットがいくつか登場した。広く使われているフォーマットは2種類ある。
メールボックスの名前
[編集]メールボックス名はメールアドレスの最初の部分、つまり@記号より前の部分で、ローカルパート (Local-part) という別名もある。名前のフォーマットはRFC 5322とRFC 5321で正式に仕様化されている。メールボックス名はメールサーバー側、または宛先ドメイン内の受信者のユーザー名であることが多い。
ローカルパートは理論上、最長64文字で、大文字と小文字を区別する (ケースセンシティブ)。また、有効な文字 (下記参照)、または空白と特殊文字を含むことができる引用文字列の連なりで構成される。SMTPUTF8拡張SMTPを用いると、非ASCII文字が使用できる。よくある落とし穴を避けるには、新しいメールボックス名を作る際に常識がいくらか必要になる。RFC 5321の文言では、制約を課すことに非常に慎重である。
上記のローカルパート (Local-part) の定義は比較的寛容だが、相互運用性を最大化するため、メールの受信が想定されるホストではローカルパートに引用文字列 (Quoted-string) 形式が必要となるメールボックスまたはローカルパートがケースセンシティブであるメールボックスの定義はしない方が良い。
有効な文字
[編集]以下の文字は、ローカルパートで引用しなくても良い。
- 英語の大文字と小文字 (a-z、A-Z)、SMTPUTF8を使用している場合はUTF-8シーケンス
-
0から9の数字 ! # $ % & ' * + - / = ? ^ _ ` { | } ~
.(ドット) は最初または最後の文字でなく、かつ2回以上連続して現れない (例: John..Doe@example.comは不可) 場合に限り使用可能。
予約名
[編集]postmaster、abuse、そして他のよく知られた役目と機能に対応する名前は、有効でなければならない[5]。
トラブルを引き起こす名前があることも知られているが、原因はおそらくメールフィルター等のメールソフトウェアが内部で使用している名前と衝突するため、あるいは下層の記憶装置で引っかかってしまうためである。GitHub等に一覧が多数存在している。[6][7][8] 顕著なフィルター事例については、スカンソープ問題を参照のこと。
参考文献
[編集]- ^ RFC 5321, Simple Mail Transfer Protocol, J. Klensin, The Internet Society (October 2008), Section 2.3.11 (Mailbox and Address)
- ^ RFC 5322, Internet Message Format, P. Resnick (Ed.), The Internet Society (October 2008), Section 3.4 (Address Specification)
- ^ “A Highly Scalable Electronic Mail Service Using Open Systems”. USENIX (December 9, 1997). December 12, 2015閲覧。 “In addition to authentication and mailbox location, the mail delivery agent also knows about mailbox quotas which we impose on our subscribers. If the current mailbox size is over the quota for that user, the default being 10 MB, then the message is bounced back to the MTA with reason, "User npc, mailbox full." In addition to preventing resource abuse on the part of subscribers, this also helps mitigate possible damaging effects of mail bombing by malicious people on the Internet. We believe that a 10 MB quota is quite generous, especially considering over a 28.8 modem using very high quality line speeds and no network bottlenecks, one could expect to take over an hour to download the contents of a 10 MB mailbox.”
- ^ John G. Myers (January 1997). IMAP4 QUOTA extension (英語). IETF. doi:10.17487/RFC2087. RFC 2087。
- ^ Dave Crocker (1997). Mailbox names for common services, roles and functions (英語). IETF. sec. 3,4,5. doi:10.17487/RFC2142. RFC 2142. 2015年12月12日閲覧。
- ^ “A list of reserved usernames to avoid vanity URL collision with resource paths” (2011年). December 12, 2015閲覧。
- ^ “Reserved username list” (2011年). December 12, 2015閲覧。
- ^ “reserved-usernames”. December 12, 2015閲覧。