メールボックス[1](電子メールボックス、[1]、 電子メールボックス、電子メールメールボックス、e-mailboxとも呼ばれる)は、電子メールメッセージが配信される宛先である。郵便システムにおける郵便受けに相当する。
定義
メールボックスは電子メール アドレスによって識別されます。ただし、すべての電子メール アドレスがストレージ ファシリティに対応しているわけではありません。疑似メールボックスという用語は、最終的なメール ストアに対応していないアドレスを指すために使用されることがあります。このようなアドレスから最終受信者に到達するには、電子メール転送を適用できます。電子メール メーリング リストと電子メール エイリアスが典型的な例です。
RFC 5321 [2]では、電子メールアドレスを 、メールの送信先のユーザーまたはメールが保管される場所を識別する文字列として定義しています。メールボックスという用語は、その保管場所を指します。その意味では、メールボックスとアドレスという用語は同じ意味で使用できます。
RFC 5322 では、メールボックスを次のように定義しています: [3] メールボックスはメールを受信します。これは、必ずしもファイルの保存に関係しない「概念的なエンティティ」です。さらに、一部のサイトでは、従来のFAX送信と同様に、プリンターでメールを印刷し、出力を宛先のデスクに届けることを選択する場合があることも例証しています。
アクセス
メールボックスへのアクセスは、メールボックス プロバイダーによって制御されます。通常、メールボックスには誰でもメッセージを送信できますが、認証されたユーザーのみが自分のメールボックスの読み取りや削除を行うことができます。電子メール クライアントは、 1 つ以上のメールボックスからメッセージを取得します。クライアントがメッセージを保存するデータベース (ファイル、ディレクトリ、ストレージ システム) は、ローカル メールボックスと呼ばれます。
読み取りアクセス
メッセージを取得するための 一般的なクライアント サーバープロトコルは次のとおりです。
- Post Office Protocol (POP): 単一のクライアント コンピューターからメッセージを読み取るのに最も適した方法です。通常、メッセージは取得後にサーバー メールボックスから削除されます。いずれにしても、メッセージのマスター コピーはローカル メールボックスにあるものです。
- インターネット メッセージ アクセス プロトコル(IMAP): サーバー メールボックスのリモート管理を可能にして、複数のクライアントからメッセージを取得するように設計されています。マスター コピーはサーバー上に残りますが、コピーはローカルに保存できます。
- HTTP経由のWeb メール: メッセージは、サーバー定義の形式でユーザーのブラウザーに配信されます。マスター コピーはサーバー上に残り、元の形式のままダウンロードできる場合もあります。
IMAP と Web メールは、ほぼシームレスに連携できます。POP は、メッセージをサーバーに残すように設定すれば、これらと互換性があります。
現在 RFC 5322 で定義されているインターネット メッセージ形式は、1982 年 (RFC 822) に遡ります。これは、POP クライアントと IMAP クライアントが取得することを期待しているものです。
書き込みアクセス
メールボックスに送信されたメッセージは、メール配信エージェントによってサーバーのローカル メールボックスに書き込まれます。リモート ユーザーの場合、このローカル メールボックスは、そのサーバー上で所有するリモート メールボックスです。IMAP クライアントは、リモート メールボックス内のメッセージをコピー、移動、および削除できます。
サイズ割り当て
メールボックスにはサイズ制限があり、利用可能なメモリによって暗黙的に決定されるか、メールボックスまたはそのフォルダのクォータ定義に従って決定されます。管理上の些細なことの他に、クォータ制限は電子メール爆弾攻撃を軽減するのに役立ちます。[4]
クォータ用のIMAP拡張機能は1997年に標準化されました。[5]
保存形式
電子メール メッセージの保存には、あらゆる種類のデータベースを使用できます。ただし、標準化により、さまざまなコンピュータ プログラムから特定のメールボックスにアクセスできるように、いくつかのよく知られたファイル形式が生まれました。広く使用されている形式には、次の 2 種類があります。
- mboxはすべてのメッセージを1つのファイルに保存するオリジナルの技術です。
- Maildir は、すべてのメッセージをディレクトリ ツリーに保存し、各メッセージに 1 つのファイルを割り当てる新しい仕様です。
メールボックス名
メールボックス名は、電子メール アドレスの最初の部分で、ローカル部分とも呼ばれ、 @記号の前の部分です。その形式は、RFC 5322 および RFC 5321 で正式に指定されています。多くの場合、これはメール サーバーまたは送信先ドメインの受信者の ユーザー名です。
ローカルパートは最大 64 文字で、理論上は大文字と小文字が区別されます。有効な文字のシーケンス (以下で説明) または引用符で囲まれた文字列のいずれかで構成できます。引用符で囲まれた文字列にはスペースや特殊文字も使用できます。SMTP のSMTPUTF8拡張を使用すると、非 ASCII 文字を使用することもできます。[6] 新しいメールボックス名を作成するときは、よくある落とし穴を避けるために、ある程度の常識が必要です。RFC 5321 の言葉を借りれば、制限を課すことには非常に注意が必要です。
上記のローカル部分の定義は比較的寛容ですが、相互運用性を最大限に高めるために、メールを受信することを想定しているホストは、ローカル部分が引用符付き文字列形式を必要とする(または使用する)メールボックス、またはローカル部分が大文字と小文字を区別するメールボックスの定義を避ける必要があります。
— ジョン・クレンシン、RFC 5321
有効な文字
次の文字は引用符なしでローカル部分に出現できます。
- 大文字と小文字の英語文字(a~z、A~Z)、およびSMTPUTF8 を使用する場合はUTF-8シーケンス
- 数字
0から9 - キャラクター
! # $ % & ' * + - / = ? ^ _ ` { | } ~ - 文字
.(ドット)。ただし、最初または最後の文字ではなく、2 回以上連続して出現しないことが条件です (例: John..Doe@example.com)。
予約名
「postmaster」、「abuse」などの名前はよく知られた役割や機能に対応しており、有効である必要があります。[7]
いくつかの名前は、メールフィルタを含むメールソフトウェア(の一部)の内部で使用されている名前と競合したり、基盤となるストレージシステムがそれらの名前を処理できないために、問題を引き起こすことが知られています。GitHubなど、いくつかのリストが存在します。 [ 8] [9]
参考文献
- ^ ISO/IEC 2382:2015 に準拠
- ^ RFC 5321、シンプルメール転送プロトコル、J. クレンシン、インターネット協会(2008 年 10 月)、セクション 2.3.11(メールボックスとアドレス)
- ^ RFC 5322、インターネットメッセージフォーマット、P. Resnick(編)、インターネット協会(2008年10月)、セクション3.4(アドレス仕様)
- ^ Nick Christenson、Tim Bosserman、David Beckemeyer (1997 年 12 月 9 日)。「オープン システムを使用した拡張性の高い電子メール サービス」。USENIX。2015年12 月 12 日取得。
認証とメールボックスの場所に加えて、メール配信エージェントは、加入者に課すメールボックスのクォータについても認識しています。現在のメールボックスのサイズがそのユーザーのクォータ (既定値は 10 MB) を超えている場合、メッセージは「ユーザー npc、メールボックスがいっぱいです」という理由で MTA に返送されます。加入者によるリソースの乱用を防ぐだけでなく、インターネット上の悪意のある人々によるメール爆撃による損害を軽減するのにも役立ちます。10 MB のクォータは、非常に高品質の回線速度を使用し、ネットワーク ボトルネックのない 28.8 モデムでは、10 MB のメールボックスの内容をダウンロードするのに 1 時間以上かかることを考慮すると、かなり寛大であると考えられます。
- ^ John G. Myers (1997 年 1 月). IMAP4 QUOTA 拡張. IETF . doi : 10.17487/RFC2087 . RFC 2087.
- ^ Jiankang YAO、Wei MAO (2012 年 2 月)。「SMTPUTF8 拡張」。国際化電子メールの SMTP 拡張。IETF。sec . 3.2。doi : 10.17487 /RFC6531。RFC 6531。2015年12月 12日閲覧。
- ^ Dave Crocker (1997 年 5 月). 共通サービス、役割、機能のメールボックス名。IETF . sec. 3,4,5. doi : 10.17487/RFC2142 . RFC 2142. 2015 年12 月 12日閲覧。
- ^ Casey O'Hara (2011). 「リソースパスとのバニティ URL の衝突を回避するための予約済みユーザー名のリスト」。GitHub。2015年12月 12 日閲覧。
- ^ Michael Mahemoff (2011). 「予約済みユーザー名リスト」
