[要約] RFC 4155は、application/mboxメディアタイプの仕様を定義しています。このメディアタイプは、電子メールのメッセージを複数のメッセージを含む単一のファイルとして表現するために使用されます。目的は、電子メールのデータを効率的に保存、転送、および処理することです。
Network Working Group E. Hall
Request for Comments: 4155 September 2005
Category: Informational
The application/mbox Media Type
アプリケーション/MBOXメディアタイプ
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).
Copyright（c）The Internet Society（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.
このメモは、RFC 2048で指定された用語に従って、アプリケーション/MboxメディアタイプをIESGによる割り当ての許可を許可することを要求します。このメモは、すべての適切な実装でサポートする必要があるMboxデータベースのデフォルト形式も定義します。
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データベースには、通常、電子メールメッセージの線形シーケンスが含まれています。各メッセージは、メッセージ送信者を識別するセパレーターラインから始まり、最終受信者（転送パスの最終ホップシステムのいずれか、または受信者のものとして機能するシステムがメッセージが受信された日時も識別されます。MailStore）。通常、各メッセージは空の行によって終了します。データベースの終了は、通常、追加のデータがないこと、または明示的なファイルのエンドマーカーが存在することによって認識されます。
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.
セパレーターラインの構造は実装間で異なりますが、通常は「From」の正確な文字シーケンスが含まれ、その後に単一のスペース文字（0x20）、ある種の電子メールアドレス、別のスペース文字、何らかの種類のタイムスタンプシーケンスが含まれます。そして、終わりのマーカー。ただし、権威ある仕様がないため、これらの属性のそれぞれは、実装全体で大きく異なることが知られています。たとえば、電子メールアドレスは、すべての履歴のメッセージングシステムで使用されたことのあるアドレス指定の構文を反映できます（特に、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データベース内のメッセージデータは、多くの場合、サイト固有の特性を反映しています。たとえば、Mboxデータベース内のメッセージ本文またはヘッダーが、サイト固有のデフォルト言語またはロケールを暗黙的に反映する、またはタイムスタンプや電子メールアドレスのローカルデフォルトを反映する未積ばられていない8ビット文字データを含めることが完全に可能です。このデータはいずれも、ローカルスコープを超えて広く移植可能ではありません。同様に、メッセージデータには、エンコードされていない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.
多くの実装は、「From」の文字シーケンスから始まるメッセージボディラインを逃れることも知られています。一般的なケースでは、この目的のために（「from」> from」を使用して）、先頭のより大きなシンボル（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メディアタイプ名：アプリケーション
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または引用プリントなど）を使用して、Mboxデータベース（または少なくともセパレーターライン）をエンコードする必要があります。メッセージングプロトコルを介して転送されます。他の転送サービスは一般に、同様のエンコード戦略を採用して、その後の再送信が発生する可能性があることを奨励しますが、これは要件ではありません。また、非準拠データを受信した場合、実装者はMoxデータをローカルにエンコードする準備をする必要があります。
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データベースの単一の権威ある仕様がないため、データベース形式間に多数のバリエーションがあります（一般的な例については、紹介テキストを参照）。または交換。このメモで指定された「デフォルト」形式では、これらの種類の気まぐれを許可していませんが、人間間の事前交渉または合意が必要になる場合があります。
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.
マジック番号：MBOXデータベースファイルは、「FROM」の主要な文字シーケンスを持つことで認識できます。その後、単一のスペース文字（0x20）が続き、その後に追加の印刷可能な文字データが続きます（詳細については、付録Aの説明を参照）を参照）。ただし、実装者は、そのようなすべてのファイルがすべてのフォーマットルールに準拠していないことに注意しているため、実装者はこれらのファイルを適切な量の円周で扱う必要があります。
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.
ファイル拡張子：Mboxデータベースファイルには「.mbox」拡張機能がある場合がありますが、これは必須でも予想もありません。魔法の数字と同様に、実装者はそのようなファイルの内容に関する反射的な仮定を避ける必要があります。
Macintosh File Type Code(s): None are known to be common.
Macintoshファイルタイプコード：一般的であることが知られていない。
Person & email address to contact for further information: Eric A. Hall (ehall@ntrg.com)
詳細については、個人とメールアドレスをお問い合わせ：Eric A. Hall（ehall@ntrg.com）
Intended usage: 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は、このメモで説明されているように、「フォーマット」パラメーターの値のレジストリを確立し、維持します。最初の登録は、付録Aで提供される説明を使用して「デフォルト」値です。「フォーマット」パラメーターの次の値には、IESGが承認した仕様、またはIESGが承認した仕様など、何らかの形式の認識可能で完全かつ合法的な仕様を添付する必要があります。ある種の権威あるベンダーのドキュメント。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、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] Freed、N.、Klensin、J。、およびJ. Postel、「多目的インターネットメールエクステンション（MIME）パート4：登録手順」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
Appendix A. The "default" mbox Database Format
付録A. 「デフォルト」MBOXデータベース形式
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 データベース内の各メッセージは、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データベース内のメッセージヘッダーとデータは完全に資格を付ける必要があります。たとえば、さまざまなヘッダーフィールドの電子メールアドレスには正当なドメイン名（RFC 2822に従って）が必要ですが、拡張文字とエンコーディングは適切な場所（適切なMIME仕様に従って）などで指定する必要があります。
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";
「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-spec」構文に適合しています。
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);
メッセージが最初に受信されたUTCの日付と時刻を示すタイムスタンプは、従来のUNIX「Ctime」出力SANS TimeZoneの構文に適合しています（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.
Mboxデータベースの最初のメッセージはセパレーターラインによってのみ前に張り込まれ、他のすべてのメッセージは2つの行の終了シーケンス（1つはメッセージ自体の最後に、もう1つは次のメッセージが終了します。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.
また、この仕様では、「From」の文字シーケンスから始まるメッセージボディラインのEscape構文を規定していないことに注意してください。レシピエントシステムは、上記の文書化されているように、完全なセパレーターラインを解析することが期待されています。
Author's Address
著者の連絡先
Eric A. Hall
エリック・A・ホール
EMail: ehall@ntrg.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。