p1) Network Working Group P. Resnick, Editor Request for Comments: 2822 QUALCOMM Incorporated Obsoletes: 822 April 2001 Category: Standards Track Internet Message Format Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. この文書の位置付け この文書はインターネット共同体のためのインターネット標準トラックプロト コルを示すものであり、発展のための議論や提案を依頼するものである。 このプロトコルの位置付けや標準化の段階については「Internet Official Protocol Standards」の現在の版を参照してほしい。この文書の配布は無制限 である。 Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This standard specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This standard supersedes the one specified in Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. 要約 この標準はコンピュータ利用者の間で送られるテキストメッセージの構文を規 定したもので、E-mailのメッセージが含まれる。この標準は標準であった RFC822 「Standard for the Format of ARPA Internet Text Messages」にとっ てかわるものであり、現在の実装や他のRFCで規定された増加分の変更を組み 込み反映したものである。 Table of Contents 1. Introduction ............................................... 3 1.1. Scope .................................................... 3 1.2. Notational conventions ................................... 4 1.2.1. Requirements notation .................................. 4 1.2.2. Syntactic notation ..................................... 4 1.3. Structure of this document ............................... 4 2. Lexical Analysis of Messages ............................... 5 2.1. General Description ...................................... 5 2.1.1. Line Length Limits ..................................... 6 2.2. Header Fields ............................................ 7 2.2.1. Unstructured Header Field Bodies ....................... 7 2.2.2. Structured Header Field Bodies ......................... 7 2.2.3. Long Header Fields ..................................... 7 2.3. Body ..................................................... 8 3. Syntax ..................................................... 9 3.1. Introduction ............................................. 9 3.2. Lexical Tokens ........................................... 9 (p2) 3.2.1. Primitive Tokens ....................................... 9 3.2.2. Quoted characters ......................................10 3.2.3. Folding white space and comments .......................11 3.2.4. Atom ...................................................12 3.2.5. Quoted strings .........................................13 3.2.6. Miscellaneous tokens ...................................13 3.3. Date and Time Specification ..............................14 3.4. Address Specification ....................................15 3.4.1. Addr-spec specification ................................16 3.5 Overall message syntax ....................................17 3.6. Field definitions ........................................18 3.6.1. The origination date field .............................20 3.6.2. Originator fields ......................................21 3.6.3. Destination address fields .............................22 3.6.4. Identification fields ..................................23 3.6.5. Informational fields ...................................26 3.6.6. Resent fields ..........................................26 3.6.7. Trace fields ...........................................28 3.6.8. Optional fields ........................................29 4. Obsolete Syntax ............................................29 4.1. Miscellaneous obsolete tokens ............................30 4.2. Obsolete folding white space .............................31 4.3. Obsolete Date and Time ...................................31 4.4. Obsolete Addressing ......................................33 4.5. Obsolete header fields ...................................33 4.5.1. Obsolete origination date field ........................34 4.5.2. Obsolete originator fields .............................34 4.5.3. Obsolete destination address fields ....................34 4.5.4. Obsolete identification fields .........................35 4.5.5. Obsolete informational fields ..........................35 4.5.6. Obsolete resent fields .................................35 4.5.7. Obsolete trace fields ..................................36 4.5.8. Obsolete optional fields ...............................36 5. Security Considerations ....................................36 6. Bibliography ...............................................37 7. Editor's Address ...........................................38 8. Acknowledgements ...........................................39 Appendix A. Example messages ..................................41 A.1. Addressing examples ......................................41 A.1.1. A message from one person to another with simple addressing .............................................41 A.1.2. Different types of mailboxes ...........................42 A.1.3. Group addresses ........................................43 A.2. Reply messages ...........................................43 A.3. Resent messages ..........................................44 A.4. Messages with trace fields ...............................46 A.5. White space, comments, and other oddities ................47 A.6. Obsoleted forms ..........................................47 (p3) A.6.1. Obsolete addressing ....................................48 A.6.2. Obsolete dates .........................................48 A.6.3. Obsolete white space and comments ......................48 Appendix B. Differences from earlier standards ................49 Appendix C. Notices ...........................................50 Full Copyright Statement ......................................51 1. Introduction 1.1. Scope This standard specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This standard supersedes the one specified in Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages" [RFC822], updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs [STD3]. 1 導入 1.1 目的 この標準はコンピュータ利用者の間で送られるテキストメッセージの構文を規 定したもので、E-mailのメッセージが含まれる。この標準は標準であった RFC822 「Standard for the Format of ARPA Internet Text Messages」にとっ てかわるものであり、現在の実装や他のRFCで規定された増加分の変更を組み 込み反映したものである。[STD3] This standard specifies a syntax only for text messages. In particular, it makes no provision for the transmission of images, audio, or other sorts of structured data in electronic mail messages. There are several extensions published, such as the MIME document series [RFC2045, RFC2046, RFC2049], which describe mechanisms for the transmission of such data through electronic mail, either by extending the syntax provided here or by structuring such messages to conform to this syntax. Those mechanisms are outside of the scope of this standard. この標準はテキストメッセージの構文だけを規定する。特に、画像、音声など のようなE-mailのメッセージ内の構築されたデータのためには規定しない。 MIMEドキュメントシリーズ[RFC2045, 2046, 2059]のようないくつかの拡張が 発行されているが、それはそのようなデータをE-mailを通じて送るからくりを 説明しており、ここに提供された構文の拡張やそれらのメッセージをこの構文 へ適合させるような構造化についてではない。それらのからくりはこの標準の 範囲外である。 In the context of electronic mail, messages are viewed as having an envelope and contents. The envelope contains whatever information is needed to accomplish transmission and delivery. (See [RFC2821] for a discussion of the envelope.) The contents comprise the object to be delivered to the recipient. This standard applies only to the format and some of the semantics of message contents. It contains no specification of the information in the envelope. E-mail状況において、メッセージはエンベロープ(封筒)とコンテンツ(内容)を 持つとみなされる。エンベロープは伝送や配送をなし遂げるのに必要などんな 情報も含んでいる([RFC821]のエンベロープに関する議論を見よ)。コンテンツ は受取人へ配達される目的物を含む。この標準は書式とコンテンツの記号論の 一部についてのみ適用される。エンベロープ中の情報の記述は含んでいない。 However, some message systems may use information from the contents to create the envelope. It is intended that this standard facilitate the acquisition of such information by programs. にもかかわらず、いくつかのシステムはエンベロープを作るのにコンテンツか らの情報を使うかもしれない。この標準がそのような情報のプログラムによる 取得を用意にするつもりである。 This specification is intended as a definition of what message content format is to be passed between systems. Though some message systems locally store messages in this format (which eliminates the need for translation between formats) and others use formats that differ from the one specified in this standard, local storage is outside of the scope of this standard. この規定はどのコンテンツの書式がシステム間で通るのかの定義をするつもり である。いくつかのシステムはこの書式でメッセージをローカルに蓄え (それは表記法間の翻訳の必要を排除する)、別のシステムではこの標準で規定 されたのと異なる表記法を用いるが、ローカルでの蓄積(spool)はこの標準の 範囲外である。 (p4) Note: This standard is not intended to dictate the internal formats used by sites, the specific message system features that they are expected to support, or any of the characteristics of user interface programs that create or read messages. In addition, this standard does not specify an encoding of the characters for either transport or storage; that is, it does not specify the number of bits used or how those bits are specifically transferred over the wire or stored on disk. メモ:この標準はサイトで使われる内部フォーマットを指図するつもりはない 1.2. Notational conventions 1.2.1. Requirements notation This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in [RFC2119]. この文書では時々、大文字で書かれた用語が使われる。「MUST」「SHOULD」 「RECOMMENDED」「MUST NOT」「SHOULD NOT」「MAY」が大文字で現れた場合に は、それらは特にこの使用を要求して使われる。これらの用語の意味について の議論は[RFC2119]にある。 1.2.2. Syntactic notation This standard uses the Augmented Backus-Naur Form (ABNF) notation specified in [RFC2234] for the formal definitions of the syntax of messages. Characters will be specified either by a decimal value (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by a case-insensitive literal value enclosed in quotation marks (e.g., "A" for either uppercase or lowercase A). See [RFC2234] for the full description of the notation. 構文上の表記方法 この標準はメッセージの構文の正式な定義のためのRFC2234に規定されたABNF 表記法を用いている。文字は数値(例えば%d65が大文字のA、%d97が小文字の A)または大文字小文字を区別しない、引用符に囲まれた文字通りの値(例えば "A"は大文字または小文字のA)のいずれかで規定される。表記法の完全な詳細 はRFC2234を見よ。 1.3. Structure of this document This document is divided into several sections. This section, section 1, is a short introduction to the document. 文書の成り立ち この文書はいくつかのセクションに分かれている。 このセクション1はこの文書の短い導入である。 Section 2 will lay out the general description of a message and its constituent parts. This is an overview to help the reader understand some of the general principles used in the later portions of this document. Any examples in this section MUST NOT be taken as specification of the formal syntax of any part of a message. セクション2ではメッセージの一般的な記述と構成要素について説明する。こ れはこの文書の後の部分で使われる一般的な原則のいくつかを読み手が理解す る手助けをするためのあらましである。このセクションの例示はメッセージの どの部分の正式な構文の規定ととってはならない(MUST NOT)。 Section 3 will specify formal ABNF rules for the structure of each part of a message (syntax) and describe the relationship between those parts and their meaning in the context of a message (the semantics). That is, it will describe the actual rules for the structure of each part of a message (the syntax) as well as a description of the parts and instructions on how they ought to be interpreted (the semantics). This will include analysis of the syntax and semantics of subparts of messages that have specific structure. The syntax included in section 3 represents messages as they MUST be created. There are also notes in section 3 to indicate if any of the options specified in the syntax SHOULD be used over any of the others. セクション3ではメッセージのそれぞれの部分の構造(構文)の正式なABNFルー ルを規定し、それらの部分間の関係とメッセージの前後関係の意味(意味論) について記す。つまり、メッセージのそれぞれの部分の構造の本当のきまり (構文)について記すとともに、部分の記述やそれらがどのように解釈される べきかの指示についてである。これは特定の構造を持つメッセージの一部分の 構文や意味論を含む。セクション3に含まれる構文は作られるべき(MUST)もの としてメッセージが表現されている。セクション3にはまた、構文に規定され たいくつかのオプションが別のいくつかに優先して使われるべき(SHOULD)場合 について示したノートがある。 (p5) Both sections 2 and 3 describe messages that are legal to generate for purposes of this standard. セクション2と3では共にこの標準の目的によって正しく生成されたメッセー ジについて書いてある。 Section 4 of this document specifies an "obsolete" syntax. There are references in section 3 to these obsolete syntactic elements. The rules of the obsolete syntax are elements that have appeared in earlier revisions of this standard or have previously been widely used in Internet messages. As such, these elements MUST be interpreted by parsers of messages in order to be conformant to this standard. However, since items in this syntax have been determined to be non-interoperable or to cause significant problems for recipients of messages, they MUST NOT be generated by creators of conformant messages. この文書のセクション4では時代遅れの構文を規定している。これらのすたれ た構文の要素へはセクション3から参照がある。すたれた構文のルールはこの 標準の古いリビジョンに現れたり、インターネットメッセージでかつて広くつ かわれたりした要素である。そのようなわけで、これらの要素はこの標準に従 うためにはメッセージのパーサによって解釈されねばならない(MUST)。しかし ながら、この構文のアイテムが運用不能と決定されたりメッセージの配送に重 大な問題を起こす場合には、メッセージの作り手によって作られてはならない (MUST NOT)。 Section 5 details security considerations to take into account when implementing this standard. セクション5ではこの標準を実装したとき考えにいれねばならないセキュリティ に関する考察がかかれている。 Section 6 is a bibliography of references in this document. セクション6ではこの文書の参考文献を記す。 Section 7 contains the author's address and instructions on where to send comments. セクション7では著者の住所とコメントをどこに送ればいいかの指示がある。 Section 8 contains acknowledgements. セクション8は謝辞である。 Appendix A lists examples of different sorts of messages. These examples are not exhaustive of the types of messages that appear on the Internet, but give a broad overview of certain syntactic forms. 付録Aは異なるメッセージの種類の例をリストにしている。これらの例はイン ターネット上に現れるメッセージの種類を網羅したものではないが、ある構文 系の広いあらましを与える。 Appendix B lists the differences between this standard and earlier standards for Internet messages. 付録Bはインターネットメッセージに関するこの標準とかつての標準との違い をリストにしている。 Appendix C has copyright and intellectual property notices. 付録Cは著作権と知的所有権に関する情報である。 2. Lexical Analysis of Messages 2.1. General Description At the most basic level, a message is a series of characters. A message that is conformant with this standard is comprised of characters with values in the range 1 through 127 and interpreted as US-ASCII characters [ASCII]. For brevity, this document sometimes refers to this range of characters as simply "US-ASCII characters". メッセージの語彙の分析 一般的な記述 もっとも基本的なレベルにおいて、メッセージは一連の文字である。この標準 に従うメッセージは1から127の範囲の値の文字からなり、US-ASCIIキャラクター として解釈される。簡単にするために、この文書では時としてこの範囲の文字 を単に「US-ASCIIキャラクター」と呼ぶ。 (p6) Note: This standard specifies that messages are made up of characters in the US-ASCII range of 1 through 127. There are other documents, specifically the MIME document series [RFC2045, RFC2046, RFC2047, RFC2048, RFC2049], that extend this standard to allow for values outside of that range. Discussion of those mechanisms is not within the scope of this standard. 注意:この標準ではメッセージは1から127までの範囲のUS-ASCIIにある文字 から成ると規定する。その範囲外の値を許すよう、この標準を拡張する他の文 書、特にMIMEに関する一連の文書(RFC2045〜2047)がある。その機構について の議論はこの標準の視野外である。 Messages are divided into lines of characters. A line is a series of characters that is delimited with the two characters carriage-return and line-feed; that is, the carriage return (CR) character (ASCII value 13) followed immediately by the line feed (LF) character (ASCII value 10). (The carriage-return/line-feed pair is usually written in this document as "CRLF".) メッセージは文字のラインに分割される。ラインは2つの文字、キャリッジリ ターンとラインフィードで区切られた一連の文字である;それはキャリッジリ ターン文字(CR, ASCIIコードで13)にすぐ続いてラインフィード文字(LF, ASCIIコードで10)である。(キャリッジリターン/ラインフィードのペアはし ばしばこの文書で「CRLF」と書かれる)。 A message consists of header fields (collectively called "the header of the message") followed, optionally, by a body. The header is a sequence of lines of characters with special syntax as defined in this standard. The body is simply a sequence of characters that follows the header and is separated from the header by an empty line (i.e., a line with nothing preceding the CRLF). メッセージはヘッダフィールド(集合的にメッセージヘッダと呼ばれる)と、 それに続く任意のボディからなる。ヘッダはこの標準に定められた特殊な構文 による文字列のシーケンスである。ボディはヘッダに続く、ヘッダと1つの空 行で区切られた(つまり、CRLFの前に何もない行)単なる文字のシーケンスで ある。 2.1.1. Line Length Limits There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. 行の長さの制限 この標準では1行中の文字数に2つの制限がある。それぞれの行の文字はCRLF を除いて、決して998文字以下でなければならず(MUST)、78文字以下であるべ きである(SHOULD)。 The 998 character limit is due to limitations in many implementations which send, receive, or store Internet Message Format messages that simply cannot handle more than 998 characters on a line. Receiving implementations would do well to handle an arbitrarily large number of characters in a line for robustness sake. However, there are so many implementations which (in compliance with the transport requirements of [RFC2821]) do not accept messages containing more than 1000 character including the CR and LF per line, it is important for implementations not to create such messages. 998文字制限は多くの実装が「インターネットメッセージフォーマット」のメッ セージを送受信、蓄積するのに、単に1行に998文字を越えるものを扱えない という制限によるものである。受信の実装は強い実装という理由で多くの文字 を任意にうまく扱えるかもしれない。しかしながら、CRとLFを含めて1行に 1000文字をこえるメッセージを受け付けない非常に多くの実装(RFC2821の配 送に関する要求に従って)があり、そのようなメッセージをつくらないことが 実装として重要である。 The more conservative 78 character recommendation is to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line, in spite of the fact that such implementations are non-conformant to the intent of this specification (and that of [RFC2821] if they actually cause information to be lost). Again, even though this limitation is put on messages, it is encumbant upon implementations which display messages to handle an arbitrarily large number of characters in a line (certainly at least up to the 998 character limit) for the sake of robustness. より控えめな78文字の勧告は、以下のような実装はこの標準の目的に(そして もし本当に情報が失われるのならRFC2821にも)従わないという事実にもかか わらず、1行に78文字を越えて表示すると途中で切れたり、ひどいラップ(1 行が複数行にまたがって表示されるときによけいなものが表示される)が生じ たりするようなユーザインターフェイスの多くの実装に便宜を図るためである。 繰り返すと、この制限がメッセージに課せられているにもかかわらず、強度の 理由から、1行に専断的な長さの文字数をもつ文字列(少なくとも998文字制 限より下)を扱うためのメッセージを表示するシステムを実装することをこの 標準は妨げる(訳注:1行の長さを勝手に決めるようなシステムの実装は、この 標準の要件を満たさない)。 (p7) 2.2. Header Fields Header fields are lines composed of a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF. A field name MUST be composed of printable US-ASCII characters (i.e., characters that have values between 33 and 126, inclusive), except colon. A field body may be composed of any US-ASCII characters, except for CR and LF. However, a field body may contain CRLF when used in header "folding" and "unfolding" as described in section 2.2.3. All field bodies MUST conform to the syntax described in sections 3 and 4 of this standard. ヘッダフィールド ヘッダフィールドはフィールド名から成る行で、コロン(:)が続き、さらに フィールドボディが続き、CRLFで終わる。フィールド名は印刷可能なUS-ASCII 文字(つまり、包括的にいって33から126の値を持つ文字)で構成されねばな らない(MUST)。フィールドボディはCR,LFを除く任意のUS-ASCII文字からなっ てよい。しかしながら、セクション2.2.3で述べるヘッダの"folding"や "unfolding"(折り返し)が使われるなら、フィールドボディはCRLFを含んで もよい。すべてのフィールドボディはこの標準のセクション3,4に記した構 文に従わなければならない。 2.2.1. Unstructured Header Field Bodies Some field bodies in this standard are defined simply as "unstructured" (which is specified below as any US-ASCII characters, except for CR and LF) with no further restrictions. These are referred to as unstructured field bodies. Semantically, unstructured field bodies are simply to be treated as a single line of characters with no further processing (except for header "folding" and "unfolding" as described in section 2.2.3). 構造化されないヘッダフィールドボディ この標準において、いくつかのフィールドボディはそれ以上の制限なく、単に 構造化されない(CR,LF以外のいかなるUS-ASII文字と以下で規定されている) と定義される。これらは構造化されないフィールドボディと参照される。構文 的にいって、構造化されないフィールドボディは単にそれ以上処理されない文 字の1行として扱われる(セクション2.2.3で述べるヘッダのfolding と unfoldingを除く)。 2.2.2. Structured Header Field Bodies Some field bodies in this standard have specific syntactical structure more restrictive than the unstructured field bodies described above. These are referred to as "structured" field bodies. Structured field bodies are sequences of specific lexical tokens as described in sections 3 and 4 of this standard. Many of these tokens are allowed (according to their syntax) to be introduced or end with comments (as described in section 3.2.3) as well as the space (SP, ASCII value 32) and horizontal tab (HTAB, ASCII value 9) characters (together known as the white space characters, WSP), and those WSP characters are subject to header "folding" and "unfolding" as described in section 2.2.3. Semantic analysis of structured field bodies is given along with their syntax. 構造化されたヘッダフィールドボディ この標準において、いくつかのフィールドボディは上記の構造化されないフィー ルドボディよりも拘束された特殊な構文の構造を持つ。これらは構造化された フィールドボディとして参照される。構造化されたフィールドボディはこの標 準のセクション3,4に述べる特殊な語彙のトークンの並びである。これらの トークンの多くがスペース(SP, アスキーコード32)、水平タブ(HTAB, アスキー コード9)、セクション2.2.3に記したfoldingやunfoldingのヘッダを仮定する WSPキャラクターと同様、(その構文によって)始まり、コメントとともに終 わることが許される。構造化されたフィールドボディの構文解析はその構文に そって得られる。 2.2.3. Long Header Fields Each header field is logically a single line of characters comprising the field name, the colon, and the field body. For convenience however, and to deal with the 998/78 character limitations per line, the field body portion of a header field can be split into a multiple line representation; this is called "folding". The general rule is that wherever this standard allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP. For example, the header field: それぞれのヘッダフィールドはフィールド名、コロン、フィールドボディから 成る単一論理行である。しかしながら便宜のため、また1行あたり998ないし 78文字の制限を扱うために、ヘッダフィールドの一部であるフィールドボディ は複数行に分割して表現でき、これをfoldingと呼ぶ。一般的なルールは、ど こであれこの標準がfoldingのホワイトスペース(WSPではない)を見込むとき、 WSPの前にCRLFを挿入してよい、というものである。例えば、ヘッダフィール ド: (p8) Subject: This is a test can be represented as: は以下のように表現できる。 Subject: This is a test Note: Though structured field bodies are defined in such a way that folding can take place between many of the lexical tokens (and even within some of the lexical tokens), folding SHOULD be limited to placing the CRLF at higher-level syntactic breaks. For instance, if a field body is defined as comma-separated values, it is recommended that folding occur after the comma separating the structured items in preference to other places where the field could be folded, even if it is allowed elsewhere. 注意:構造化されたフィールドボディはfoldingが構文上のトークンの多くの 間に存在できるというふうに定義されているにもかかわらず(そしていくつか の構文上のトークン内にさえ)、foldingはより高次の構文上の分かれ目にお かれるよう制限されるべきである(SHOULD)。例えば、もしフィールドボディが コンマで分けられる値と定義されているならば、よしんば別のところで許可さ れているにしても、フィールドがfoldできるそれ以外の場所よりも優先して、 構造化された項目を分割するコンマの後でfoldingが起きることが推奨される。 The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation. このfoldingされたヘッダフィールドの複数行表現を1行表現にする過程を unfolding と呼ぶ。unfolding はWSPがすぐ後に続くあらゆるCRLFを単に削除す ることでなされる。それぞれのヘッダフィールドはunfoldingの形で文法、意 味の評価がなされるべきである。 2.3. Body The body of a message is simply lines of US-ASCII characters. The only two limitations on the body are as follows: ボディ メッセージのボディは単にUS-ASCII文字の列である。ボディに課せられたたっ た2つの制限は以下の通り。 - CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body. CRとLFはCRLFとして一緒に現れねばならない(MUST)。ボディに独立して現れて はならない(MUST NOT)。 - Lines of characters in the body MUST be limited to 998 characters, and SHOULD be limited to 78 characters, excluding the CRLF. ボディ中、ラインの文字数はCRLFを除き998に制限されねばならず(MUST)、78 に制限されるべきである(SHOULD)。 Note: As was stated earlier, there are other standards documents, specifically the MIME documents [RFC2045, RFC2046, RFC2048, RFC2049] that extend this standard to allow for different sorts of message bodies. Again, these mechanisms are beyond the scope of this document. 注意:以前述べた通り、別の標準文書、特にこの標準に別の種類のメッセージ ボディを許すような拡張であるMIMEに関する文書(RFC2045, 2046, 2048, 2049)が存在する。再度言うが、これらの機構はこの文書の範囲外である。 (p9) 3. Syntax 3.1. Introduction The syntax as given in this section defines the legal syntax of Internet messages. Messages that are conformant to this standard MUST conform to the syntax in this section. If there are options in this section where one option SHOULD be generated, that is indicated either in the prose or in a comment next to the syntax. 構文 導入 このセクションで与えられる構文ではインターネットメッセージの合法的な構 文を定義する。この標準に合致したメッセージはこの節の構文に合致せねばな らない(MUST)。もしこのセクションに生成されるべき(SHOULD)場所が決まった オプションがあるならば、散文中または構文の隣のコメントに示す。 For the defined expressions, a short description of the syntax and use is given, followed by the syntax in ABNF, followed by a semantic analysis. Primitive tokens that are used but otherwise unspecified come from [RFC2234]. 表現の定義として、構文についての短い記述と用法を挙げ、続いてABNF中の構 文、意味論の分析を挙げる。使われているが明確に示されない基本的なトーク ンはRFC2234から来ている。 In some of the definitions, there will be nonterminals whose names start with "obs-". These "obs-" elements refer to tokens defined in the obsolete syntax in section 4. In all cases, these productions are to be ignored for the purposes of generating legal Internet messages and MUST NOT be used as part of such a message. However, when interpreting messages, these tokens MUST be honored as part of the legal syntax. In this sense, section 3 defines a grammar for generation of messages, with "obs-" elements that are to be ignored, while section 4 adds grammar for interpretation of messages. 定義のいくつかにおいて、obs-で始まる名前を持つ語末でないものがある。こ のobs-要素はセクション4の時代遅れな構文中定義されたトークンを示す。す べての場合において、これらの提示は正しいインターネットメッセージ生成の 目的から無視されるべきであり、そのようなメッセージの一部として使っては ならない(MUST NOT)。しかしながら、メッセージを解釈する場合には、これら のトークンは正しい構文の一部として尊敬されねばならない(MUST)。この感覚 から、セクション4でメッセージ解釈のための文法を加えるために、セクショ ン3では無視されるべきobs要素を含めてメッセージ生成のための文法を定義 する。 3.2. Lexical Tokens The following rules are used to define an underlying lexical analyzer, which feeds tokens to the higher-level parsers. This section defines the tokens used in structured header field bodies. 構文トークン 以下のルールは基礎となる構文分析装置を定義するために使われるが、それは トークンをより高次のパーサに送り込む。このセクションでは構造化されたヘッ ダフィールドボディに使われるトークンを定義する。 Note: Readers of this standard need to pay special attention to how these lexical tokens are used in both the lower-level and higher-level syntax later in the document. Particularly, the white space tokens and the comment tokens defined in section 3.2.3 get used in the lower-level tokens defined here, and those lower-level tokens are in turn used as parts of the higher-level tokens defined later. Therefore, the white space and comments may be allowed in the higher-level tokens even though they may not explicitly appear in a particular definition. 注意:この標準の読者は、これらの構文トークンがどのように低次とこの文書 の後に出てくる高次両方で使われるか、について特別の注意を払うべきである。 特に、セクション3.2.3で定義されるホワイトスペーストークンやコメントトー クンはここで定義される低次のトークンとして使われるが、それらの低次のトー クンは今度は後に定義される高次のトークンの一部として使われる。すなわち、 ホワイトスペースやコメントは特に定義として明確には現れないにもかかわら ず、高次のトークンとして許可されているかもしれない。 3.2.1. Primitive Tokens The following are primitive tokens referred to elsewhere in this standard, but not otherwise defined in [RFC2234]. Some of them will not appear anywhere else in the syntax, but they are convenient to refer to in other parts of this document. 基本的なトークン 以下はこの標準のどこか別に示される基本的なトークンであり、RFC2234に定 義されているものではない。いくつかはこの構文以外のどこにも現れないが、 この文書の別の部分のために示すと便利である。 (p10) Note: The "specials" below are just such an example. Though the specials token does not appear anywhere else in this standard, it is useful for implementers who use tools that lexically analyze messages. Each of the characters in specials can be used to indicate a tokenization point in lexical analysis. 注意:下記の"specials"はちょうどそのような例である。specialsトークンは この標準以外どこにも現れないが、メッセージの構文解析をするツールを利用 する実装者にとって便利である。特殊文字のそれぞれは構文解析のトークン化 する点を示すのに使われる。 NO-WS-CTL = %d1-8 / ; US-ASCII control characters %d11 / ; that do not include the %d12 / ; carriage return, line feed, %d14-31 / ; and white space characters %d127 US-ASCIIのコントロールコード CR,LF,ホワイトスペースを含まない text = %d1-9 / ; Characters excluding CR and LF %d11 / %d12 / %d14-127 / obs-text CR,LF以外の文字 specials = "(" / ")" / ; Special characters used in "<" / ">" / ; other parts of the syntax "[" / "]" / ":" / ";" / "@" / "\" / "," / "." / DQUOTE この構文の別の箇所で使われる特殊文字 No special semantics are attached to these tokens. They are simply single characters. 特殊な語義がこれらのトークンに結びつけられることはない。それらは単に1 つの文字である。 3.2.2. Quoted characters Some characters are reserved for special interpretation, such as delimiting lexical tokens. To permit use of these characters as uninterpreted data, a quoting mechanism is provided. 引用された文字 いくつかの文字は構文トークンの範囲を定めるような特殊な解釈のために予約 されている。解釈されないデータとしてこれらの文字を利用することを許すた め、引用という機構が提供される。 quoted-pair = ("\" text) / obs-qp Where any quoted-pair appears, it is to be interpreted as the text character alone. That is to say, the "\" character that appears as part of a quoted-pair is semantically "invisible". quoted-pairの現れたところでは、テキスト文字それ自体として解釈されるべ きである。つまり、quoted-pair部分として現れた\文字は語義としては「不 可視」である。 Note: The "\" character may appear in a message where it is not part of a quoted-pair. A "\" character that does not appear in a quoted-pair is not semantically invisible. The only places in this standard where quoted-pair currently appears are ccontent, qcontent, dcontent, no-fold-quote, and no-fold-literal. 注意:メッセージ中、quoted-pairと離れたところに、\文字が現れるかもしれ ない。quoted-pair中以外で現れた1つの\は語義として不可視ではない。こ の標準では、有効なquoted-pairが現れたところだけがccontent, qcontent, dcontent, no-fold-quote, no-fold-literalである。 3.2.3. Folding white space and comments White space characters, including white space used in folding (described in section 2.2.3), may appear between many elements in header field bodies. Also, strings of characters that are treated as comments may be included in structured field bodies as characters enclosed in parentheses. The following defines the folding white space (FWS) and comment constructs. foldingしたホワイトスペースとコメント folding(セクション2.2.3に記した)に使われたものを含むホワイトスペース 文字は、ヘッダフィールドボディの多くの要素の間に現れてもよい。また、コ メントとしてとられる文字列もカッコ()に囲まれた文字として構造化されたフィー ルドボディに含まれてもよい。以下ではfoldingホワイトスペース(FWS)とコメ ントの構成を定義する。 Strings of characters enclosed in parentheses are considered comments so long as they do not appear within a "quoted-string", as defined in section 3.2.5. Comments may nest. カッコに囲まれた文字列は、セクション3.2.5に定義した引用文字列中に現れ たのでなければコメントと考えられる。コメントはネストしてよい。 There are several places in this standard where comments and FWS may be freely inserted. To accommodate that syntax, an additional token for "CFWS" is defined for places where comments and/or FWS can occur. However, where CFWS occurs in this standard, it MUST NOT be inserted in such a way that any line of a folded header field is made up entirely of WSP characters and nothing else. この標準中、コメントやFWSを自由に挿入してよい場所はいくつかある。構文 上便宜を図るため、CFWSという追加のトークンをコメントおよびFWSが起きう る場所として定義する。にもかかわらず、この標準でCFWSが起きる場所で、 foldingヘッダーフィールドのとある行が、完全にWSP文字だけで他になにもな いように作られるような挿入はしてはならない(MUST NOT)。 FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space obs-FWS foldingホワイトスペース ctext = NO-WS-CTL / ; Non white space controls ホワイトスペース以外のコントロール文字 %d33-39 / ; The rest of the US-ASCII %d42-91 / ; characters not including "(", %d93-126 ; ")", or "\" ()\以外のUS-ASCII文字 ccontent = ctext / quoted-pair / comment comment = "(" *([FWS] ccontent) [FWS] ")" CFWS = *([FWS] comment) (([FWS] comment) / FWS) Throughout this standard, where FWS (the folding white space token) appears, it indicates a place where header folding, as discussed in section 2.2.3, may take place. Wherever header folding appears in a message (that is, a header field body containing a CRLF followed by any WSP), header unfolding (removal of the CRLF) is performed before any further lexical analysis is performed on that header field according to this standard. That is to say, any CRLF that appears in FWS is semantically "invisible." この標準の隅から隅まで、FWS(Foldingホワイトスペーストークン)が現れる 場所には、セクション2.2.3で議論したヘッダのfoldingをおいても構わない場 所である、ということが示される。メッセージ中、ヘッダfoldingが現れた場 所どこであれ(つまり、ヘッダフィールドボディがCRLFとそれに続くWSPを含 む)、この標準に従ってヘッダフィールドのさらなる構文解釈が行われる前に ヘッダのunfolding(CRLFを除く)が行われる。いってみれば、FWS中現れる CRLFは語義としては不可視である。 (p11) A comment is normally used in a structured field body to provide some human readable informational text. Since a comment is allowed to contain FWS, folding is permitted within the comment. Also note that since quoted-pair is allowed in a comment, the parentheses and backslash characters may appear in a comment so long as they appear as a quoted-pair. Semantically, the enclosing parentheses are not part of the comment; the comment is what is contained between the two parentheses. As stated earlier, the "\" in any quoted-pair and the CRLF in any FWS that appears within the comment are semantically "invisible" and therefore not part of the comment either. コメントは普通構造化されたフィールドボディに人が読める情報テキストを提 供するために使われる。コメントはFWSを含むことが許されているので、コメ ントにおいてfoldingは許される。quoted-pairがコメント中許されているので、 カッコとバックスラッシュはquoted-pair中に現れるのと同様、現れるかもし れない点にも注意せよ。語義として、囲むカッコはコメントではない;コメン トは2つのカッコの間に含まれるものである。前に述べたように、 quoted-pair中の「\」とコメント中に現れるFWSのCRLFは語義として不可視で あり、故にコメントの一部ではない。 Runs of FWS, comment or CFWS that occur between lexical tokens in a structured field header are semantically interpreted as a single space character. 構造化されたフィールドヘッダ中の構文トークン間にあるFWS, コメント、 CWFSの類は、語義的には1つのスペースとして解釈される。 3.2.4. Atom Several productions in structured header field bodies are simply strings of certain basic characters. Such productions are called atoms. atom 構造化されたヘッダフィールドボディのいくつかの産物は、単にある基本的な 文字列である。そのようなものをatomと呼ぶ。 Some of the structured header field bodies also allow the period character (".", ASCII value 46) within runs of atext. An additional "dot-atom" token is defined for those purposes. いくつかの構造化されたヘッダフィールドボディはまた、一連のatext中ピリ オド(".", アスキーコード46)が許可されている。追加の「dot-atom」トーク ンがその目的で定義される。 atext = ALPHA / DIGIT / ; Any character except controls, "!" / "#" / ; SP, and specials. "$" / "%" / ; Used for atoms "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" atom = [CFWS] 1*atext [CFWS] dot-atom = [CFWS] dot-atom-text [CFWS] dot-atom-text = 1*atext *("." 1*atext) Both atom and dot-atom are interpreted as a single unit, comprised of the string of characters that make it up. Semantically, the optional comments and FWS surrounding the rest of the characters are not part of the atom; the atom is only the run of atext characters in an atom, or the atext and "." characters in a dot-atom. atomとdot-atomは共に1つのかたまりと解釈され、文字列の構成要素である。 語義的に、任意のコメントや残りの文字を囲むFWSはatomの一部ではない; atomはatom中の一連のatext文字;のみであるか、dot-atomではatextと「.」 である。 (p13) 3.2.5. Quoted strings Strings of characters that include characters other than those allowed in atoms may be represented in a quoted string format, where the characters are surrounded by quote (DQUOTE, ASCII value 34) characters. quoted-string (引用された文字列) 引用符(DQUOTE, アスキーコード34)に囲まれた文字のところで、atomで許 されたもの以外を含む文字列がquoted-stringフォーマットとして表現される かもしれない。 qtext = NO-WS-CTL / ; Non white space controls %d33 / ; The rest of the US-ASCII %d35-91 / ; characters not including "\" %d93-126 ; or the quote character qcontent = qtext / quoted-pair quoted-string = [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS] A quoted-string is treated as a unit. That is, quoted-string is identical to atom, semantically. Since a quoted-string is allowed to contain FWS, folding is permitted. Also note that since quoted-pair is allowed in a quoted-string, the quote and backslash characters may appear in a quoted-string so long as they appear as a quoted-pair. quoted-stringは1つの固まりとして扱う。つまり、語義的にはquoted-string はatomと同じである。quoted-stringはFWSを含むことが許されるため、 foldingが許可される。また、quoted-pairがquoted-string中許されるので、 引用符とバックスラッシュの文字はquoted-pair中現れたのと同様に quoted-string中に現れるかもしれないことに注意せよ。 Semantically, neither the optional CFWS outside of the quote characters nor the quote characters themselves are part of the quoted-string; the quoted-string is what is contained between the two quote characters. As stated earlier, the "\" in any quoted-pair and the CRLF in any FWS/CFWS that appears within the quoted-string are semantically "invisible" and therefore not part of the quoted-string either. 語義的に、引用さらた文字列以外の任意のCFWSや引用符そのものは quoted-stringの一部ではない;quoted-stringは2つの引用符の間に囲まれた ものである。前述したように、quoted-string中に現れるquoted-pair中の「\」 とFWS/CFWS中のCRLFは語義的には不可視であり、よってquoted-string中に含 まれない。 3.2.6. Miscellaneous tokens Three additional tokens are defined, word and phrase for combinations of atoms and/or quoted-strings, and unstructured for use in unstructured header fields and in some places within structured header fields. 雑多なトークン word、atomとquoted-stringのいずれか、または両方を組み合わせたphrase、 構造化されないヘッダフィールド中、また構造化されたヘッダフィールドの一 部の場所で使われるunstructuredの3つが追加で定義される。 word = atom / quoted-string phrase = 1*word / obs-phrase (p14) utext = NO-WS-CTL / ; Non white space controls %d33-126 / ; The rest of US-ASCII obs-utext unstructured = *([FWS] utext) [FWS] 3.3. Date and Time Specification Date and time occur in several header fields. This section specifies the syntax for a full date and time specification. Though folding white space is permitted throughout the date-time specification, it is RECOMMENDED that a single space be used in each place that FWS appears (whether it is required or optional); some older implementations may not interpret other occurrences of folding white space correctly. 日時の詳細 日時はいくつかのヘッダフィールドに現れる。このセクションでは日時の詳細 についての構文を規定する。日時の仕様中foldingのホワイトスペースは許さ れているが、FWSが現れるそれぞれの場所(必須、任意いずれも)に1つのス ペースを使うことが推奨される(RECOMMENDED);いくつかの古い実装はfolding のホワイトスペースの存在を正しく解釈できないかもしれない。 date-time = [ day-of-week "," ] date FWS time [CFWS] day-of-week = ([FWS] day-name) / obs-day-of-week day-name = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" date = day month year year = 4*DIGIT / obs-year month = (FWS month-name FWS) / obs-month month-name = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" day = ([FWS] 1*2DIGIT) / obs-day time = time-of-day FWS zone time-of-day = hour ":" minute [ ":" second ] hour = 2DIGIT / obs-hour minute = 2DIGIT / obs-minute second = 2DIGIT / obs-second zone = (( "+" / "-" ) 4DIGIT) / obs-zone (P15) The day is the numeric day of the month. The year is any numeric year 1900 or later. 日(day)は月の中の日である。年(year)は1900年以降の年である。 The time-of-day specifies the number of hours, minutes, and optionally seconds since midnight of the date indicated. time-of-day は日を示す深夜12時からの時、分、オプションで秒を規定する。 The date and time-of-day SHOULD express local time. dateとtime-of-dayは現地時間で表現されるべき(SHOULD)である。 The zone specifies the offset from Coordinated Universal Time (UTC, formerly referred to as "Greenwich Mean Time") that the date and time-of-day represent. The "+" or "-" indicates whether the time-of-day is ahead of (i.e., east of) or behind (i.e., west of) Universal Time. The first two digits indicate the number of hours difference from Universal Time, and the last two digits indicate the number of minutes difference from Universal Time. (Hence, +hhmm means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm) minutes). The form "+0000" SHOULD be used to indicate a time zone at Universal Time. Though "-0000" also indicates Universal Time, it is used to indicate that the time was generated on a system that may be in a local time zone other than Universal Time and therefore indicates that the date-time contains no information about the local time zone. ゾーンは日付と時間表現の世界標準時(UTC, かつてはグリニッジ標準時と呼 ばれた)からのオフセットを規定する。「+」および「-」は、日時が世界時間 よりも進んでいる(東)か遅れている(西)かを表す。最初の2つの数字は世 界時間からの時間のずれを表し、後の2つの数字は世界時間からの分のずれを 表す。(それ故、+hhmmは+(hh * 60 + mm) 分の意味であり、-hhmmは -(hh * 60 + mm) 分の意味である)世界時間のゾーンを表すのに「+0000」が使われる べきである(SHOULD)。「-0000」もまた世界時間を表すが、それは世界時間で はなく、とあるローカルタイムゾーンのとあるシステム上で時間が生成された ことを表すのに用い、故にその日時はローカルタイムゾーンについてなんら情 報を有していないことを示す。 A date-time specification MUST be semantically valid. That is, the day-of-the-week (if included) MUST be the day implied by the date, the numeric day-of-month MUST be between 1 and the number of days allowed for the specified month (in the specified year), the time-of-day MUST be in the range 00:00:00 through 23:59:60 (the number of seconds allowing for a leap second; see [STD12]), and the zone MUST be within the range -9959 through +9959. 日時の記述は意味論的に有効でなければならない(MUST)。つまり、週の中の日 (もし含まれるなら)は日時によって決められねばならない(MUST)し、(月の 中の)日付は1と(規定された年の)規定された月の日数の間になければなら ず(MUST)、また(日の中の)時間は00:00:00と23:59:60(その秒はうるう秒の ために許可されている。std12を見よ)の範囲になければならない(MUST)し、 ゾーンは-9959と+9959の範囲になければならない(MUST)。 3.4. Address Specification Addresses occur in several message header fields to indicate senders and recipients of messages. An address may either be an individual mailbox, or a group of mailboxes. アドレスの規定 アドレスはメッセージの差出人や受取人を表すために、いくつかのメッセージ ヘッダフィールドに現れる。アドレスは個人のメールボックスかメールボック スの集合いずれかを表してよい。 address = mailbox / group mailbox = name-addr / addr-spec name-addr = [display-name] angle-addr angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr group = display-name ":" [mailbox-list / CFWS] ";" [CFWS] (p16) display-name = phrase mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list address-list = address *("," address) / obs-addr-list A mailbox receives mail. It is a conceptual entity which does not necessarily pertain to file storage. For example, some sites may choose to print mail on a printer and deliver the output to the addressee's desk. Normally, a mailbox is comprised of two parts: (1) an optional display name that indicates the name of the recipient (which could be a person or a system) that could be displayed to the user of a mail application, and (2) an addr-spec address enclosed in angle brackets ("<" and ">"). There is also an alternate simple form of a mailbox where the addr-spec address appears alone, without the recipient's name or the angle brackets. The Internet addr-spec address is described in section 3.4.1. メールボックスはメールを受け取る。それはファイルのストレージが付属しな い、概念的な存在物である。例えば、いくつかのサイトでは、メールをプリン タで打ち出して受取人の机にその打ち出した紙を配達するかもしれない。普通、 メールボックスは2つの部分からなる:(1)オプションである、メールアプリ ケーションソフトの利用者が見ることになる、受取人(人かシステムかもしれ ない)の名前が示されるdisplay name (2)かぎかっこ(<>)で囲まれた addr-specのアドレスである。addr-specが単体で現れ、受取人の名前もかぎかっ こもないような、代わりの簡単なメールボックスを表すフォームもある。イン ターネットのaddr-specアドレスはセクション3.4.1に記す。 Note: Some legacy implementations used the simple form where the addr-spec appears without the angle brackets, but included the name of the recipient in parentheses as a comment following the addr-spec. Since the meaning of the information in a comment is unspecified, implementations SHOULD use the full name-addr form of the mailbox, instead of the legacy form, to specify the display name associated with a mailbox. Also, because some legacy implementations interpret the comment, comments generally SHOULD NOT be used in address fields to avoid confusing such implementations. 注意:いくつかの過去からの実装で、かぎかっこなしでaddr-specが現れる簡 単なフォームだが受取人の名前をaddr-specに続けてコメントとしてカッコで くくって含む、というものが使われる。コメント中の情報の意味は規定されて いないので、メールボックスに関連するdisplay nameを定義するために、実装 としてはメールボックスの完全なname-addrフォームを使うべきである (SHOULD)。また、いくつかの過去の実装ではコメントを解釈するので、そのよ うな実装が混乱するのを防ぐため、概してアドレスフィールドにコメントを使 うべきではない(SHOULD NOT)。 When it is desirable to treat several mailboxes as a single unit (i.e., in a distribution list), the group construct can be used. The group construct allows the sender to indicate a named group of recipients. This is done by giving a display name for the group, followed by a colon, followed by a comma separated list of any number of mailboxes (including zero and one), and ending with a semicolon. Because the list of mailboxes can be empty, using the group construct is also a simple way to communicate to recipients that the message was sent to one or more named sets of recipients, without actually providing the individual mailbox address for each of those recipients. いくつかのメールボックスを1つの単位として扱うことが好ましい時(例えば 配送リスト)、グループ構成を使うことができる。グループ構成では、差出人 が名前のついた受取人グループを名乗ることが許されている。これはグループ につけたdisplay name、続けてコロン、続けてメールボックスのコンマで分け られたリスト(0,1を含む)で、セミコロンで終わることで達成される。メー ルボックスのリストは空でもよい。よって、受取人のめいめいが個人のメール アドレスを本当に準備することなく、1つ、あるいはそれ以上の名前がついた 受取人の集合にメッセージを送るというような、受取人とコミュニケーション をとるのにグループ構成を使うのは簡単な方法である。 3.4.1. Addr-spec specification An addr-spec is a specific Internet identifier that contains a locally interpreted string followed by the at-sign character ("@", ASCII value 64) followed by an Internet domain. The locally interpreted string is either a quoted-string or a dot-atom. If the string can be represented as a dot-atom (that is, it contains no characters other than atext characters or "." surrounded by atext (p17) characters), then the dot-atom form SHOULD be used and the quoted-string form SHOULD NOT be used. Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec. addr-specの規定 addr-specはローカルで解釈される文字列、続いて@マーク("@", アスキーコー ド64)、続いてインターネットドメインを持つ、固有のインターネットでの識 別名である。ローカルで解釈される文字列はquoted-stringまたはdot-atomの いずれかである。その文字列がdot-atomとして表現され得るならば(つまり、 atextとatextに囲まれた「.」以外の文字が存在しないならば)、dot-atom形 式が使われるべき(SHOULD)であり、quoted-string形式は使われるべきではな い。コメントやfoldingホワイトスペースはaddr-spec中、"@"の周りに使うべ きではない(SHOULD NOT)。 addr-spec = local-part "@" domain local-part = dot-atom / quoted-string / obs-local-part domain = dot-atom / domain-literal / obs-domain domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS] dcontent = dtext / quoted-pair dtext = NO-WS-CTL / ; Non white space controls %d33-90 / ; The rest of the US-ASCII %d94-126 ; characters not including "[", ; "]", or "\" The domain portion identifies the point to which the mail is delivered. In the dot-atom form, this is interpreted as an Internet domain name (either a host name or a mail exchanger name) as described in [STD3, STD13, STD14]. In the domain-literal form, the domain is interpreted as the literal Internet address of the particular host. In both cases, how addressing is used and how messages are transported to a particular host is covered in the mail transport document [RFC2821]. These mechanisms are outside of the scope of this document. ドメインの部分は、そのメールが配送される先を明らかにする。dot-item形式 において、これは[STD3, STD13, STD14]にあるインターネットドメイン名とし て解釈される(ホストネームかメールエクスチェンジャーの名前)。 domain-literal形式では、ドメインは文字通り、特定ホストのインターネット アドレスとして解釈される。いずれの場合においても、メッセージがどのよう に宛名が使われるか、どのように特定ホストに配送されるかはメール配送に関 する文書[RFC2821]でカバーされている。これらのしくみはこの文書の範囲外 である。 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. local-partの部分はドメインに依存する文字列である。特定のメールボックス として、特定のホスト上で解釈されるだけである。 3.5 Overall message syntax A message consists of header fields, optionally followed by a message body. Lines in a message MUST be a maximum of 998 characters excluding the CRLF, but it is RECOMMENDED that lines be limited to 78 characters excluding the CRLF. (See the note in section 2.1 for explanation.) In a message body, though all of the characters listed in the text rule MAY be used, the use of US-ASCII control characters (values 1 through 8, 11, 12, and 14 through 31) is discouraged since their interpretation by receivers for display is not guaranteed. 総合的なメッセージの構文 メッセージはヘッダフィールドと、オプションでそれに続くメッセージボディ とから成り立っている。メッセージ中の各行はCRLFを除き998文字を上限とし なければならない(MUST)が、CRLFを除き78文字に制限されるのが望ましい (RECOMMENDED)(説明はセクション2.1の注意を見よ)。メッセージボディにお いては、テキストのルールにあるすべての文字を使える(MAY)が、受け取り側 の表示上の解釈が保証されないので、US-ASCIIのコントロール文字(アスキー コード1〜8, 11, 12, 14〜31)はやめておく。 (p18) message = (fields / obs-fields) [CRLF body] body = *(*998text CRLF) *998text The header fields carry most of the semantic information and are defined in section 3.6. The body is simply a series of lines of text which are uninterpreted for the purposes of this standard. ヘッダフィールドは意味上の情報のほとんどを持ち、セクション3.6で定義さ れる。ボディは単にこの標準の目的によって解釈されない、テキストの行の単 なる連なりである。 3.6. Field definitions The header fields of a message are defined here. All header fields have the same general syntactic structure: A field name, followed by a colon, followed by the field body. The specific syntax for each header field is defined in the subsequent sections. フィールドの定義 メッセージのヘッダフィールドはここで定義されている。すべてのヘッダフィー ルドは同一の、一般的な構文構造を持つ:フィールド名、続けてコロン、続け てフィールドボディである。それぞれのヘッダフィールドにおける特殊な構文 は、後のセクションで定義する。 Note: In the ABNF syntax for each field in subsequent sections, each field name is followed by the required colon. However, for brevity sometimes the colon is not referred to in the textual description of the syntax. It is, nonetheless, required. 注意:後のセクションにおけるそれぞれのフィールドのためのABNF構文で、そ れぞれのフィールド名の後にコロンが必要である。しかしながら、簡潔にする ためにときとしてコロンが本文の構文記述中、書かれていないことがある。そ れはそれでもなお、必要である。 It is important to note that the header fields are not guaranteed to be in a particular order. They may appear in any order, and they have been known to be reordered occasionally when transported over the Internet. However, for the purposes of this standard, header fields SHOULD NOT be reordered when a message is transported or transformed. More importantly, the trace header fields and resent header fields MUST NOT be reordered, and SHOULD be kept in blocks prepended to the message. See sections 3.6.6 and 3.6.7 for more information. ヘッダフィールドが特定の順序で書かれているわけではないことに注意するこ とは、重要である。それらはどんな順番で出てきても構わないし、インターネッ トで配送中、時として順序が変わってしまうことが知られている。しかしなが ら、この標準の目的からして、ヘッダフィールドは配送や変形によって順序を 変えられるべきでない(SHOULD NOT)。より重要なことに、trace header field (Received のようなもの)とresent header fieldは決して順序を変えてはな らず(MUST NOT)、メッセージの前に付加されるかたまりに保存されるべきであ る(SHOULD)。さらなる情報はセクション3.6.6と3.6.7を見よ。 The only required header fields are the origination date field and the originator address field(s). All other header fields are syntactically optional. More information is contained in the table following this definition. 必須のヘッダフィールドは、起点のdateフィールドと最初にメッセージを作っ た人のaddressフィールドである。他のヘッダフィールドは、構文上オプショ ンである。さらなる情報はこの定義に続く表にある。 fields = *(trace *(resent-date / resent-from / resent-sender / resent-to / resent-cc / resent-bcc / resent-msg-id)) *(orig-date / from / sender / reply-to / (p19) to / cc / bcc / message-id / in-reply-to / references / subject / comments / keywords / optional-field) The following table indicates limits on the number of times each field may occur in a message header as well as any special limitations on the use of those fields. An asterisk next to a value in the minimum or maximum column indicates that a special restriction appears in the Notes column. 下記の表では、それぞれのフィールドが何回メッセージヘッダに現れることが 許されているか、またそれらのフィールドの利用に特殊な制限があるかを示し ている。最大、最小を示すカラムの値の横に付いたアスタリスクは、備考欄に 特別な制限があることを示している。 (表は備考:Noteのみ和訳) Field Min number Max number Notes trace 0 unlimited Block prepended - see 3.6.7 前置されるブロックー3.6.7を見よ。 resent-date 0* unlimited* One per block, required if other resent fields present - see 3.6.6 ブロックごとに1つ、もし他のresentフィールドがあるなら必要ー3.6.6を見よ resent-from 0 unlimited* One per block - see 3.6.6 ブロックごとに1つ、3.6.6を見よ resent-sender 0* unlimited* One per block, MUST occur with multi-address resent-from - see 3.6.6 ブロックごとに1つ、multi-addressのresent-fromの場合に必須(MUST)、3.6.6を見よ resent-to 0 unlimited* One per block - see 3.6.6 ブロックごとに1つ、3.6.6を見よ resent-cc 0 unlimited* One per block - see 3.6.6 ブロックごとに1つ、3.6.6を見よ resent-bcc 0 unlimited* One per block - see 3.6.6 ブロックごとに1つ、3.6.6を見よ resent-msg-id 0 unlimited* One per block - see 3.6.6 ブロックごとに1つ、3.6.6を見よ orig-date 1 1 from 1 1 See sender and 3.6.2 senderと3.6.2を見よ (p20) sender 0* 1 MUST occur with multi- address from - see 3.6.2 fromがmulti-addressのとき必須(MUST)、3.6.2を見よ reply-to 0 1 to 0 1 cc 0 1 bcc 0 1 message-id 0* 1 SHOULD be present - see 3.6.4 存在するべき(SHOULD)、3.6.4を見よ in-reply-to 0* 1 SHOULD occur in some replies - see 3.6.4 返信にはあるべき(SHOULD)、3.6.4を見よ references 0* 1 SHOULD occur in some replies - see 3.6.4 返信にはあるべき(SHOULD)、3.6.4を見よ subject 0 1 comments 0 unlimited keywords 0 unlimited optional-field 0 unlimited The exact interpretation of each field is described in subsequent sections. 各フィールドの正確な解釈については続くセクションで示す。 3.6.1. The origination date field The origination date field consists of the field name "Date" followed by a date-time specification. もともとの日時のフィールド メールが発信されたもともとの日時のフィールドは、フィールド名"Date"、続 いてdate-timeでの規定からなる。 orig-date = "Date:" date-time CRLF The origination date specifies the date and time at which the creator of the message indicated that the message was complete and ready to enter the mail delivery system. For instance, this might be the time that a user pushes the "send" or "submit" button in an application program. In any case, it is specifically not intended to convey the time that the message is actually transported, but rather the time at which the human or other creator of the message has put the message into its final form, ready for transport. (For example, a portable computer user who is not connected to a network might queue a message (p21) for delivery. The origination date is intended to contain the date and time that the user queued the message, not the time when the user connected to the network to send the message.) もともとの日時は、メッセージが完成し、メール配送システムに投入する準備 ができた、とメッセージの著者が示す日付と時間を明記する。例えば、これは ユーザがアプリケーションプログラムにおいて「送る」や「提出」ボタンを押 した時間かもしれない。いかなる場合でも、特にメッセージが実際に配送され ている時間を含むことを意味せず、むしろ人またはメッセージの人以外の著者 がメッセージを最終形にした、配送の準備ができたという時間を示す。(例え ば、ネットワークに接続されていない携帯型コンピュータの利用者は、メッセー ジを配送のためにキューに貯めるかもしれない。もともとの日時はユーザがメッ セージをキューにためた日時を示し、ユーザがメッセージを送信するためにネッ トワークに接続した時間を示さない)。 3.6.2. Originator fields The originator fields of a message consist of the from field, the sender field (when applicable) and optionally the reply-to field. The from field consists of the field name "From" and a comma-separated list of one or more mailbox specifications. If the from field contains more than one mailbox specification in the mailbox-list, then the sender field, containing the field name "Sender" and a single mailbox specification, MUST appear in the message. In either case, an optional reply-to field MAY also be included, which contains the field name "Reply-To" and a comma-separated list of one or more addresses. 差出人のフィールド メッセージの差出人のフィールドはfromフィールド, senderフィールド(適用 されるなら)、オプションのreply-toフィールドからなる。fromフィールドは フィールド名"From"と、コンマで分けられた1つまたはより多くのメールボッ クスを列挙したリストからなる。もし、fromフィールドがメールボックスリス トにおいて1つより多いメールボックスを列挙しているならば、senderフィー ルド、これはフィールド名"Sender"と1つのメールボックスを特定したもの、 がメッセージ中に現れなければならない(MUST)。いずれの場合でも、オプショ ンのreply-toフィールドが含まれてもよい(MAY)が、それはフィールド名 "Reply-To"とコンマで区切られた1,ないし複数のアドレスのリストである。 from = "From:" mailbox-list CRLF sender = "Sender:" mailbox CRLF reply-to = "Reply-To:" address-list CRLF The originator fields indicate the mailbox(es) of the source of the message. The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the "Sender:" field and the mailbox of the actual author would appear in the "From:" field. If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD appear. 差出人フィールドはメッセージの発生したメールボックスを示す。From: フィー ルドはメッセージの著者を示し、つまりメッセージを書いたことに対して責任 を持つ人かシステムのメールボックスである。"sender:"フィールドは、メッ セージの実際の送信に責任を持つ代理人のメールボックスを示す。例えば、も し秘書が別の人にメッセージを送ったなら、秘書のメールボックスが "Sender:"フィールドに現れ、本当の著者のメールボックスが"From"に現れる。 もしメッセージの差出人が単一のメールボックスであることが示され、かつ著 者と送信者が同じ場合、"Sender:"フィールドは使われるべきではない(SHOULD NOT)。そうでなければ、両方のフィールドは現れるべきである(SHOULD)。 The originator fields also provide the information required when replying to a message. When the "Reply-To:" field is present, it indicates the mailbox(es) to which the author of the message suggests that replies be sent. In the absence of the "Reply-To:" field, replies SHOULD by default be sent to the mailbox(es) specified in the "From:" field unless otherwise specified by the person composing the reply. 差出人フィールドはまた、メッセージを返信するときに必要な情報を提供する。 "Reply-To"フィールドが存在するとき、メッセージの著者が返信を送る先とし て提案するメールボックスを示す。Reply-Toフィールドが存在しないならば、 返信を書く人が異なるように指定しない限り、デフォルトではfromフィールド で指定されるメールボックスへ返信するべきである(SHOULD)。 In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message. See also section 3.6.3 for more information on forming the destination addresses for a reply. どの場合でも、"From"はメッセージの著者に属さないメールボックスを含むべ きではない(SHOULD NOT)。返信のための宛先を得るより多くの情報はセクショ ン3.6.3を見よ。 (p22) 3.6.3. Destination address fields The destination fields of a message consist of three possible fields, each of the same form: The field name, which is either "To", "Cc", or "Bcc", followed by a comma-separated list of one or more addresses (either mailbox or group syntax). 宛先フィールド メッセージの宛先フィールドは3種のフィールドの可能性があり、それぞれ同 じ形をしている:フィールド名である"To", "Cc", "Bcc"のいずれか、続いて コンマで区切られた1つないし複数のアドレス(メールボックス或いはグルー プ構文)のリストである。 to = "To:" address-list CRLF cc = "Cc:" address-list CRLF bcc = "Bcc:" (address-list / [CFWS]) CRLF The destination fields specify the recipients of the message. Each destination field may have one or more addresses, and each of the addresses indicate the intended recipients of the message. The only difference between the three fields is how each is used. 宛先フィールドはメッセージの受取人を示す。それぞれの宛先フィールドは1 つないし複数のアドレスを持つかもしれず、また各アドレスはメッセージを受 け取るであろう人を示す。この3つのフィールドの唯一の違いは、それぞれが いかにして使われるかである。 The "To:" field contains the address(es) of the primary recipient(s) of the message. "To:"フィールドはメッセージの主たる受取人のアドレスを持つ。 The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of making a copy on a typewriter using carbon paper) contains the addresses of others who are to receive the message, though the content of the message may not be directed at them. "Cc:"フィールド(ここで"Cc"は、タイプライターでカーボン紙を使ってコピー を作るという、カーボンコピーを意味する)は、メッセージの内容が彼らに向 けられたものではないかもしれないが、受け取るべき他の人のアドレスからな る。 The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains addresses of recipients of the message whose addresses are not to be revealed to other recipients of the message. There are three ways in which the "Bcc:" field is used. In the first case, when a message containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is removed even though all of the recipients (including those specified in the "Bcc:" field) are sent a copy of the message. In the second case, recipients specified in the "To:" and "Cc:" lines each are sent a copy of the message with the "Bcc:" line removed as above, but the recipients on the "Bcc:" line get a separate copy of the message containing a "Bcc:" line. (When there are multiple recipient addresses in the "Bcc:" field, some implementations actually send a separate copy of the message to each recipient with a "Bcc:" containing only the address of that particular recipient.) Finally, since a "Bcc:" field may contain no addresses, a "Bcc:" field can be sent without any addresses indicating to the recipients that blind copies were sent to someone. Which method to use with "Bcc:" fields is implementation dependent, but refer to the "Security Considerations" section of this document for a discussion of each. "Bcc:"フィールド(ここで"Bcc"はブラインドカーボンコピー)は、このメッ セージの他の受取人に対して公表すべきでない受取人のアドレスを持つ。 "Bcc"フィールドの使用には3つの方法がある。最初は、Bccフィールドを持つ メッセージの送信準備が出来たとき、すべての受取人(Bccフィールドで指定 したものも含む)にメッセージのコピーが送られるが、Bccの行が削除される。 2つめの場合、ToやCcで指定した行で規定される受取人それぞれは上記と同じ く、Bcc:の行が消されたメッセージのコピーを受け取るが、Bcc行にある受取 人はBcc行を含むメッセージの別のコピーを受け取る。(Bccフィールドに複数 の受取人アドレスがあるなら、いくつかの実装では実際、その特定の受取人の アドレスだけを含む、それぞれの受取人への別々のメッセージのコピーを送る) 最後に、Bccフィールドはアドレスを持っていないかもしれないので、ブライ ンドコピーが誰かにおくられたということを受取人に示さず、アドレスなしの Bccフィールドとして送られる。Bccの利用をいずれの方法で行うかは実装依存 だが、この文書の「セキュリティに関する考察」のセクションをめいめいの議 論のために参照せよ。 (p23) When a message is a reply to another message, the mailboxes of the authors of the original message (the mailboxes in the "From:" field) or mailboxes specified in the "Reply-To:" field (if it exists) MAY appear in the "To:" field of the reply, since these would normally be the primary recipients of the reply. If a reply is sent to a message that has destination fields, it is often desirable to send a copy of the reply to all of the recipients of the message, in addition to the author. When such a reply is formed, addresses in the "To:" and "Cc:" fields of the original message MAY appear in the "Cc:" field of the reply, since these are normally secondary recipients of the reply. If a "Bcc:" field is present in the original message, addresses in that field MAY appear in the "Bcc:" field of the reply, but SHOULD NOT appear in the "To:" or "Cc:" fields. メッセージが別のメッセージのリプライ(返信)であるとき、大元のメッセー ジの著者のメールボックス(Fromフィールドにあるメールボックス)あるいは (存在するなら)Reply-To フィールドに規定されたメールボックスがリプラ イのToフィールドにあらわれてもよい(MAY)。というのは、それがリプライの 第一の受取人として一般的であろうからだ。もし宛先フィールドを持つメッセー ジへの返信ならば、しばしば、著者に加えてメッセージの受取人すべてへリプ ライのコピーを送信することが要求される。そのようなリプライが作られたと き、元々のメッセージにおけるTo:やCc:フィールドに書かれたアドレスは、そ れらが一般にリプライの従の受取人であるから、Cc:フィールドにあらわれて もよい(MAY)。もしもともとのメッセージにBcc:が存在するなら、返信のBccに あらわれてもよい(MAY)が、ToやCcフィールドに現れるべきではない(SHOULD NOT)。 Note: Some mail applications have automatic reply commands that include the destination addresses of the original message in the destination addresses of the reply. How those reply commands behave is implementation dependent and is beyond the scope of this document. In particular, whether or not to include the original destination addresses when the original message had a "Reply-To:" field is not addressed here. 注意:いくつかのメールアプリケーションは、リプライの宛先アドレスにもと もとのメッセージの宛先アドレスを入れるような自動のリプライコマンドを持っ ている。どのようにそれらのリプライコマンドが振る舞うかは実装依存であり、 この文書の範囲にない。特に、もともとのメッセージがReply-To:フィールド を持っているときに、もともとの宛先アドレスを含むかどうかは、ここに書い ていない。 3.6.4. Identification fields Though optional, every message SHOULD have a "Message-ID:" field. Furthermore, reply messages SHOULD have "In-Reply-To:" and "References:" fields as appropriate, as described below. 同一性に関するフィールド オプションではあるが、すべてのメッセージは「Message-ID」フィールドを持 つべきである(SHOULD)。加えて、返信のメッセージは「In-Reply-To:」と 「References:」フィールドを後に記述する通り、適切に持つべきである (SHOULD)。 The "Message-ID:" field contains a single unique message identifier. The "References:" and "In-Reply-To:" field each contain one or more unique message identifiers, optionally separated by CFWS. 「Message-ID:」フィールドは1つのユニークなメッセージ識別名を含む。 「References:」と「In-Reply-To:」フィールドはそれぞれ、1つまたはそれ 以上のユニークなメッセージ識別名を持ち、オプションでCFWSで区切られる。 The message identifier (msg-id) is similar in syntax to an addr-spec construct enclosed in the angle bracket characters, "<" and ">", without the internal CFWS. メッセージ識別名(msg-id)は構文上、かぎかっこ、"<"と">"に囲まれ、内部に CFWSを持たないというaddr-specに似ている。 message-id = "Message-ID:" msg-id CRLF in-reply-to = "In-Reply-To:" 1*msg-id CRLF references = "References:" 1*msg-id CRLF msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] id-left = dot-atom-text / no-fold-quote / obs-id-left id-right = dot-atom-text / no-fold-literal / obs-id-right (p24) no-fold-quote = DQUOTE *(qtext / quoted-pair) DQUOTE no-fold-literal = "[" *(dtext / quoted-pair) "]" The "Message-ID:" field provides a unique message identifier that refers to a particular version of a particular message. The uniqueness of the message identifier is guaranteed by the host that generates it (see below). This message identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one instantiation of a particular message; subsequent revisions to the message each receive new message identifiers. 「Message-ID」フィールドは、固有のメッセージの固有の版を示すユニークな メッセージ識別名を提供する。メッセージ識別名がユニークであることは、そ れを生成した(以下を見よ)ホストによって保証される。メッセージ識別名は コンピュータが読めるような性質のものであり、人間にとって必要で意味のあ るものではない。1つのメッセージ識別名は、正確に1つのメッセージの1つ の実物に属する;メッセージへの続く校正それぞれで新しいメッセージ識別名 を持つ。 Note: There are many instances when messages are "changed", but those changes do not constitute a new instantiation of that message, and therefore the message would not get a new message identifier. For example, when messages are introduced into the transport system, they are often prepended with additional header fields such as trace fields (described in section 3.6.7) and resent fields (described in section 3.6.6). The addition of such header fields does not change the identity of the message and therefore the original "Message-ID:" field is retained. In all cases, it is the meaning that the sender of the message wishes to convey (i.e., whether this is the same message or a different message) that determines whether or not the "Message-ID:" field changes, not any particular syntactic difference that appears (or does not appear) in the message. 注意:メッセージが「変わる」とき多くの段階があるが、それらの変化はその メッセージの新しい実物ではなく、つまりメッセージは新しいメッセージ識別 名を持たない。例えば、メッセージが配送システムに提出されたとき、トレー スフィールド(セクション3.6.7で記述)やリセントフィールド(セクション 3.6.6で記述)のような追加のヘッダフィールドがしばしば前に付加される。 そのような追加のヘッダフィールドによって、メッセージの同一性は変わらず、 つまり元々の「Message-ID:」フィールドが保持される。すべての場合におい て、「Message-ID:」フィールドを変更するかどうか決定したメッセージの送 り手が、運搬すること望むことは(つまりこれが同じメッセージか違うメッセー ジか)意味上の問題であり、メッセージ中に特に構文上の違いが現れる(ある いは現れない)ということはない。 The "In-Reply-To:" and "References:" fields are used when creating a reply to a message. They hold the message identifier of the original message and the message identifiers of other messages (for example, in the case of a reply to a message which was itself a reply). The "In-Reply-To:" field may be used to identify the message (or messages) to which the new message is a reply, while the "References:" field may be used to identify a "thread" of conversation. 「In-Reply-To:」や「References:」フィールドは、メッセージへの返信を作 るときに使われる。それらはもとのメッセージや他のメッセージのメッセージ 識別名を持つ(例えば、返信メッセージそれ自身が返信メッセージである場合)。 「In-Reply-To:」フィールドは、新しいメッセージが返信する元のメッセージ を示し、「References:」フィールドは会話の「スレッド」を識別するために 使われるかもしれない。 When creating a reply to a message, the "In-Reply-To:" and "References:" fields of the resultant message are constructed as follows: メッセージへの返信を作るとき、作られるメッセージの「In-Reply-To:」や 「References:」フィールドは以下のようにして作られる: The "In-Reply-To:" field will contain the contents of the "Message- ID:" field of the message to which this one is a reply (the "parent message"). If there is more than one parent message, then the "In- Reply-To:" field will contain the contents of all of the parents' "Message-ID:" fields. If there is no "Message-ID:" field in any of the parent messages, then the new message will have no "In-Reply-To:" field. 「In-Reply-To:」フィールドは、このメッセージがリプライする元のメッセー ジ(親メッセージ)の「Message-ID:」フィールドの内容を持つ。もし複数の 親メッセージがあるなら、「In-Reply-To:」フィールドはすべての親メッセー ジの「Message-ID:」フィールドの内容を持つ。もしどの親メッセージにも 「Message-ID:」フィールドがないなら、新しいメッセージは「In-Reply-To:」 フィールドを持たない。 (p25) The "References:" field will contain the contents of the parent's "References:" field (if any) followed by the contents of the parent's "Message-ID:" field (if any). If the parent message does not contain a "References:" field but does have an "In-Reply-To:" field containing a single message identifier, then the "References:" field will contain the contents of the parent's "In-Reply-To:" field followed by the contents of the parent's "Message-ID:" field (if any). If the parent has none of the "References:", "In-Reply-To:", or "Message-ID:" fields, then the new message will have no "References:" field. 「References:」フィールドは、親メッセージの「References:」フィールドの 内容(あるなら)、続けて親メッセージの「Message-ID:」フィールドの内容 (あるなら)を持つ。もしおやめセージが「References:」フィールドを持た ず、1つのメッセージ識別名を持つ「In-Reply-To:」フィールドがあるなら、 そのときは「References:」フィールドは親の「In-Reply-To:」フィールドの 内容に続けて、親の「Message-ID:」フィールドの内容(あるなら)を持つ。 もし親が「Refernces:」、「In-Reply-To:」、「Message-ID:」いずれのフィー ルドも持たないなら、そのときは新しいメッセージは「References:」フィー ルドを持たない。 Note: Some implementations parse the "References:" field to display the "thread of the discussion". These implementations assume that each new message is a reply to a single parent and hence that they can walk backwards through the "References:" field to find the parent of each message listed there. Therefore, trying to form a "References:" field for a reply that has multiple parents is discouraged and how to do so is not defined in this document. 注意:いくつかの実装では「References:」フィールドを議論のスレッドを示 すのに解析する。これらの実装では、それぞれの新しいメッセージは1つの親 への返信であり、よって「References:」フィールドにあるそれぞれのメッセー ジの親は、「References:」フィールドを辿って戻れると仮定している。よっ て、1つの返信で複数の親を持つ「References:」フィールドを作る試みは思 いとどまるべきで、どうすればいいかはこの文書にはかいていない。 The message identifier (msg-id) itself MUST be a globally unique identifier for a message. The generator of the message identifier MUST guarantee that the msg-id is unique. There are several algorithms that can be used to accomplish this. Since the msg-id has an similar syntax to addr-spec (identical except that comments and folding white space are not allowed), a good method is to put the domain name (or a domain literal IP address) of the host on which the message identifier was created on the right hand side of the "@", and put a combination of the current absolute date and time along with some other currently unique (perhaps sequential) identifier available on the system (for example, a process id number) on the left hand side. Using a date on the left hand side and a domain name or domain literal on the right hand side makes it possible to guarantee uniqueness since no two hosts use the same domain name or IP address at the same time. Though other algorithms will work, it is RECOMMENDED that the right hand side contain some domain identifier (either of the host itself or otherwise) such that the generator of the message identifier can guarantee the uniqueness of the left hand side within the scope of that domain. メッセージ識別名(msg-id)それ自身は、1つのメッセージの世界レベルでの ユニークな識別名でなければならない(MUST)。メッセージ識別名を生成するシ ステムは、msg-idがユニークであることを保証せねばならない(MUST)。これを 達成するために使えるいくつかのアルゴリズムがある。msg-idはaddr-specと にた構文であることから(コメントとFWSが認められない点を除いて同じ)、 メッセージ識別名が作られたホストのドメイン名(または正確なIP address) を、「@」の右側におき、いくつかの現在のユニークな(おそらくシーケンシャ ルな)システム上利用可能な識別子(例えばプロセスのid)に加えて、現在の 絶対的な日時を左側に置くのはよい方法である。左手に日付、右手にドメイン 名かドメインリテラルを使うことで、2つのホストが同時に、同一のドメイン 名やIPアドレスを持つことがないから、ユニークさを保証することが可能とな る。他のアルゴリズムも働くだろうが、そのドメインの範囲内で左手のユニー クさを保証できるため、右手にメッセージ識別名を生成したシステムがドメイ ン識別子(ホストそのものか、それ以外いずれか)を持つことが推奨される (RECOMMENDED)。 Semantically, the angle bracket characters are not part of the msg-id; the msg-id is what is contained between the two angle bracket characters. 語義上、かぎかっこ(<>)はmsg-idの一部ではない;msg-idは2つのかぎ括弧に 囲まれたものである。 (p26) 3.6.5. Informational fields The informational fields are all optional. The "Keywords:" field contains a comma-separated list of one or more words or quoted-strings. The "Subject:" and "Comments:" fields are unstructured fields as defined in section 2.2.1, and therefore may contain text or folding white space. 情報フィールド 情報フィールドはすべてオプションである。「Keywords:」フィールドは1つ またはそれ以上の単語または引用された文字列のコンマで分けられたリストを 含む。「Subject:」と「Comments:」フィールドはセクション2.2.1で定義され た、構造化されないフィールドであり、すなわちテキストかFWSを含むかもし れない。 subject = "Subject:" unstructured CRLF comments = "Comments:" unstructured CRLF keywords = "Keywords:" phrase *("," phrase) CRLF These three fields are intended to have only human-readable content with information about the message. The "Subject:" field is the most common and contains a short string identifying the topic of the message. When used in a reply, the field body MAY start with the string "Re: " (from the Latin "res", in the matter of) followed by the contents of the "Subject:" field body of the original message. If this is done, only one instance of the literal string "Re: " ought to be used since use of other strings or more than one instance can lead to undesirable consequences. The "Comments:" field contains any additional comments on the text of the body of the message. The "Keywords:" field contains a comma-separated list of important words and phrases that might be useful for the recipient. これらの3つのフィールドは、メッセージについて、単に人がよめる情報の内 容を持つ目的がある。「Subject:」フィールドはもっとも一般的で、メッセー ジのトピックを識別する短い文字列を持つ。返信で使われると、そのフィール ドボディは「Re:」(ラテン語の「res」、「〜について」から)で始まるかも しれない(MAY)。もしこれがなされるなら、他の文字列や1つより多くの使用 は好ましくない結果をもたらすので、文字列「Re:」はたった1つだけ、使わ れるべきである。「Comments:」フィールドは、メッセージボディのテキスト への追加のコメントを含む。「Keywords:」フィールドは、受取人にとって有 用かもしれない、重要な単語やフレーズのコンマで分けられたリストを含む。 3.6.6. Resent fields Resent fields SHOULD be added to any message that is reintroduced by a user into the transport system. A separate set of resent fields SHOULD be added each time this is done. All of the resent fields corresponding to a particular resending of the message SHOULD be together. Each new set of resent fields is prepended to the message; that is, the most recent set of resent fields appear earlier in the message. No other fields in the message are changed when resent fields are added. 再送フィールド 再送フィールドは、ユーザによって再び配送システムに提出されたいかなるメッ セージにも付加されるべきである(SHOULD)。独立した再送フィールドの1つが、 これがなされたときごとに付加されるべきである(SHOULD)。メッセージのある 再送に関するすべての再送フィールドのセットは一緒にあるべきである (SHOULD)。それぞれの新しいリセンドフィールドはメッセージに前置される; つまり、再送フィールドのセットのほとんどはメッセージに先に現れる。メッ セージの他のフィールドは、再送フィールドが加えられたとき変更されない。 Each of the resent fields corresponds to a particular field elsewhere in the syntax. For instance, the "Resent-Date:" field corresponds to the "Date:" field and the "Resent-To:" field corresponds to the "To:" field. In each case, the syntax for the field body is identical to the syntax given previously for the corresponding field. それぞれの再送フィールドは、構文上、他の特定のフィールドに相当する。例 えば、「Resent-Date:」フィールドは「Date:」フィールドに相当し、 「Resent-To:」フィールドは「To:」フィールドに相当する。それぞれの場合 において、フィールドボディの構文は、相当するフィールド用に以前あげた構 文と同じである;。 When resent fields are used, the "Resent-From:" and "Resent-Date:" fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent. "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be identical to "Resent-From:". 再送フィールドが使われる時、「Resent-From:」と「Resent-Date:」フィール ドは送信されねばならない(MUST)。「Resent-Message-ID:」フィールドは送信 されるべきである(SHOULD)。「Resent-Sender:」は、「Resent-Sender:」が 「Resent-From:」と同一ならばつかわれるべきではない(SHOULD NOT)。 (p27) resent-date = "Resent-Date:" date-time CRLF resent-from = "Resent-From:" mailbox-list CRLF resent-sender = "Resent-Sender:" mailbox CRLF resent-to = "Resent-To:" address-list CRLF resent-cc = "Resent-Cc:" address-list CRLF resent-bcc = "Resent-Bcc:" (address-list / [CFWS]) CRLF resent-msg-id = "Resent-Message-ID:" msg-id CRLF Resent fields are used to identify a message as having been reintroduced into the transport system by a user. The purpose of using resent fields is to have the message appear to the final recipient as if it were sent directly by the original sender, with all of the original fields remaining the same. Each set of resent fields correspond to a particular resending event. That is, if a message is resent multiple times, each set of resent fields gives identifying information for each individual time. Resent fields are strictly informational. They MUST NOT be used in the normal processing of replies or other such automatic actions on messages. 再送フィールドは、ユーザによって配送システムに再度提出されたメッセージ であることを識別するのに使われる。再送フィールドの使用目的は、すべての もともとのフィールドを同じに保ったまま、もとの送り手から直接送られたも のであるかのごとく、メッセージを最終の受取人に見せることである。それぞ れの再送フィールドのセットは、特定の再送イベントに相当する。つまり、1 つのメッセージが複数回再送されたなら、それぞれの再送フィールドのセット が、それぞれの時の情報を識別させる。再送フィールドは厳密に情報提供であ る。それは普通の返信の生成やメッセージ上の自動のアクションのようなもの に使ってはならない(MUST NOT)。 Note: Reintroducing a message into the transport system and using resent fields is a different operation from "forwarding". "Forwarding" has two meanings: One sense of forwarding is that a mail reading program can be told by a user to forward a copy of a message to another person, making the forwarded message the body of the new message. A forwarded message in this sense does not appear to have come from the original sender, but is an entirely new message from the forwarder of the message. On the other hand, forwarding is also used to mean when a mail transport program gets a message and forwards it on to a different destination for final delivery. Resent header fields are not intended for use with either type of forwarding. 注意:配送システムへのメッセージの再提出で再送フィールドを使うことは、 「forwarding」とは違う。「Forwarding」には2つの意味がある:forwarding の1つ目の意味は、メールを読むプログラムがユーザに別の人にメッセージの コピーを転送するよう命令されて、forwarded messageを新しいメッセージの ボディにするかもしれない。この意味でのforwarded messageはもともとの送 り手から送られることはなく、メッセージの転送者からのまったく新しいメッ セージである。他方、メール配送プログラムがメッセージを受け取り、最終の 配送先である別の宛先へと転送されるとき、forwardingはこの意味でも使われ る。再送ヘッダフィールドは、いずれのタイプのforwardingでも使われない。 The resent originator fields indicate the mailbox of the person(s) or system(s) that resent the message. As with the regular originator fields, there are two forms: a simple "Resent-From:" form which contains the mailbox of the individual doing the resending, and the more complex form, when one individual (identified in the "Resent-Sender:" field) resends a message on behalf of one or more others (identified in the "Resent-From:" field). 再送の発起人のフィールドは人のメールボックスまたは、メッセージを再送し たシステムを示す。正規の発起人のフィールドと共にあるので、2つの形式が ある:再送をした個人のメールボックスを持つ単純な「Resent-From:」と、 (Resent-Sender: フィールドで識別される)1個人が(Resent-From: フィールド で識別される)1ないし多数の者達の代表としてメッセージを再送するときの、 より複雑な形態である。 Note: When replying to a resent message, replies behave just as they would with any other message, using the original "From:", (p28) "Reply-To:", "Message-ID:", and other fields. The resent fields are only informational and MUST NOT be used in the normal processing of replies. 注意:再送メッセージへ返信するとき、返信は他のメッセージ、もともとの 「From:」、「Reply-To:」、「Message-ID:」、その他のフィールドを使った 他のメッセージであるかのように振る舞う。再送フィールドは単に情報を与え るだけで、普通の返信の生成において使ってはならない(MUST NOT)。 The "Resent-Date:" indicates the date and time at which the resent message is dispatched by the resender of the message. Like the "Date:" field, it is not the date and time that the message was actually transported. 「Resent-Date:」は、メッセージの再送者によって再送メッセージが発送され た日時を示す。「Date:」フィールドと同じく、メッセージが実際に配送され た日時ではない。 The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function identically to the "To:", "Cc:", and "Bcc:" fields respectively, except that they indicate the recipients of the resent message, not the recipients of the original message. 「Resent-To:」、「Resent-Cc:」、「Resent-Bcc:」フィールドは、オリジナ ルのメッセージでなく再送されたメッセージの受取人であることを示している ことの他は、「To:」、「Cc:」、「Bcc:」フィールドそれぞれと同等に機能す る。 The "Resent-Message-ID:" field provides a unique identifier for the resent message. 「Resent-Message-ID:」フィールドは再送メッセージのために、ユニークな識 別名を与える。 3.6.7. Trace fields The trace fields are a group of header fields consisting of an optional "Return-Path:" field, and one or more "Received:" fields. The "Return-Path:" header field contains a pair of angle brackets that enclose an optional addr-spec. The "Received:" field contains a (possibly empty) list of name/value pairs followed by a semicolon and a date-time specification. The first item of the name/value pair is defined by item-name, and the second item is either an addr-spec, an atom, a domain, or a msg-id. Further restrictions may be applied to the syntax of the trace fields by standards that provide for their use, such as [RFC2821]. トレースフィールド トレースフィールドはオプションで、1つの「Return-Path:」フィールドと1 つないし複数の「Received:」フィールドからなるヘッダフィールドのグルー プである。「Return-Path:」ヘッダフィールドはオプションでaddr-specを内 包したかぎかっこの組を持つ。「Received:」フィールドは名前と値の組のリ スト(空の可能性もある)、続いてセミコロン、日時の列挙である。名前と値 の組の最初の要素は要素名で定義され、2つめの要素はaddr-spec, atom, domain, msg-idのいずれかである。RFC2821のような、それらの利用を準備す る標準により、トレースフィールド構文へのさらなる規定は適用される。 trace = [return] 1*received return = "Return-Path:" path CRLF path = ([CFWS] "<" ([CFWS] / addr-spec) ">" [CFWS]) / obs-path received = "Received:" name-val-list ";" date-time CRLF name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)] name-val-pair = item-name CFWS item-value item-name = ALPHA *(["-"] (ALPHA / DIGIT)) item-value = 1*angle-addr / addr-spec / atom / domain / msg-id (p29) A full discussion of the Internet mail use of trace fields is contained in [RFC2821]. For the purposes of this standard, the trace fields are strictly informational, and any formal interpretation of them is outside of the scope of this document. トレースフィールドのインターネットメールでの利用の議論の全体はRFC2821 に含まれる。この標準の目的のため、トレースフィールドは厳密に情報提供で あり、その公式な解釈はこの文書の範囲外である。 3.6.8. Optional fields Fields may appear in messages that are otherwise unspecified in this standard. They MUST conform to the syntax of an optional-field. This is a field name, made up of the printable US-ASCII characters except SP and colon, followed by a colon, followed by any text which conforms to unstructured. オプションのフィールド この標準で規定されないフィールドがメッセージ中、現れるかもしれない。そ れらはオプションフィールドの構文に従わなければならない(MUST)。これは、 スペース、コロンを除いた印刷可能なUS-ASCII文字からなるフィールド名、続 いてコロン、続いて構造化されないものに従うテキストである。 The field names of any optional-field MUST NOT be identical to any field name specified elsewhere in this standard. オプションフィールドのフィールド名は、この文書の他の場所で規定されるい かなるフィールド名と同じであってはならない(MUST NOT)。 optional-field = field-name ":" unstructured CRLF field-name = 1*ftext ftext = %d33-57 / ; Any character except %d59-126 ; controls, SP, and ; ":". For the purposes of this standard, any optional field is uninterpreted. この標準の目的から、オプションフィールドは解釈されない。 4. Obsolete Syntax Earlier versions of this standard allowed for different (usually more liberal) syntax than is allowed in this version. Also, there have been syntactic elements used in messages on the Internet whose interpretation have never been documented. Though some of these syntactic forms MUST NOT be generated according to the grammar in section 3, they MUST be accepted and parsed by a conformant receiver. This section documents many of these syntactic elements. Taking the grammar in section 3 and adding the definitions presented in this section will result in the grammar to use for interpretation of messages. 時代遅れの構文 この標準の以前のバージョンでは、このバージョンで許可されたものと異なる (たいていより自由な)構文が許されていた。また、インターネットのメッセー ジで使われた、その解釈方法がかつて文書化されなかった構文要素がある。こ れらの構文形のいくつかは、セクション3の文法によって生成してはならない (MUST NOT)にもかかわらず、それらは受け取り、受取手によって構文解釈され ねばならない(MUST)。このセクションでは、これらの構文要素の多くを文書化 する。セクション3の文法を選び、このセクションにある定義を加えれば、メッ セージの解釈のために使われる文法が得られる。 Note: This section identifies syntactic forms that any implementation MUST reasonably interpret. However, there are certainly Internet messages which do not conform to even the additional syntax given in this section. The fact that a particular form does not appear in any section of this document is not justification for computer programs to crash or for malformed data to be irretrievably lost by any implementation. To repeat an example, though this document requires lines in messages to be no longer than 998 characters, silently (p31) discarding the 999th and subsequent characters in a line without warning would still be bad behavior for an implementation. It is up to the implementation to deal with messages robustly. 注意:このセクションでは、どの実装系でも妥当に解釈せねばならない(MUST) 構文形を鑑別する。しかしながら、このセクションであげた追加の構文にも従 わないインターネットメッセージが確かに存在する。特定の形がこの文書のど のセクションにも現れない、という事実は、コンピュータプログラムにとって、 暴走の弁明にならないし、どんな実装系であっても、奇形のデータにとって、 取り返しのつかない欠損の弁明にならない。例を繰り返すと、この文書ではメッ セージの1行に998文字より長くしないことを要求しているが、静かに、警告 なく行内の999番目以降の文字を捨ててしまうことは、実装にとっていまだ、 悪い振る舞いである。それは、メッセージを扱う実装のたくましさによる。 One important difference between the obsolete (interpreting) and the current (generating) syntax is that in structured header field bodies (i.e., between the colon and the CRLF of any structured header field), white space characters, including folding white space, and comments could be freely inserted between any syntactic tokens. This allowed many complex forms that have proven difficult for some implementations to parse. 時代遅れ(解釈する)と現在(生成する)の構文間の1つの重要な違いは、構 造化されたヘッダフィールドボディ(つまり、コロンと構造化されたヘッダフィー ルドのCRLFとの間)、FWSを含むホワイトスペース文字、コメントが構文上の トークンの間に自由に入れられるということである。これでは、いくつかの実 装で解釈が難しいと証明された、多くの複雑な形式が許される。 Another key difference between the obsolete and the current syntax is that the rule in section 3.2.3 regarding lines composed entirely of white space in comments and folding white space does not apply. See the discussion of folding white space in section 4.2 below. 時代遅れと現在の構文の別のかぎとなる違いは、セクション3.2.3にあるルー ルでは、コメント中のホワイトスペースを構成する行を尊重し、FWSには適用 しない。FWSの議論は以下セクション4.2を見よ。 Finally, certain characters that were formerly allowed in messages appear in this section. The NUL character (ASCII value 0) was once allowed, but is no longer for compatibility reasons. CR and LF were allowed to appear in messages other than as CRLF; this use is also shown here. 最後に、メッセージ中、かつて許可されていた文字が、このセクションにあら われる。NUL文字(ASCIIコード0)は一度許可されたが、もはや互換性の理由か ら許可されない。CRとLFはCRLF以外でメッセージに現れることが許される;こ の用法もまた、ここに挙げる。 Other differences in syntax and semantics are noted in the following sections. 他の構文上の違いは以下のセクションに記してある。 4.1. Miscellaneous obsolete tokens These syntactic elements are used elsewhere in the obsolete syntax or in the main syntax. The obs-char and obs-qp elements each add ASCII value 0. Bare CR and bare LF are added to obs-text and obs-utext. The period character is added to obs-phrase. 種々雑多な時代遅れのトークン これらの構文要素は時代遅れの構文と主たる構文以外の場所で使われる。 obs-charとobs-qpの要素それぞれに、アスキーコード0を加える。裸の(CRLFの 形でない)CRとLFをobs-textとobs-utextを加える。ピリオド文字を obs-phraseに加える。 Note: The "period" (or "full stop") character (".") in obs-phrase is not a form that was allowed in earlier versions of this or any other standard. Period (nor any other character from specials) was not allowed in phrase because it introduced a parsing difficulty distinguishing between phrases and portions of an addr-spec (see section 4.4). It appears here because the period character is currently used in many messages in the display-name portion of addresses, especially for initials in names, and therefore must be interpreted properly. In the future, period may appear in the regular syntax of phrase. 注意:obs-phrase中のピリオド文字(".")は、これ、あるいは別の標準の古 い版で許可された形式ではない。ピリオド(や他のspecialsにある文字)は、 それはphraseとaddr-specの部分とを見分ける構文解析を難しくする(セクショ ン4.4を見よ)ため、phrase中において許可されない。ピリオドは現在、多く のメッセージにおいてアドレスの一部の表示名、特に名前のイニシャルで使わ れ、それゆえ適切に解釈されねばならないため、それがここに現れている。将 来、ピリオドはphraseの正規の構文中に現れるかもしれない。 obs-qp = "\" (%d0-127) obs-text = *LF *CR *(obs-char *LF *CR) (p31) obs-char = %d0-9 / %d11 / ; %d0-127 except CR and %d12 / %d14-127 ; LF obs-utext = obs-text obs-phrase = word *(word / "." / CFWS) Bare CR and bare LF appear in messages with two different meanings. In many cases, bare CR or bare LF are used improperly instead of CRLF to indicate line separators. In other case, bare CR and bare LF are used simply as ASCII control characters with their traditional ASCII meanings. 裸のCRと裸のLFはメッセージ中、2つの異なった意味で現れる。多くの場合、 裸のCRと裸のLFは、行の分かれ目を示すためのCRLFの代わりに誤って用いられ る。別の場合、裸のCRと裸のLFは、単純にそれらの伝統的なASCIIの意味を持 つASCIIコントロール文字として使われる。 4.2. Obsolete folding white space In the obsolete syntax, any amount of folding white space MAY be inserted where the obs-FWS rule is allowed. This creates the possibility of having two consecutive "folds" in a line, and therefore the possibility that a line which makes up a folded header field could be composed entirely of white space. 時代遅れのfoldingのホワイトスペース 時代遅れの構文において、obs-FWSルールで許された場所に、foldingのホワイ トスペースを挿入してよい(MAY)。これにより、1行中2つの連続した「fold」 (折り返し)を持つ可能性があり、それゆえfoldingヘッダフィールドを作る 1つの行が、まったくホワイトスペースだけで形成される可能性がある。 obs-FWS = 1*WSP *(CRLF 1*WSP) 4.3. Obsolete Date and Time The syntax for the obsolete date format allows a 2 digit year in the date field and allows for a list of alphabetic time zone specifications that were used in earlier versions of this standard. It also permits comments and folding white space between many of the tokens. 時代遅れの日時 時代遅れの日付フォーマットの構文は、date フィールドに2桁の年を許し、 またこの標準の昔の版で使われたアルファベットによるタイムゾーンの特定が 許される。トークンの多くの間にコメントやfoldingのホワイトスペースも許 可される。 obs-day-of-week = [CFWS] day-name [CFWS] obs-year = [CFWS] 2*DIGIT [CFWS] obs-month = CFWS month-name CFWS obs-day = [CFWS] 1*2DIGIT [CFWS] obs-hour = [CFWS] 2DIGIT [CFWS] obs-minute = [CFWS] 2DIGIT [CFWS] obs-second = [CFWS] 2DIGIT [CFWS] obs-zone = "UT" / "GMT" / ; Universal Time ; North American UT ; offsets (p32) "EST" / "EDT" / ; Eastern: - 5/ - 4 "CST" / "CDT" / ; Central: - 6/ - 5 "MST" / "MDT" / ; Mountain: - 7/ - 6 "PST" / "PDT" / ; Pacific: - 8/ - 7 %d65-73 / ; Military zones - "A" %d75-90 / ; through "I" and "K" %d97-105 / ; through "Z", both %d107-122 ; upper and lower case Where a two or three digit year occurs in a date, the year is to be interpreted as follows: If a two digit year is encountered whose value is between 00 and 49, the year is interpreted by adding 2000, ending up with a value between 2000 and 2049. If a two digit year is encountered with a value between 50 and 99, or any three digit year is encountered, the year is interpreted by adding 1900. 2ないし3桁の年が日付に存在すると、その年は以下のように解釈される:も し2桁の年の数字が00〜49の値なら、年は2000を加算して解釈し、結果2000年〜 2049年となる。もし2桁の年の数字が50〜99の値なら、また3桁の年の数字な ら、その年は1900を加えたものとして解釈する。 In the obsolete time zone, "UT" and "GMT" are indications of "Universal Time" and "Greenwich Mean Time" respectively and are both semantically identical to "+0000". 時代遅れのタイムゾーン中、"UT"と"GMT"は「世界時間」と「グリニッジ標準 時」をそれぞれ表し、意味上、ともに"+0000"と同じである。 The remaining three character zones are the US time zones. The first letter, "E", "C", "M", or "P" stands for "Eastern", "Central", "Mountain" and "Pacific". The second letter is either "S" for "Standard" time, or "D" for "Daylight" (or summer) time. Their interpretations are as follows: 残る3つの文字によるゾーンはUSのタイムゾーンである。最初の文字、 "E","C","M","P"は「東部」「中央」「山岳」「太平洋」を示す。2つ目の文 字は標準を示す"S"か、日中(サマータイム)を示す"D"である。それらは以下 のように解釈される: EDT is semantically equivalent to -0400 EST is semantically equivalent to -0500 CDT is semantically equivalent to -0500 CST is semantically equivalent to -0600 MDT is semantically equivalent to -0600 MST is semantically equivalent to -0700 PDT is semantically equivalent to -0700 PST is semantically equivalent to -0800 EDTは-0400と同義である。 ESTは-0500と同義である。 CDTは-0500と同義である。 CSTは-0600と同義である。 MDTは-0600と同義である。 MSTは-0700と同義である。 PDTは-0700と同義である。 PSTは-0800と同義である。 The 1 character military time zones were defined in a non-standard way in [RFC822] and are therefore unpredictable in their meaning. The original definitions of the military zones "A" through "I" are equivalent to "+0100" through "+0900" respectively; "K", "L", and "M" are equivalent to "+1000", "+1100", and "+1200" respectively; "N" through "Y" are equivalent to "-0100" through "-1200" respectively; and "Z" is equivalent to "+0000". However, because of the error in [RFC822], they SHOULD all be considered equivalent to "-0000" unless there is out-of-band information confirming their meaning. 1文字の軍隊のタイムゾーンは、RFC822で非標準の方法で定義され、それゆえ その意味は予測不能である。軍のゾーン"A"から"I"のそもそもの定義は "+0100"から"+0900"それぞれと同じである;"K","L","M"はそれぞれ "+1000","+1100","+1200"と同義である;"N"から"Y"はそれぞれ"-0100"から "-1200"と同義である;そして"Z"は"+0000"と同じである。しかしながら、 RFC822の間違いのため、もしもその意味を確かめる情報がある場合以外は、す べて"-0000"と同じと考えるべきである(SHOULD)。 (p33) Other multi-character (usually between 3 and 5) alphabetic time zones have been used in Internet messages. Any such time zone whose meaning is not known SHOULD be considered equivalent to "-0000" unless there is out-of-band information confirming their meaning. 他の複数文字(普通3から5)のアルファベットのタイムゾーンがインターネッ トのメッセージで使われてきた。そのような、意味がわからないタイムゾーン は、その意味を確かめる情報がある場合以外は"-0000"と同じに考えるべきで ある(SHOULD)。 4.4. Obsolete Addressing There are three primary differences in addressing. First, mailbox addresses were allowed to have a route portion before the addr-spec when enclosed in "<" and ">". The route is simply a comma-separated list of domain names, each preceded by "@", and the list terminated by a colon. Second, CFWS were allowed between the period-separated elements of local-part and domain (i.e., dot-atom was not used). In addition, local-part is allowed to contain quoted-string in addition to just atom. Finally, mailbox-list and address-list were allowed to have "null" members. That is, there could be two or more commas in such a list with nothing in between them. 時代遅れのアドレス 3つの基本的な違いがある。まず、<と>に囲まれた時、メールボックスのアド レスがaddr-specの前に経路の部分を持つことが許されていた。経路は単にコ ンマで分けられた、それぞれ「@」に続くドメイン名のリストであり、コロン でリストが終わる。第2に、ピリオドで分けられたlocal-partやドメインの要 素の間に、CFWSが許されれていた(つまり、dot-atomが使われていなかった)。 加えて、local-partに、単なるatomに加えてquoted-stringを持つことが許さ れる。最後に、mailbox-listとaddress-listに空の(null)メンバーを持つこ とが許された。つまり、間に何もないようなリストに2つ以上のコンマがある 可能性がある。 obs-angle-addr = [CFWS] "<" [obs-route] addr-spec ">" [CFWS] obs-route = [CFWS] obs-domain-list ":" [CFWS] obs-domain-list = "@" domain *(*(CFWS / "," ) [CFWS] "@" domain) obs-local-part = word *("." word) obs-domain = atom *("." atom) obs-mbox-list = *([mailbox] [CFWS] "," [CFWS]) obs-addr-list = *([address] [CFWS] "," [CFWS]) When interpreting addresses, the route portion SHOULD be ignored. 4.5. Obsolete header fields Syntactically, the primary difference in the obsolete field syntax is that it allows multiple occurrences of any of the fields and they may occur in any order. Also, any amount of white space is allowed before the ":" at the end of the field name. 時代遅れのヘッダフィールド 構文的に、時代遅れのフィールドの文法における第一の違いは、いかなるフィー ルドも複数回存在することが許され、いかなる順番で出現してもよい、という ことである。また、フィールド名の終わりで「:」の前に任意個のホワイトス ペースが許される。 obs-fields = *(obs-return / obs-received / obs-orig-date / obs-from / obs-sender / obs-reply-to / obs-to / (p34) obs-cc / obs-bcc / obs-message-id / obs-in-reply-to / obs-references / obs-subject / obs-comments / obs-keywords / obs-resent-date / obs-resent-from / obs-resent-send / obs-resent-rply / obs-resent-to / obs-resent-cc / obs-resent-bcc / obs-resent-mid / obs-optional) Except for destination address fields (described in section 4.5.3), the interpretation of multiple occurrences of fields is unspecified. Also, the interpretation of trace fields and resent fields which do not occur in blocks prepended to the message is unspecified as well. Unless otherwise noted in the following sections, interpretation of other fields is identical to the interpretation of their non-obsolete counterparts in section 3. 宛先アドレスのフィールドを除いて(セクション4.5.3に記す)、複数回出現 したフィールドの解釈は規定されていない。また、トレースフィールドの解釈 と、メッセージに前置される形でブロックとなっては現れない再送フィールド も定義されない。続くセクションに他の注意がない限り、他のフィールドの解 釈はセクション3にある、時代遅れになっていない、よく似たフィールドと同 じである。 4.5.1. Obsolete origination date field obs-orig-date = "Date" *WSP ":" date-time CRLF 4.5.2. Obsolete originator fields obs-from = "From" *WSP ":" mailbox-list CRLF obs-sender = "Sender" *WSP ":" mailbox CRLF obs-reply-to = "Reply-To" *WSP ":" mailbox-list CRLF 4.5.3. Obsolete destination address fields obs-to = "To" *WSP ":" address-list CRLF obs-cc = "Cc" *WSP ":" address-list CRLF obs-bcc = "Bcc" *WSP ":" (address-list / [CFWS]) CRLF (p35) When multiple occurrences of destination address fields occur in a message, they SHOULD be treated as if the address-list in the first occurrence of the field is combined with the address lists of the subsequent occurrences by adding a comma and concatenating. 1つのメッセージに複数の宛先アドレスのフィールドが現れた場合、フィール ドの最初に現れるアドレスリストに、続いて現れるアドレスリストがコンマで 連結して結合されたかのように扱われねばならない(SHOULD)。 4.5.4. Obsolete identification fields The obsolete "In-Reply-To:" and "References:" fields differ from the current syntax in that they allow phrase (words or quoted strings) to appear. The obsolete forms of the left and right sides of msg-id allow interspersed CFWS, making them syntactically identical to local-part and domain respectively. 時代遅れの同定(identification)フィールド 時代遅れの「In-Reply-To:」や「References:」フィールドは、phrase(words や引用された文字列)が現れることが許される点で現在の文法と違う。時代遅 れとなったmsg-idの左側、また右側の形式はCFWSをちりばめることを許し、そ れぞれlocal-partとドメインと同じ文法となる。 obs-message-id = "Message-ID" *WSP ":" msg-id CRLF obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF obs-id-left = local-part obs-id-right = domain For purposes of interpretation, the phrases in the "In-Reply-To:" and "References:" fields are ignored. 解釈の目的から、「In-Reply-To:」と「References:」中のphraseは無視される。 Semantically, none of the optional CFWS surrounding the local-part and the domain are part of the obs-id-left and obs-id-right respectively. 文法上、local-partやドメインに囲まれたオプションのCFWSは、それぞれ obs-id-leftとobs-id-rightの一部ではない。 4.5.5. Obsolete informational fields obs-subject = "Subject" *WSP ":" unstructured CRLF obs-comments = "Comments" *WSP ":" unstructured CRLF obs-keywords = "Keywords" *WSP ":" *([phrase] ",") CRLF 4.5.6. Obsolete resent fields The obsolete syntax adds a "Resent-Reply-To:" field, which consists of the field name, the optional comments and folding white space, the colon, and a comma separated list of addresses. 時代遅れの再送フィールド 時代遅れの構文には「Resent-Reply-To:」が加わるが、それはフィールド名、 オプションのコメント、FWS、コロン、コンマで分けられたアドレスのリスト から成る。 obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF (p36) obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF obs-resent-to = "Resent-To" *WSP ":" address-list CRLF obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF obs-resent-bcc = "Resent-Bcc" *WSP ":" (address-list / [CFWS]) CRLF obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF As with other resent fields, the "Resent-Reply-To:" field is to be treated as trace information only. 他の再送フィールドと同様、「Resent-Reply-To:」フィールドは、トレースに 関する情報のみとして扱われるべきである。 4.5.7. Obsolete trace fields The obs-return and obs-received are again given here as template definitions, just as return and received are in section 3. Their full syntax is given in [RFC2821]. 時代遅れのトレースフィールド returnとreceivedをセクション3で提示したように、obs-returnと obs-receivedをテンプレートの定義としてここに再び挙げる。それらの完全な 構文はRFC2821で与えられる。 obs-return = "Return-Path" *WSP ":" path CRLF obs-received = "Received" *WSP ":" name-val-list CRLF obs-path = obs-angle-addr 4.5.8. Obsolete optional fields obs-optional = field-name *WSP ":" unstructured CRLF 5. Security Considerations Care needs to be taken when displaying messages on a terminal or terminal emulator. Powerful terminals may act on escape sequences and other combinations of ASCII control characters with a variety of consequences. They can remap the keyboard or permit other modifications to the terminal which could lead to denial of service or even damaged data. They can trigger (sometimes programmable) answerback messages which can allow a message to cause commands to be issued on the recipient's behalf. They can also effect the operation of terminal attached devices such as printers. Message viewers may wish to strip potentially dangerous terminal escape sequences from the message prior to display. However, other escape sequences appear in messages for useful purposes (cf. [RFC2045, RFC2046, RFC2047, RFC2048, RFC2049, ISO2022]) and therefore should not be stripped indiscriminately. セキュリティに関する考察 端末やターミナルエミュレータにメッセージを表示するとき、注意が必要であ る。強力な端末はエスケープシークエンスや、いろいろにつながった他のアス キーコントロール文字の組み合わせを実行できるかもしれない。それらはキー ボードのリマップや、サービス妨害やデータに障害を与えさえするようなター ミナルへのその他の変更が可能である。それは(時としてプログラム可能な)、 受取人の利益のためにコマンドを実行することをメッセージに許可できるよう な、返答メッセージのトリガーを引く可能性がある。それはまた、ターミナル に接続されたプリンターのような機器にも影響を与える。メッセージを見る人 は、潜在的に危険な端末から、表示する以上のメッセージからのエスケープシー クエンスを取り除くことを望むかもしれない。しかしながら、メッセージ中に 現れる他のエスケープシークエンスは有用な目的であり(RFC2045, RFC2046, RFC2047, RFC2048, RFC2049, ISO2022参照)、即ち無差別に取り除くべきでは ない。 (p37) Transmission of non-text objects in messages raises additional security issues. These issues are discussed in [RFC2045, RFC2046, RFC2047, RFC2048, RFC2049]. メッセージ中テキストでないものの伝達は、追加のセキュリティの問題を引き 起こす。これらについてはRFC2045, RFC2046, RFC2047, RFC2048, RFC2049に ある。 Many implementations use the "Bcc:" (blind carbon copy) field described in section 3.6.3 to facilitate sending messages to recipients without revealing the addresses of one or more of the addressees to the other recipients. Mishandling this use of "Bcc:" has implications for confidential information that might be revealed, which could eventually lead to security problems through knowledge of even the existence of a particular mail address. For example, if using the first method described in section 3.6.3, where the "Bcc:" line is removed from the message, blind recipients have no explicit indication that they have been sent a blind copy, except insofar as their address does not appear in the message header. Because of this, one of the blind addressees could potentially send a reply to all of the shown recipients and accidentally reveal that the message went to the blind recipient. When the second method from section 3.6.3 is used, the blind recipient's address appears in the "Bcc:" field of a separate copy of the message. If the "Bcc:" field sent contains all of the blind addressees, all of the "Bcc:" recipients will be seen by each "Bcc:" recipient. Even if a separate message is sent to each "Bcc:" recipient with only the individual's address, implementations still need to be careful to process replies to the message as per section 3.6.3 so as not to accidentally reveal the blind recipient to other recipients. 多くの実装では、他の受取人に、宛先のうちの1つないし複数のアドレスを見 せることなくメッセージを送るのを容易にするために、セクション3.6.3に記 したBcc:(ブラインドカーボンコピー)フィールドを使う。Bccのこの用法を 誤ることは、明かされるかもしれない内密の情報に密接なかかわりあいを持ち、 特別なメールアドレスの存在が知られることさえ、結果としてセキュリティの 問題を導く可能性がある。例えば、もしセクション3.6.3に記した最初の方法 を使っていると、"Bcc:"行がメッセージから取り除かれ、ブラインドの受取人 は、かれらのアドレスがメッセージヘッダに乗っていないということを除き、 それがブラインドコピーでおくられたというなんら明示的なしるしがない。こ のため、ブラインドで送られた受取人の一人が見える受取人全員に返答を送っ てしまい、事故でそのメッセージがブラインドの受取人へ送られたことが明ら かになってしまう可能性がある。もしBccフィールドがすべてのブラインドの 受取人に含まれるなら、すべてのBccの受取人は、それぞれのBccの受取人に知 られてしまうだろう。もし、別々のメッセージがBcc受取人のそれぞれに個人 のアドレスだけを書いて送られた場合であっても、依然、セクション3.6.3に あるように、ブラインドの受取人が他の受取人に事故で明らかになってしまわ ないよう、メッセージに返答を作成することに注意が必要である。 6. Bibliography [ASCII] American National Standards Institute (ANSI), Coded Character Set - 7-Bit American National Standard Code for Information Interchange, ANSI X3.4, 1986. [ISO2022] International Organization for Standardization (ISO), Information processing - ISO 7-bit and 8-bit coded character sets - Code extension techniques, Third edition - 1986-05-01, ISO 2022, 1986. [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. (p38) [RFC2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Format of Internet Message Bodies", RFC 2048, November 1996. [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2821] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC 2821, March 2001. [STD3] Braden, R., "Host Requirements", STD 3, RFC 1122 and RFC 1123, October 1989. [STD12] Mills, D., "Network Time Protocol", STD 12, RFC 1119, September 1989. [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 and RFC 1035, November 1987. [STD14] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, January 1986. 7. Editor's Address Peter W. Resnick QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 USA Phone: +1 858 651 4478 Fax: +1 858 651 1102 EMail: presnick@qualcomm.com (p39) 8. Acknowledgements Many people contributed to this document. They included folks who participated in the Detailed Revision and Update of Messaging Standards (DRUMS) Working Group of the Internet Engineering Task Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and people who simply sent their comments in via e-mail. The editor is deeply indebted to them all and thanks them sincerely. The below list includes everyone who sent e-mail concerning this document. Hopefully, everyone who contributed is named here: 多くの人々がこの文書に寄与した。それにはIETFの「Detailed Revision and Update of Messaging Standards, DRUMS」(メッセージの標準の詳細な版とアッ プデート)ワーキンググループに参加する人たち、IETFのエリアディレクター、 単にE-mailを通じてコメントを置くってくれた人たちを含む。編集者は彼らに 深い恩義を感じ、心から感謝している。下記は、この文書に関連するe-mailを 送った全員を含むリストである。望むべきは、寄与した全員がここに名前があ ることだ。 Matti Aarnio Barry Finkel Larry Masinter Tanaka Akira Erik Forsberg Denis McKeon Russ Allbery Chuck Foster William P McQuillan Eric Allman Paul Fox Alexey Melnikov Harald Tveit Alvestrand Klaus M. Frank Perry E. Metzger Ran Atkinson Ned Freed Steven Miller Jos Backus Jochen Friedrich Keith Moore Bruce Balden Randall C. Gellens John Gardiner Myers Dave Barr Sukvinder Singh Gill Chris Newman Alan Barrett Tim Goodwin John W. Noerenberg John Beck Philip Guenther Eric Norman J. Robert von Behren Tony Hansen Mike O'Dell Jos den Bekker John Hawkinson Larry Osterman D. J. Bernstein Philip Hazel Paul Overell James Berriman Kai Henningsen Jacob Palme Norbert Bollow Robert Herriot Michael A. Patton Raj Bose Paul Hethmon Uzi Paz Antony Bowesman Jim Hill Michael A. Quinlan Scott Bradner Paul E. Hoffman Eric S. Raymond Tom Byrer Steve Hole Sam Roberts Bruce Campbell Marco S. Hyman Hugh Sasse Larry Campbell Ofer Inbar Bart Schaefer W. J. Carpenter Olle Jarnefors Tom Scola Michael Chapman Kevin Johnson Wolfgang Segmuller Richard Clayton Sudish Joseph Nick Shelness Maurizio Codogno Maynard Kang John Stanley Jim Conklin Prabhat Keni Einar Stefferud R. Kelley Cook John C. Klensin Jeff Stephenson Steve Coya Graham Klyne Bernard Stern Mark Crispin Brad Knowles Peter Sylvester Dave Crocker Shuhei Kobayashi Mark Symons Matt Curtin Peter Koch Eric Thomas Michael D'Errico Dan Kohn Lee Thompson Cyrus Daboo Christian Kuhtz Karel De Vriendt Jutta Degener Anand Kumria Matthew Wall Mark Delany Steen Larsen Rolf Weber Steve Dorner Eliot Lear Brent B. Welch (p40) Harold A. Driscoll Barry Leiba Dan Wing Michael Elkins Jay Levitt Jack De Winter Robert Elz Lars-Johan Liman Gregory J. Woodhouse Johnny Eriksson Charles Lindsey Greg A. Woods Erik E. Fair Pete Loshin Kazu Yamamoto Roger Fajman Simon Lyall Alain Zahm Patrik Faltstrom Bill Manning Jamie Zawinski Claus Andre Farber John Martin Timothy S. Zurcher (p41) Appendix A. Example messages This section presents a selection of messages. These are intended to assist in the implementation of this standard, but should not be taken as normative; that is to say, although the examples in this section were carefully reviewed, if there happens to be a conflict between these examples and the syntax described in sections 3 and 4 of this document, the syntax in those sections is to be taken as correct. メッセージの例 このセクションではメッセージを抜粋して示している。これは、この標準を実 装する助けとするつもりだが、規範的であるととるべきではない;つまり、こ のセクションの例が注意深く観察されているにもかかわらず、もしもこれらの 例とこの文書のセクション3,4に記した構文との間に矛盾が生じたならば、 それらのセクションにある構文を正しいものであるととるべきである。 Messages are delimited in this section between lines of "----". The "----" lines are not part of the message itself. メッセージは、このセクションでは「----」の行の間の範囲と定める。「----」 の行はメッセージそのものの一部ではない。 A.1. Addressing examples The following are examples of messages that might be sent between two individuals. アドレス書きの例 以下は、2人の個人間で送られたであろう、メッセージの例である。 A.1.1. A message from one person to another with simple addressing This could be called a canonical message. It has a single author, John Doe, a single recipient, Mary Smith, a subject, the date, a message identifier, and a textual message in the body. ある人から別の人への、単純なアドレス書きのメッセージ これは正規メッセージと呼ばれるかもしれない。1人の著者、John Doe、1人 の受取人、Mary Smith、subject, 日時、メッセージ識別名、ボディにテキス トのメッセージからなる。 ---- From: John Doe To: Mary Smith Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello". ---- (p42) If John's secretary Michael actually sent the message, though John was the author and replies to this message should go back to him, the sender field would be used: もし実際には、Johnの秘書Michaelがメッセージを送ったなら、Johnが著者で あり、このメッセージへの返信は彼に戻るべきであるにしても、senderフィー ルドが使われるだろう: ---- From: John Doe Sender: Michael Jones To: Mary Smith Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello". ---- A.1.2. Different types of mailboxes This message includes multiple addresses in the destination fields and also uses several different forms of addresses. 異なる種類のメールボックス このメッセージは宛先フィールドに複数のアドレスを含み、またいくつかの異 なるアドレスの形式を用いている。 ---- From: "Joe Q. Public" To: Mary Smith , jdoe@example.org, Who? Cc: , "Giant; \"Big\" Box" Date: Tue, 1 Jul 2003 10:52:37 +0200 Message-ID: <5678.21-Nov-1997@example.com> Hi everyone. ---- Note that the display names for Joe Q. Public and Giant; "Big" Box needed to be enclosed in double-quotes because the former contains the period and the latter contains both semicolon and double-quote characters (the double-quote characters appearing as quoted-pair construct). Conversely, the display name for Who? could appear without them because the question mark is legal in an atom. Notice also that jdoe@example.org and boss@nil.test have no display names associated with them at all, and jdoe@example.org uses the simpler address form without the angle brackets. 以前の版ではピリオドを含み、後の版ではセミコロンとダブルクォーテーショ ンを含む(ダブルクォーテーション文字がペアを形成して現れる)ため、Joe Q. Public や Giant; "Big" Box という表示名では、ダブルクォーテーション に入れることが必要となっていることに注意。対して、Who? の表示名は、ク エスチョンマークがアトムで認められているため、ダブルクォーテーションな しで現れる。また、jdoe@example.orgとboss@nil.testは、それらに関連する 表示名を一切持たず、jdoe@example.orgではかぎかっこのない、より単純なア ドレス表記を使っている。 (p43) A.1.3. Group addresses グループアドレス ---- From: Pete To: A Group:Chris Jones ,joe@where.test,John ; Cc: Undisclosed recipients:; Date: Thu, 13 Feb 1969 23:32:54 -0330 Message-ID: Testing. ---- In this message, the "To:" field has a single group recipient named A Group which contains 3 addresses, and a "Cc:" field with an empty group recipient named Undisclosed recipients. このメッセージ中、「To:」フィールドは3つのアドレスを含んだ、A Group と命名された、1つのグループ受取人であり、「Cc:」フィールドは Undisclosed recipients と命名された、空のグループ受取人である。 A.2. Reply messages The following is a series of three messages that make up a conversation thread between John and Mary. John firsts sends a message to Mary, Mary then replies to John's message, and then John replies to Mary's reply message. Note especially the "Message-ID:", "References:", and "In-Reply-To:" fields in each message. 返信メッセージ 以下はJohnとMaryの間の会話スレッドを形成した、3つの一連のメッセージで ある。JohnはまずMaryにメッセージを送り、そしてMaryがJohnのメッセージに 返信し、さらにJohnはMaryの返信メッセージに返信する。 ---- From: John Doe To: Mary Smith Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello". ---- (p44) When sending replies, the Subject field is often retained, though prepended with "Re: " as described in section 3.6.5. 返信を送るとき、セクション3.6.5に書いたように「Re:」が前置されるものの、 Subjectフィールドはしばしば保持される。 ---- From: Mary Smith To: John Doe Reply-To: "Mary Smith: Personal Account" Subject: Re: Saying Hello Date: Fri, 21 Nov 1997 10:01:10 -0600 Message-ID: <3456@example.net> In-Reply-To: <1234@local.machine.example> References: <1234@local.machine.example> This is a reply to your hello. ---- Note the "Reply-To:" field in the above message. When John replies to Mary's message above, the reply should go to the address in the "Reply-To:" field instead of the address in the "From:" field. 上のメッセージ中、「Reply-To:」フィールドに注意。Johnが上記のMaryのメッ セージへ返信するとき、返信は「From:」フィールドにあるアドレスの代わり に、「Reply-To:」フィールドのアドレスに送られるべきである。 ---- To: "Mary Smith: Personal Account" From: John Doe Subject: Re: Saying Hello Date: Fri, 21 Nov 1997 11:00:00 -0600 Message-ID: In-Reply-To: <3456@example.net> References: <1234@local.machine.example> <3456@example.net> This is a reply to your reply. ---- A.3. Resent messages Start with the message that has been used as an example several times: 例として幾度か使ったメッセージから始めよう。 ---- From: John Doe To: Mary Smith Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello". ---- (p45) Say that Mary, upon receiving this message, wishes to send a copy of the message to Jane such that (a) the message would appear to have come straight from John; (b) if Jane replies to the message, the reply should go back to John; and (c) all of the original information, like the date the message was originally sent to Mary, the message identifier, and the original addressee, is preserved. In this case, resent fields are prepended to the message: ここで、このメッセージを受信したMaryが、(a)メッセージが直接Johnから来 たようにしたい、(b)Janeがもしこのメッセージに対して返信するなら、返信 はJohnに行くべきである、(c)もともとそのメッセージがMaryに送られたとき の日時、メッセージ識別名、もともとの送り先のような、そもそもの情報のす べてを保存したい、というふうにしてメッセージのコピーをJaneに送りたいと 望む。この場合、再送フィールドがメッセージに前置される: ---- Resent-From: Mary Smith Resent-To: Jane Brown Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800 Resent-Message-ID: <78910@example.net> From: John Doe To: Mary Smith Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello". ---- If Jane, in turn, wished to resend this message to another person, she would prepend her own set of resent header fields to the above and send that. 次に、Janeがこのメッセージを別の人に再送することを望んだら、彼女は上記 のものに、彼女自身の再送ヘッダフィールドを1組前置し、送る。 (p46) A.4. Messages with trace fields As messages are sent through the transport system as described in [RFC2821], trace fields are prepended to the message. The following is an example of what those trace fields might look like. Note that there is some folding white space in the first one since these lines can be long. トレースフィールドつきメッセージ メッセージが、RFC2821に説明されるように転送システムを通じて送られると、 トレースフィールドがメッセージに前置される。以下はトレースフィールドが どんな外見をしているかの例である。行が長くなりすぎる可能性があるため、 最初の例にはフォールディングホワイトスペースがある。 ---- Received: from x.y.test by example.net via TCP with ESMTP id ABC12345 for ; 21 Nov 1997 10:05:43 -0600 Received: from machine.example by x.y.test; 21 Nov 1997 10:01:22 -0600 From: John Doe To: Mary Smith Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello". ---- (p47) A.5. White space, comments, and other oddities White space, including folding white space, and comments can be inserted between many of the tokens of fields. Taking the example from A.1.3, white space and comments can be inserted into all of the fields. ホワイトスペース、コメント、その他変なもの フォールディングホワイトスペースを含むホワイトスペースやコメントは、フィー ルド中多くのトークンの間に挿入することができる。A.1.3から例をとると、 ホワイトスペースとコメントはあらゆるフィールドに挿入することができる。 ---- From: Pete(A wonderful \) chap) To:A Group(Some people) :Chris Jones , joe@example.org, John (my dear friend); (the end of the group) Cc:(Empty list)(start)Undisclosed recipients :(nobody(that I know)) ; Date: Thu, 13 Feb 1969 23:32 -0330 (Newfoundland Time) Message-ID: Testing. ---- The above example is aesthetically displeasing, but perfectly legal. Note particularly (1) the comments in the "From:" field (including one that has a ")" character appearing as part of a quoted-pair); (2) the white space absent after the ":" in the "To:" field as well as the comment and folding white space after the group name, the special character (".") in the comment in Chris Jones's address, and the folding white space before and after "joe@example.org,"; (3) the multiple and nested comments in the "Cc:" field as well as the comment immediately following the ":" after "Cc"; (4) the folding white space (but no comments except at the end) and the missing seconds in the time of the date field; and (5) the white space before (but not within) the identifier in the "Message-ID:" field. 上の例は芸術としてはよくないが、完全に正しい。特に、以下に言及する。 (1)「From:」フィールド中のコメント(クォートペアの一部として現れる「)」 を持つ場合を含む);(2)ホワイトスペースが「To:」フィールドの「:」の後 ろにないのはもちろん、グループ名の後のコメントとフォールディングホワイ トスペース、Chris Jonesのアドレス中、コメントに特殊な文字「.」、 「joe@example.org」の前後にフォールディングホワイトスペース;(3)「Cc:」 フィールドに複数のネストしたコメントがあるのはもちろん、「Cc:」の「:」 の直後にコメント(4)フォールディングホワイトスペース(最後以外にコメン トがない)と、dateフィールドの時間に秒がない;(5)「Message-ID:」フィー ルド中、識別名の前(中ではない)にホワイトスペース。 A.6. Obsoleted forms The following are examples of obsolete (that is, the "MUST NOT generate") syntactic elements described in section 4 of this document. 時代遅れのフォーム 以下は、本文書中セクション4で記した時代遅れの構文要素の例(つまり、生 成してはならない MUST NOT)である。 (p48) A.6.1. Obsolete addressing Note in the below example the lack of quotes around Joe Q. Public, the route that appears in the address for Mary Smith, the two commas that appear in the "To:" field, and the spaces that appear around the "." in the jdoe address. 時代遅れのアドレス書き 以下の例で、Joe Q. Public の周りに引用符がかけていること、Mary Smithの アドレスに現れている経路、「To:」フィールド中に現れた2つのコンマ、 jdoeのアドレス中、「.」の周りに現れているスペースに注目せよ。 ---- From: Joe Q. Public To: Mary Smith <@machine.tld:mary@example.net>, , jdoe@test . example Date: Tue, 1 Jul 2003 10:52:37 +0200 Message-ID: <5678.21-Nov-1997@example.com> Hi everyone. ---- A.6.2. Obsolete dates The following message uses an obsolete date format, including a non- numeric time zone and a two digit year. Note that although the day-of-week is missing, that is not specific to the obsolete syntax; it is optional in the current syntax as well. 時代遅れの日時 以下のメッセージでは、数字でないタイムゾーンと2桁の数字の年を含む、時 代遅れの日時フォーマットを使っている。day-of-weekがかけているが、それ は時代遅れフォーマット特有ではないことに注意;現在の構文でもまた、それ はオプションである。 ---- From: John Doe To: Mary Smith Subject: Saying Hello Date: 21 Nov 97 09:55:06 GMT Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello". ---- A.6.3. Obsolete white space and comments White space and comments can appear between many more elements than in the current syntax. Also, folding lines that are made up entirely of white space are legal. 時代遅れのホワイトスペースとコメント ホワイトスペースとコメントは、現在の構文中よりも多くの要素の間に用いる ことができる。また、まったくホワイトスペースだけで構成されるフォールディ ング(折り返し)の行も正しい。 (p49) ---- From : John Doe To : Mary Smith Subject : Saying Hello Date : Fri, 21 Nov 1997 09(comment): 55 : 06 -0600 Message-ID : <1234 @ local(blah) .machine .example> This is a message just to say hello. So, "Hello". ---- Note especially the second line of the "To:" field. It starts with two space characters. Therefore, it is considered part of the folding as described in section 4.2. Also, the comments and white space throughout addresses, dates, and message identifiers are all part of the obsolete syntax. 特に、「To:」フィールドの2行目に注意。それは2個のスペース文字で始まっ ている。即ち、セクション4.2で記したフォールディングの一部と考えられる。 また、アドレス、日時、メッセージ識別名中のコメントとホワイトスペースは、 すべて時代遅れの構文の一部である。 Appendix B. Differences from earlier standards This appendix contains a list of changes that have been made in the Internet Message Format from earlier standards, specifically [RFC822] and [STD3]. Items marked with an asterisk (*) below are items which appear in section 4 of this document and therefore can no longer be generated. 古い標準からの変更点 この付録は、古い標準、特にRFC822やSTD3にあるインターネットメッセージフォー マットに書かれたものとの変更点のリストを含む。以下でアスタリスク(*) を付したものは、本文書セクション4に現れたアイテムであり、つまり、もは や作成され得ないものである。 1. Period allowed in obsolete form of phrase. 2. ABNF moved out of document to [ABNF]. 3. Four or more digits allowed for year. 4. Header field ordering (and lack thereof) made explicit. 5. Encrypted header field removed. 6. Received syntax loosened to allow any token/value pair. 7. Specifically allow and give meaning to "-0000" time zone. 8. Folding white space is not allowed between every token. 9. Requirement for destinations removed. 10. Forwarding and resending redefined. 11. Extension header fields no longer specifically called out. 12. ASCII 0 (null) removed.* 13. Folding continuation lines cannot contain only white space.* 14. Free insertion of comments not allowed in date.* 15. Non-numeric time zones not allowed.* 16. Two digit years not allowed.* 17. Three digit years interpreted, but not allowed for generation. 18. Routes in addresses not allowed.* 19. CFWS within local-parts and domains not allowed.* 20. Empty members of address lists not allowed.* 21. Folding white space between field name and colon not allowed.* (p50) 22. Comments between field name and colon not allowed. 23. Tightened syntax of in-reply-to and references.* 24. CFWS within msg-id not allowed.* 25. Tightened semantics of resent fields as informational only. 26. Resent-Reply-To not allowed.* 27. No multiple occurrences of fields (except resent and received).* 28. Free CR and LF not allowed.* 29. Routes in return path not allowed.* 30. Line length limits specified. 31. Bcc more clearly specified. 1. 時代遅れのphraseの形式ではピリオドが許された 2. ABNFはABNFの文書に移った 3. 4ないしそれ以上の数字が年として許された 4. ヘッダフィールドの順序(またそれについての欠如)が明確になった 5. "Encrypted"ヘッダフィールドが削除された。 6. Receivedの構文が、token/value の如何なる組でも許されるよう、緩くなっ た 7. 「-0000」のタイムゾーンを明確に許可し、意味づけした 8. フォールディングホワイトスペースがあらゆるトークンの間では許されな くなった 9. 宛先に関する要求が削除された 10. フォワードと再送を再定義した 11. "Extension header fields" (RFC822での X-*** のフィールド)は、もは や特に規定されなくなった 12. アスキーコード0 (null)が削除された * 13. フォールディングによる連続行で、ホワイトスペースだけが許可されない * 14. date中、コメントを自由に挿入することが許されない * 15. 数字以外のタイムゾーンが許可されない * 16. 2桁の年が許されない * 17. 3桁の数字の年が解釈されるが、生成は許可されない * 18. アドレス中、経路は許されない * 19. local-partやドメイン中、CFWSは許可されない。 * 20. 空のアドレスメンバーリストは許可されない * 21. フィールド名とコロンの間のフォールディングホワイトスペースが許可さ れない * 22. フィールド名とコロンの間のコメントが許可されない * 23. in-reply-toとreferencesの構文が厳しくなった * 24. msg-id中、CFWSは許可されない 25. 再送フィールドの意義が、情報のみと厳しくなった 26. Resent-Reply-Toは許可されない * 27. (resent と receivedを除き)フィールドは複数回出現してはならない * 28. 裸のCRやLFは許可されない * 29. 返信パスに経路が許可されない * 30. 行の長さの制限を規定した。 31. Bcc をより明確に規定した。 Appendix C. Notices Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. Resnick Standards Track [Page 50] RFC 2822 Internet Message Format April 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Resnick Standards Track [Page 51] ---- 訳について この訳は、美森勇気 が個人的な目的で行いました。利用 は自由ですが、一切の保証はしません。 (謝辞) 翻訳にあたり、以下の方々から様々なコメントや誤りの指摘などをいただきま した。この場を借りてお礼とさせていただきます。 おぜきひとし様 松下様