Network Working Group E. Hall
Request for Comments: 4155 September 2005
Category: Informational
The application/mbox Media Type
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This memo requests that the application/mbox media type be authorized for allocation by the IESG, according to the terms specified in RFC 2048. This memo also defines a default format for the mbox database, which must be supported by all conformant implementations.
このメモは、アプリケーション/ MBOXメディアタイプがこのメモは、すべての準拠実装によってサポートされなければならないMBOXデータベースのデフォルトフォーマットを定義するRFC 2048に指定された条件に従って、IESGによって割り当てのために認可されることを要求します。
UNIX-like operating systems have historically made widespread use of "mbox" database files for a variety of local email purposes. In the common case, mbox files store linear sequences of one or more electronic mail messages, with local email clients treating the database as a logical folder of email messages. mbox databases are also used by a variety of other messaging tools, such as mailing list management programs, archiving and filtering utilities, messaging servers, and other related applications. In recent years, mbox databases have also become common on a large number of non-UNIX computing platforms, for similar kinds of purposes.
UNIX系オペレーティングシステムは、歴史的にローカル電子メール、様々な目的のために、「mbox形式」のデータベースファイルの普及を行っています。一般的なケースでは、mbox形式のファイルは、ローカルの電子メールクライアントは、電子メールメッセージの論理的なフォルダとしてデータベースを処理すると、1つまたは複数の電子メールメッセージの線形シーケンスを記憶します。 mbox形式のデータベースはまた、メーリングリスト管理プログラム、アーカイブおよびフィルタリングユーティリティ、メッセージングサーバー、およびその他の関連するアプリケーションなどの他のメッセージングツール、様々な方法で使用されています。近年では、mbox形式のデータベースも目的の似た種類の、非UNIXのコンピューティング・プラットフォームの大規模な数に一般的になっています。
The increased pervasiveness of these files has led to an increased demand for a standardized, network-wide interchange of these files as discrete database objects. In turn, this dictates a need for a general media type definition for mbox files, which is the subject and purpose of this memo.
これらのファイルの増加普及は、個別のデータベースオブジェクトとしてこれらのファイルの標準化、ネットワーク全体の交換のための需要の増加につながっています。ターンでは、これは、このメモの主題と目的であるmbox形式のファイルのための一般的なメディアタイプの定義の必要性を指示します。
The mbox database format is not documented in an authoritative specification, but instead exists as a well-known output format that is anecdotally documented, or which is only authoritatively documented for a specific platform or tool.
MBOXデータベースフォーマットは権威明細書に記載され、その代わり逸話記載され、又はのみ正式特定のプラットフォームまたはツールのために文書化されているよく知られた出力形式として存在していません。
mbox databases typically contain a linear sequence of electronic mail messages. Each message begins with a separator line that identifies the message sender, and also identifies the date and time at which the message was received by the final recipient (either the last-hop system in the transfer path, or the system which serves as the recipient's mailstore). Each message is typically terminated by an empty line. The end of the database is usually recognized by either the absence of any additional data, or by the presence of an explicit end-of-file marker.
mbox形式のデータベースは、典型的には、電子メールメッセージの線形配列を含みます。各メッセージは、メッセージの送信者を識別する区切り線で始まり、そして、メッセージが転送経路の最後の受信者（いずれかの最終ホップシステム、または受信者として機能するシステムによって受信された日付と時刻を特定しますメールストア）。各メッセージは通常、空行で終了します。データベースの最後には、通常、任意の追加データが存在しない場合、または明示的なファイル終了マーカーの存在のいずれかによって認識されています。
The structure of the separator lines vary across implementations, but usually contain the exact character sequence of "From", followed by a single Space character (0x20), an email address of some kind, another Space character, a timestamp sequence of some kind, and an end-of-line marker. However, due to the lack of any authoritative specification, each of these attributes are known to vary widely across implementations. For example, the email address can reflect any addressing syntax that has ever been used on any messaging system in all of history (specifically including address forms that are not compatible with Internet messages, as defined by RFC 2822 [RFC2822]). Similarly, the timestamp sequences can also vary according to system output, while the end-of-line sequences will often reflect platform-specific requirements. Different data formats can even appear within a single database as a result of multiple mbox files being concatenated together, or because a single file was accessed by multiple messaging clients, each of which has used its own syntax for the separator line.
区切り線の構造は、単一の空白文字（0x20に）、いくつかの種類の電子メールアドレス、別のスペース文字、いくつかの種類のタイムスタンプ・シーケンス、続いて、実装ごとに異なるが、通常の「From」の正確な文字列を含みます、行末マーカー。しかし、任意の正式な仕様の欠如に起因し、これらの属性のそれぞれは、実装を横切って広く変化することが知られています。例えば、電子メール・アドレスは、（特にRFC 2822 [RFC2822]で定義されているインターネットメッセージと互換性がありませんアドレス形式を含む）これまでの歴史のすべてで任意のメッセージングシステム上で使用されている任意のアドレス指定の構文を反映することができます。行末配列はしばしば、プラットフォーム固有の要件を反映しながら、同様に、タイムスタンプの配列はまた、システムの出力に応じて変えることができます。異なるデータフォーマットであっても、複数のMBOXファイルが一緒に連結された結果として、単一のデータベース内に表示することができ、または単一のファイルが区切り線のための独自の構文を使用しているそれぞれが複数のメッセージングクライアントによってアクセスされたからです。
Message data within mbox databases often reflects site-specific peculiarities. For example, it is entirely possible for the message body or headers in an mbox database to contain untagged eight-bit character data that implicitly reflects a site-specific default language or locale, or that reflects local defaults for timestamps and email addresses; none of this data is widely portable beyond the local scope. Similarly, message data can also contain unencoded eight-bit binary data, or can use encoding formats that represent a specific platform (e.g., BINHEX or UUENCODE sequences).
mbox形式のデータベース内のメッセージデータは、多くの場合、サイト固有の特殊性を反映しています。例えば、それは暗黙のうちに、サイト固有のデフォルトの言語またはロケールを反映したタグなし8ビットの文字データを格納するのmboxデータベース内のメッセージ本文やヘッダのための完全に可能である、またはそれは、タイムスタンプと電子メールアドレスのローカルのデフォルト値を反映しています。このデータのどれも地元の範囲を超えて広く移植性がありません。同様に、メッセージデータも符号化されていない8ビットバイナリデータを含むことができ、または特定のプラットフォーム（例えば、BINHEXまたはUUENCODEの配列）を表す符号化フォーマットを使用することができます。
Many implementations are also known to escape message body lines that begin with the character sequence of "From ", so as to prevent confusion with overly-liberal parsers that do not search for full separator lines. In the common case, a leading Greater-Than symbol (0x3E) is used for this purpose (with "From " becoming ">From "). However, other implementations are known not to escape such lines unless they are immediately preceded by a blank line or if they also appear to contain an email address and a timestamp. Other implementations are also known to perform secondary escapes against these lines if they are already escaped or quoted, while others ignore these mechanisms altogether.
多くの実装では、完全な区切り線を検索しません過度に自由主義のパーサーとの混同を防止するために、「から」の文字列で始まるメッセージのボディラインを脱出することが知られています。一般的なケースでは、主要な大なり記号（0x3E）は、（「から>」になってきて「から」と）、この目的のために使用されます。彼らはすぐに空白行が先行されていない限り、または、彼らはまた、電子メールアドレスとタイムスタンプが含まれているように見える場合は、他の実装は、そのような行をエスケープしないことが知られています。他の人は完全にこれらのメカニズムを無視しながら、他の実装も、彼らはすでにエスケープまたは引用されている場合は、これらの線に対する二次エスケープを行うことが知られています。
A comprehensive description of mbox database files on UNIX-like systems can be found at http://qmail.org./man/man5/mbox.html, which should be treated as mostly authoritative for those variations that are otherwise only documented in anecdotal form. However, readers are advised that many other platforms and tools make use of mbox databases, and that there are many more potential variations that can be encountered in the wild.
UNIX系システムでMBOXデータベースファイルの包括的な説明は、そうでなければのみ逸話に記載されるもののバリエーションを主に権威として扱われるべき、http://qmail.org./man/man5/mbox.htmlで見つけることができ形。しかし、読者は他の多くのプラットフォームやツールが野生で遭遇することができ、より多くの潜在的なばらつきがあるmbox形式のデータベースの使用、およびことを確認することをお勧めします。
In order to mitigate errors that may arise from such vagaries, this specification defines a "format" parameter to the application/mbox media type declaration, which can be used to identify the specific kind of mbox database that is being transferred. Furthermore, this specification defines a "default" database format which MUST be supported by implementations that claim to be compliant with this specification, and which is to be used as the implicit format for undeclared application/mbox data objects. Additional format types are to be defined in subsequent specifications. Messaging systems that receive an mbox database with an unknown format parameter value SHOULD treat the data as an opaque binary object, as if the data had been declared as application/octet-stream
このような気まぐれから生じ得る誤差を軽減するために、本明細書が転送されてMBOXデータベースの特定の種類を識別するために使用することができるアプリケーション/ MBOXメディアタイプ宣言は、「形式」パラメータを定義します。さらに、本明細書は、この仕様に準拠する請求実装によってサポートされなければならない「デフォルト」のデータベース・フォーマットを定義し、その宣言されていないアプリケーション/ MBOXデータオブジェクトの暗黙的なフォーマットとして使用されます。追加のフォーマットタイプは、その後の仕様で定義されるべきです。データは、アプリケーション/オクテットストリームとして宣言されていたかのように、未知の形式のパラメータ値とmbox形式のデータベースを受けるメッセージングシステムは、不透明なバイナリオブジェクトとしてデータを扱うべきです
Refer to Appendix A for a description of the default mbox format.
デフォルトのmbox形式の説明については、付録Aを参照してください。
Note that RFC 2046 [RFC2046] defines the multipart/digest media type for transferring platform-independent message files. Because that specification defines a set of neutral and strict formatting rules, the multipart/digest media type already facilitates highly-predictable transfer and conversion operations; as such, implementers are strongly encouraged to support and use that media type where possible.
/そのRFC 2046 [RFC2046]はマルチパートを定義注プラットフォームに依存しないメッセージファイルを転送するためのメディアタイプを消化します。その仕様は、中性及び厳格なフォーマット規則のセットを定義するため、マルチパート/ダイジェストメディアタイプは、すでに高度に予測可能な転送および変換動作を容易にします。など、実装者は強く、可能な場合は、そのメディアタイプをサポートして使用することをお勧めします。
Readers of this document are expected to be familiar with the specification for MIME [RFC2045] and MIME-type registrations [RFC2048].
この文書の読者は、MIME [RFC2045]とMIMEタイプの登録[RFC2048]の仕様に精通していることが期待されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
This section provides the media type registration application (as per [RFC2048]).
このセクションでは、（[RFC2048]に従って）メディアタイプ登録アプリケーションを提供します。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: mbox
MIMEサブタイプ名：MBOX
Required parameters: none
必須パラメータ：なし
Optional parameters: The "format" parameter identifies the format of the mbox database and the messages contained therein. The default value for the "format" parameter is "default", and refers to the formatting rules defined in Appendix A of this memo. mbox databases that do not have a "format" parameter SHOULD be interpreted as having the implicit "format" value of "default". mbox databases that have an unknown value for the "format" parameter SHOULD be treated as opaque data objects, as if the media type had been specified as application/octet-stream. Additional values for the format parameter are to be defined in subsequent specifications, and registered with IANA.
オプションのパラメータ：「形式」パラメータはMBOXデータベースとそこに含まれるメッセージのフォーマットを識別する。 「形式」パラメータのデフォルト値は、「デフォルト」であり、このメモの付録Aで定義されたフォーマットルールを指します。 「フォーマット」のパラメータを持っていないのmboxデータベースは、「デフォルト」の暗黙の「形式」の値を持つものとして解釈されるべきです。メディアタイプは、アプリケーション/オクテットストリームとして指定されていたかのように「フォーマット」パラメータの未知の値を持っているのmboxデータベースは、不透明なデータオブジェクトとして扱われるべきです。フォーマットパラメータの追加の値は、後続の仕様で定義され、IANAに登録されます。
Encoding considerations: If an email client receives an mbox database as a message attachment, and then stores that attachment within a local mbox database, the contents of the two database files may become irreversibly intermingled, such that both databases are rendered unrecognizable. In order to avoid these collisions, messaging systems that support this specification MUST encode an mbox database (or at a minimum, the separator lines) with non-transparent transfer encoding (such as BASE64 or Quoted-Printable) whenever an application/mbox object is transferred via messaging protocols. Other transfer services are generally encouraged to adopt similar encoding strategies in order to allow for any subsequent retransmission that might occur, but this is not a requirement. Implementers should also be prepared to encode mbox data locally if non-compliant data is received.
エンコーディングの考慮事項：電子メールクライアントは、メッセージの添付ファイルとしてmbox形式のデータベースを受信し、ローカルのmboxデータベース内でその添付ファイルを保存する場合は、2つのデータベースファイルの内容は、不可逆的に、両方のデータベースが認識できないレンダリングされるように、混ざりなることがあります。アプリケーション/ MBOXオブジェクトがあるときはいつでも、これらの衝突を回避するために、この仕様をサポートするメッセージングシステムは、（例えばBASE64またはquoted-printableのような）非透過転送エンコーディングでMBOXデータベース（または最小で、区切り線）をコードしなければなりませんメッセージングプロトコルを介して転送。他の転送サービスは、一般的に発生する可能性のある、後続の再送信を可能にするために、類似した符号化戦略を採用することを奨励しますが、これは必須ではありませんされています。実装は、非準拠データを受信した場合、ローカルにMBOXデータを符号化するために用意されなければなりません。
Security considerations: mbox data is passive, and does not generally represent a unique or new security threat. However, there is risk in sharing any kind of data, because unintentional information may be exposed, and this risk certainly applies to mbox data as well.
セキュリティの考慮事項：mbox形式のデータは、受動的であり、一般にユニークな、または新しいセキュリティ上の脅威を表すものではありません。意図しない情報が露出することができるので、しかし、あらゆる種類のデータを共有することでリスクは、そこにあり、このリスクは確かに同様のmboxデータに適用されます。
Interoperability considerations: Due to the lack of a single authoritative specification for mbox databases, there are a large number of variations between database formats (refer to the introduction text for common examples), and it is expected that non-conformant data will be erroneously tagged or exchanged. Although the "default" format specified in this memo does not allow for these kinds of vagaries, prior negotiation or agreement between humans may sometimes be needed.
相互運用性の考慮事項：MBOXデータベースの単一権限の指定がないために、データベース・フォーマット間の変動が多数あるDUE（一般的な例のために導入テキストを参照）、非準拠データが誤ってタグ付けされることが期待されますまたは交換しました。このメモで指定された「デフォルト」の形式は人間の間気まぐれ、事前交渉や契約のこれらの種類のために許可されていませんが、時には必要になる場合があります。
Published specification: see Appendix A.
公開された仕様：付録Aを参照してください。
Applications that use this media type: hundreds of messaging products make use of the mbox database format, in one form or another.
このメディアタイプを使用するアプリケーション：メッセージング製品の何百ものは、一つの形態または別で、mbox形式のデータベース形式を使用しています。
Magic number(s): mbox database files can be recognized by having a leading character sequence of "From", followed by a single Space character (0x20), followed by additional printable character data (refer to the description in Appendix A for details). However, implementers are cautioned that all such files will not be compliant with all of the formatting rules, therefore implementers should treat these files with an appropriate amount of circumspection.
マジックナンバー（S）：mbox形式のデータベースファイルには、追加印刷可能な文字データに続いて、単一の空白文字（0x20の）に続いて、「から」の先頭の文字列を持つことによって認識することができます（詳細については、付録Aで説明を参照してください） 。しかし、実装者は、そのようなすべてのファイルが実装はcircumspectionの適切な量でこれらのファイルを扱う必要がありますので、フォーマット規則のすべてに準拠していないだろうと警告しています。
File extension(s): mbox database files sometimes have an ".mbox" extension, but this is not required nor expected. As with magic numbers, implementers should avoid reflexive assumptions about the contents of such files.
ファイルの拡張子（S）：mbox形式のデータベースファイルは、時々「.mbox」の拡張子を持っていますが、これは必要でも期待されていません。マジックナンバーと同じように、実装者は、このようなファイルの内容について反射的な仮定を避ける必要があります。
Macintosh File Type Code(s): None are known to be common.
Macintoshのファイルタイプコード（S）：なし、共通であることが知られています。
Person & email address to contact for further information: Eric A. Hall (ehall@ntrg.com)
人と詳細のために連絡する電子メールアドレス：エリック・A.・ホール（ehall@ntrg.com）
Intended usage: COMMON
意図している用法：COMMON
See the discussion in section 4.
セクション4での議論を参照してください。
The IANA has registered the application/mbox media type in the MIME registry, using the application provided in section 4 above.
IANAは、上記のセクション4に設けられたアプリケーションを使用して、MIMEレジストリのアプリケーション/ MBOXメディアタイプが登録されています。
Furthermore, IANA has established and will maintain a registry of values for the "format" parameter as described in this memo. The first registration is the "default" value, using the description provided in Appendix A. Subsequent values for the "format" parameter MUST be accompanied by some form of recognizable, complete, and legitimate specification, such as an IESG-approved specification, or some kind of authoritative vendor documentation.
また、IANAが確立しており、このメモに記載されているように、「形式」パラメータの値のレジストリを維持します。最初の登録は、IESG承認書、又は、認識可能な完全な、そして正当な仕様、いくつかの形態を添付しなければならない「形式」パラメータについては、付録A.後続値で提供される説明を用いて、「デフォルト」の値であります正式なベンダーのドキュメントのいくつかの種類。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[RFC2048]解放され、N.、Klensin、J.、およびJ.ポステル、 "多目的インターネットメール拡張（MIME）第四部：登録手順"、BCP 13、RFC 2048、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
Appendix A. The "default" mbox Database Format
「デフォルト」のmboxデータベース形式付録A.
In order to improve interoperability among messaging systems, this memo defines a "default" mbox database format, which MUST be supported by all implementations that claim to be compliant with this specification.
メッセージングシステム間の相互運用性を向上させるために、このメモは、この仕様に準拠すると主張するすべての実装によってサポートされなければならない「デフォルト」MBOXデータベース・フォーマットを定義します。
The "default" mbox database format uses a linear sequence of Internet messages, with each message being immediately prefaced by a separator line, and being terminated by an empty line. More specifically:
「デフォルト」のmboxデータベースフォーマットは、各メッセージが直ちに分離ラインによって前置きされ、空行で終了されると、インターネットメッセージの線形配列を使用します。すなわち：
o Each message within the database MUST follow the syntax and formatting rules defined in RFC 2822 [RFC2822] and its related specifications, with the exception that the canonical mbox database MUST use a single Line-Feed character (0x0A) as the end-of-line sequence, and MUST NOT use a Carriage-Return/Line-Feed pair (NB: this requirement only applies to the canonical mbox database as transferred, and does not override any other specifications). This usage represents the most common historical representation of the mbox database format, and allows for the least amount of conversion.
Oデータベース内の各メッセージは、カノニカルMBOXデータベースがエンドオブとして単改行文字（0x0Aの）を使用しなければならないことを除いて、RFC 2822 [RFC2822]及びその関連仕様で定義された構文およびフォーマッティング規則に従わなければなりませんラインシーケンス、および復帰/改行のペア（NB：この要件は唯一の転送として標準的なmbox形式のデータベースに適用され、その他の仕様を上書きすることはありません）を使用してはなりません。この使用は、MBOXデータベース形式の最も一般的な歴史的な表現を表し、変換の最小量を可能にします。
o Messages within the default mbox database MUST consist of seven-bit characters within an eight-bit stream. Eight-bit data within the stream MUST be converted to a seven-bit form (using appropriate, standardized encoding) and appropriately tagged (with the correct header fields) before the database is transferred.
Oデフォルトのmbox形式のデータベース内のメッセージは、8ビット・ストリーム内の7ビット文字で構成する必要があります。ストリーム内の8ビットのデータがデータベースに転送される前に、適切に（正しいヘッダフィールドで）タグ付けされた（適切な、標準化された符号化を使用して）7ビット形式に変換されなければなりません。
o Message headers and data in the default mbox database MUST be fully-qualified, as per the relevant specification(s). For example, email addresses in the various header fields MUST have legitimate domain names (as per RFC 2822), while extended characters and encodings MUST be specified in the appropriate location (as per the appropriate MIME specifications), and so forth.
OデフォルトMBOXデータベース内のメッセージヘッダとデータは、関連する仕様（単数または複数）に従って、完全修飾でなければなりません。拡張文字と符号化が等（適切なMIME仕様に従って）適切な場所に指定され、なければならないが、例えば、様々なヘッダフィールドに電子メールアドレスは、（RFC 2822による）正規のドメイン名を持っていなければなりません。
o Each message in the mbox database MUST be immediately preceded by a single separator line, which MUST conform to the following syntax:
O MBOXデータベース内の各メッセージは、直ちに次の構文に準拠しなければならない単一の区切り線が先行しなければなりません。
The exact character sequence of "From";
「から」の正確な文字列。
a single Space character (0x20);
単一のスペース文字（0x20の）;
the email address of the message sender (as obtained from the message envelope or other authoritative source), conformant with the "addr-spec" syntax from RFC 2822;
RFC 2822から「ADDRスペック」構文に準拠し、（メッセージエンベロープまたは他の信頼できるソースから得られる）メッセージ送信者の電子メールアドレス。
a single Space character;
単一スペース文字。
a timestamp indicating the UTC date and time when the message was originally received, conformant with the syntax of the traditional UNIX 'ctime' output sans timezone (note that the use of UTC precludes the need for a timezone indicator);
伝統的なUNIX「ctimeの」出力サンセリフのタイムゾーンの構文に準拠UTCの日付とメッセージが最初に受信した時刻を示すタイムスタンプ、（UTCの使用が時間帯標識の必要性を排除することに注意してください）。
an end-of-line marker.
行末マーカー。
o Each message in the database MUST be terminated by an empty line, containing a single end-of-line marker.
Oデータベース内の各メッセージは、シングルエンド・オブ・ラインマーカーを含む、空行で終了する必要があります。
Note that the first message in an mbox database will only be prefaced by a separator line, while every other message will begin with two end-of-line sequences (one at the end of the message itself, and another to mark the end of the message within the mbox database file stream) and a separator line (marking the new message). The end of the database is implicitly reached when no more message data or separator lines are found.
他のすべてのメッセージがの終わりをマークするために2つのエンド・オブ・ラインシーケンス（メッセージ自体の端部に1つ、そして相互に開始されつつMBOXデータベース内の最初のメッセージのみ、区切り線によって前置きされることに注意してくださいMBOXデータベースファイルストリーム内のメッセージ）、および区切り線（新たなメッセージをマーキング）。それ以上のメッセージデータまたはセパレータ線が見つからなかった場合、データベースの端部は、暗黙的に達成されます。
Also note that this specification does not prescribe any escape syntax for message body lines that begin with the character sequence of "From ". Recipient systems are expected to parse full separator lines as they are documented above.
また、この仕様は、「から」の文字列で始まるメッセージのボディラインのための任意のエスケープ構文を規定していないことに注意してください。受信者のシステムは、それらが上記の文書化されているようフル区切り線を解析することが期待されています。
Author's Address
著者のアドレス
Eric A. Hall
エリック・A.・ホール
EMail: ehall@ntrg.com
メールアドレス：ehall@ntrg.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。