日本語翻訳版覚書　[ホーム] [RFC 821(jp)] [RFC 561(jp)] [MIMEへの過程] [RFC 2045(jp)] [RFC 2046(jp)] [RFC 2047(jp)] [RFC 2049(jp)] http://www.asahi-net.or.jp/~bd9y-ktu/dtd_f/rfc_f/rfc822j.htmlで http://www.cis.ohio-state.edu/htbin/rfc/rfc822.htmlが原著です。 翻訳版は、翻訳からくる間違いがあり得ます：in progress。 message　メッセージ：通信（交流） a communication passed or sent by speech, in writing, by signals etc. a official communication/the President's message to Congress RFC 822:messages (mail) By 1977, the Arpanet employed several informal standards for the text messages (mail) sent among its host computers. -------------------------------------------------------------------------------- (Obsoletes RFC0733) (Updated by RFC1123, RFC1138, RFC1148, RFC1327, RFC2156) (Also STD0011) (Status: STANDARD) -------------------------------------------------------------------------------- Yasutaka Kato　加藤泰孝 -------------------------------------------------------------------------------- rfc822 ［rfcディレクトリーのトップへ］ 　　http://www.cis.ohio-state.edu/hypertext/information/rfc.html RFC # 822 Obsoletes: RFC #733 (NIC #41952) STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES ARPAインターネットテキストメッセージ 　　の書式のための標準 August 13, 1982 Revised by David H. Crocker Dept. of Electrical Engineering University of Delaware, Newark, DE 19711 Network: DCrocker @ UDel-Relay Standard for ARPA Internet Text Messages 目次 前置き ..................................................... ii 1. はじめに ............................................... 1 1.1. 概観 ............................................. 1 1.2. メッセージ（交流）枠組 ........................... 2 2. 命名規約 ............................................... 3 3. メッセージの語彙分析 ................................... 5 3.1. 一般的説明 ....................................... 5 3.2. ヘッダーフィールド定義 ........................... 9 3.3. 語彙字句 ......................................... 10 3.4. 詳細説明 ......................................... 11 4. メッセージ仕様 ......................................... 17 4.1. 構文（使い方） ................................... 17 4.2. 転（返）送 ....................................... 19 4.3. トレース（追跡）フィールド ....................... 20 4.4. 送信者フィールド ................................. 21 4.5. 受信者フィールド ................................. 23 4.6. 参照フィールド ................................... 23 4.7. その他のフィールド ............................... 24 5. 日付と時刻仕様 ......................................... 26 5.1. 構文 ............................................. 26 5.2. 意味 ............................................. 26 6. 住所（アドレス）仕様 ................................... 27 6.1. 構文 ............................................. 27 6.2. 意味 ............................................. 27 6.3. 予約住所（アドレス） ............................. 33 7. 文献 ................................................... 34 付録 A. 例 ..................................................... 36 B. 簡単なフィールド解析 ................................... 40 C. RFC #733との違い ....................................... 41 D. 構文規則のアルファベット順一覧 ......................... 44 August 13, 1982 - i - RFC #822 Standard for ARPA Internet Text Messages 　　　　前置き 1977年までに、Arpanetネットはそのホストコンピューター間でのテキ スト・メッセージ（メール）の情報標準を採用していた。これらの実践を コード化し、差し迫っていると思われる機能を提供することが必要に思われ た。その努力の結果が Request for Comments (RFC) #733、"Standard for the Format of ARPA　Network Text Message", by Crocker, Vittal, Pogran, and Henderson、でした。この仕様書は、既存のソフトウェアーの 大きな変更を避けようと試みられ、一方では幾つかの新しい機能を容認して います。 この文書はRFC #733の仕様書を、大きくてより複雑なARPAインターネッ トの要求に役立つために、改訂しています。幾つかのREC #733の機能は、十 分な認知がえられませんでした。その後を継ぐ標準とソフトウェアーを簡潔 にするために、これらの機能は除去されています。異なった接近体系が、イ ンターネットネットワーク・メールの場合を取り扱うために、使用されてい ます；そして再転送（re-transmission）という概念が導入されています。 この仕様書はARPAインターネットでの使用を意図しています。しかし この試みは、環境への如何なる依存からも自由であるようになされ、従って 別のネットワークテキストメッセージシステムに適用できます。 RFC #733仕様書自体、ARPANETメール環境下で、一年以上が経過し、 それが持っている能力を議論する継続的なフォーラムを提供してきました。 20人をこす人達、国を越えて、がオリジナリルの議論に寄与しました。この 改訂された仕様書の発展も同じ様にメールに基づくグループ議論を利用しま した。両仕様書は、参加者のコメントやアイデアからおおいに得ることがあ りました。 RFC #733で標準の構文は、Backus-Naur Form (BNF)メタ言語でオリジ ナルに特定化されました。Ken L.Harrenstien、of SRI International、は そのBNFを、表現を軽量化し容易に理解できるよう拡大したBNFへ再コード化 の責務を果たしてくれました。 August 13, 1982 - ii - RFC #822 Standard for ARPA Internet Text Messages 1. はじめに 1.1. 概要 この標準は、「電子メール」の枠組み内で、コンピューター利用者の 間で送信されるテキストメッセージ用の構文を特定します。この標準は、 ARPANET Request for Comments #733、「ARPAネットワークテキストメッ セージの書式の標準」、で特定されたものに取って代わるものです。 この文脈で、メッセージは封筒と中味を持っているものとして見られ ます。封筒は転送や配達を成し遂げるのに必要な情報を何でも持っています。 中味は、受信者に配達される対象を組み立てています。この基準は、メッ セージ内容の書式と幾つかの意味にだけ適用されます。それは、封筒にある 情報仕様を一切内容としていません。 しかしメッセージシステムによっては、中味からの情報を使って封筒 を生成するものもあります。この標準は、プログラムによるそのような情報 取得を容易にします。 メッセージシステムによっては、この標準で特定されたものとは異な る書式でメッセージを蓄えるものもあります。この仕様書は、ホスト間を通 過されるにはどんなメッセージの内容書式かの定義として厳格に意図されて います。 　　　 注意： この標準規格は、サイトが使う内部書式、サポートが望まれ た特別なメッセージシステム書式機能・メッセージを生成もしくは読み取る ユーザーインターフェース・プログラムの特徴、を述べる意図はありません。 仕様は何を要求しているか（必須）と何を許しているかの区別を明確 にしておくべきです。メッセージは、情報の書式的に構造化された要素で、 複雑で豊かにでき、またそのような情報を最小にして、小さく簡潔にもでき ます。また、この標準規格はメッセージの色々な視覚的な書式の解釈を簡素 にしています；メッセージの視覚的な面だけが影響をうけ、その中にある情 報の解釈は影響されません。手段提供者はそのような視覚的な区別を温存す ることを選ぶかもしれません。 この公式定義は四つのレベルに分けられます。最低レベルはこの文書 で使用されるメタ命名を記載します。二番目のレベルは高次レベルパーサー にトークン（字句）を送り込む基本的な語彙分析器を説明します。次はメッ セージの全体的な仕様です；個々のフィールドの区別が許されています。最 後に、幾つかの構造化されたフィールドの内容の定義があります。 August 13, 1982 - 1 - RFC #822 Standard for ARPA Internet Text Messages 1.2. メッセージ（交流）枠組 メッセージはテキスト行からなっています。線画・複写・演説そして 構造化されたテキストを符号化するために、何ら特別な規定は作られていま せん。データー圧縮問題もしくは転送や保存効率について重要な考慮は一切 払われなく、標準は使われるビット数は自由です。例えば、フィールド名は 特別な簡潔なコードでなく自由なテキストとして特定されています。 一般的な"memo"枠組みが使われています、言い替えると、メッセージ は厳格な書式の情報つづいて主メッセージ部分、この文書で特定していない 書式を持った、が来るという構成です。厳格に書式化されたセクション （ヘッダー＝"headers"）の構文はこの仕様書で定義されます；これら フィールドの幾つかは、全てのメッセージに来なければなりません。 ヘッダーフィールドを区別する構文は特別なフィールド用の内部構文 　　 と分離して特定されています。この分離の意図は、シンプルなパーサー（解 　　 析）が、個々のヘッダーフィールドの詳しい構造に関わらないで、一般的な 　　 メッセージ構造を操作できることです。付録 Bは、これらのパーサーの構築 　　 を助けるために提供されています。 この文書で特定されたフィールドに加えて、その他のフィールドは普 通の使い方ができます。必要なら、これら「拡張フィールド」用の仕様は、 この文書を公開するのに使われたと同じ機構で、公開できます。個人的に使 う一式のフィールドを拡張したいと思う利用者もいるでしょう。そのような 「利用者定義フィールド」は許されています。 この枠組みは文書格式と表現を厳格に強制し、主に、大部分の企業内 交流やよく構造化された企業内交流にとって有益です。これはまた仲介交流 の或る種の型、簡単なファイル転送や遠隔の仕事登録といった、にとっても 利用できます。より強力な枠組みでは、情報の多元文字・多元色彩・多元次 元符号化が可能かもしれません。より強力てないもの、殆どの単一機械メッ セージシステムで提供しているので、はフィールドを追加する能力や特別な フィールドを含むことの決定をより厳格に拘束します。紙基本の交流とは対 照的に、メッセージ受信者がメッセージ表示に関わる大変な量の制御を発揮 していることに気付くことは興味があります。メッセージ受信者が入手でき る実際の制御は、個々のメッセージシステムの能力しだいです。 [#^] August 13, 1982 - 2 - RFC #822 Standard for ARPA Internet Text Messages 2. 命名規約 この仕様書は拡大Backus-Naur書式（BNF）命名法を用いています。標 準BNFとの違いは、命名規則や反復や「ローカル」代替を示唆していること です。 2.1. 命名規則 鈎括弧は（"<"、">"）は一般に使用されていません。規則の名前は、 ""でなく単に名前そのものです。引用符号はその通りの文字（大文字 かもしくは小文字であるかもしれない）を囲います。或る種の基本的な規則 はSPACE・TAB・CRLF・DIGIT・ALPHAなどのように大文字です。角括弧は、規 則定義やこの文書の後のほうで使われ、これらがあるので規則名を探すこと が容易になります。 2.2. 規則1／規則2：　代替 スラッシュ("/")で分離された要素は、代替です。従って、 "foo / bar" は food もしくは bar を受け入れます。 2.3. （規則1／規則2）： 部分的代替 丸括弧で囲われた要素は、単一要素として処理されます。かくて、 "(elem (foo / bar) elem)" は、トクン（字句）連続体 "elem foo elem" と "elem bar elem"が可能です。 2.4. *規則： 反復 要素の前の"*"文字は、繰り返しを指します。書式は： *element は、要素の最低そして最高出現を指します。既定値は0から無限大で、 "*(element)" は0を含めてどんな数値でもとります；"1*element" は少なく とも一つを必要とします；そして "1*2element" は一つもしくは二つを許容 します。 2.5. [規則]： 選択 大括弧は選択性の要素を囲います； "[foo bar]" は "*1(foo bar)" と同じものです。 2.6. n規則（NRULE）： 特別な反復 "(element)" は "*(element)" と同じです；つまり、 正確に (element) が出現します。かくて、2DIGITは2-数値、そして 3ALPHAは三つのアルファベット文字列です。 August 13, 1982 - 3 - RFC #822 Standard for ARPA Internet Text Messages 2.7. #規則： リスト "#"構成は、"*" と似ていて、以下のように定義されます： #element 最低そして最高要素、一つ以上のコンマ（","）でお互い分離され た、を指します。これは有効なリスト書式を大変容易に作成します； ' (element *("," element))' といった規則は "1#element" として見せるこ とができます。この構造が使われる場合はヌール要素（null element）が許 されますが、そこにある要素にはかぞえません。 つまり、 "(element),, (element)" が許されますが、ただ二つの要素とし て数えられます。従ってすくなくとも一つの要素が必要な場合少なくとも一 つの非ヌール要素（non-null element）が存在しなければなりません。既定 値は 0 と無限大で、"#(element)" が幾つでも、ゼロも入れて、許されま す。"1#element" は少なくとも一つ必要です；そして "1#2element" は一つ もしくは二つ許されます。 2.8. ; コメント セミコロンは、規則テキストの右に距離をおいて、行の終まで続くコ メントの開始です。これは、仕様書に並記する有用な覚書を書く簡単な方法 です。 [#^] August 13, 1982 - 4 - RFC #822 Standard for ARPA Internet Text Messages 3. メッセージの語彙分析 3.1. 一般的な説明 メッセージは、ヘッダーファイルと選択性のボディから構成されてい ます。このボディは単なるASCII文字を内容とする行連続体です。ヘッダー とはヌール行（空行）で分離されています（すなわち、CRLFに先行するもの がない行）。 3.1.1. 長いヘッダーフィールド 各ヘッダーフィールドは、ASCII文字の単一論理的な行としてみることが でき、フィールド名とフィールドボディを含みます。慣例として、この 概念実体のフィールドボディは多元行表現に分割できます；これは「折 り重ね="folding"」と言われます。一般的な規則は、空行（linear- white-space）がくるところは、最低一つのLWSP-charが直後に続くCRLF が代わりに挿入されます。従って、以下の単一行 To: "Joe & J. Harvey" , JJV @ BBN は、以下のように表現できます： To: "Joe & J. Harvey" , JJV@BBN や To: "Joe & J. Harvey" , JJV @BBN や To: "Joe & J. Harvey" , JJV @ BBN ヘッダーフィールドの折り重ねられた多元行表現からその単一行 表現への移行は、「折り重ね復元="unfolding"」といわれます。「折り 重ね復元="unfolding"」は、LWSP-charが直後にあるCRLFをLWSP-charと 等価なものとして解釈することで、成し遂げられます。 　　　 注意： 標準では、空白行が入れられる所ならどこででも折り重ねが許さ 　　　 れますが、構造化されたフィールド、アドレス（address）が来 　　　 る所のような、は折り重ねをより高次レベル構文分断に限定して 　　　 います。アドレスでは、そのような折り重ねは住所間で分離コン 　　　 マの後に来るよう薦められています。 August 13, 1982 - 5 - RFC #822 Standard for ARPA Internet Text Messages 3.1.2. ヘッダーフィールドの構造 フィールドが折り重ねを解かれたら、field-name続いてコロン（":"）、 続いてfield-bodyそしてキャッリッジリターン／改行（carriage- return/line-feed）で終りという構成として見えるかもしれません。 field-nameは印字可能なASCII文字から成っていなければなりません（コ ロン以外は33から26の間の十進値文字）。field-bodyはCRもしくはLFを 除いたASCII文字から構成されているかもしれません（CR と／若くはLF が実際のテキストに来ていても、フィールドを折り重ねることで除去さ れます）。 ヘッダーの或る種のフィールドボディは、システムによっては解析した いと思う、内部構文に従って解釈されるかもしれません。例では、 フィールドにデーターとアドレスが来ています。別のフィールド、 注意： 単なる以外と定義されたフィールドボディのあるフィー ルドは、構造化されたフィールドとして処理されなければなり ません。 Field-names・非構造化フィールドボディそして構造化フィール ドボディは、自身の独立の、「語彙」分析によって、お互いに情 報を調べています。 3.1.3. 非構造化フィールド体（FIELD BODIES） フィールドによっては、"Subject" と "Comments" のように、構造化は ないと考えられ、単にメッセージボディのとして処理されます。 「折り重ね」の規則はこれらのフィールドに、数行を写すそのような フィールドボディは、少なくとも一つのLWSP-charで字下げされた二番目 や引き続く行が来なければならないので、適用します。 3.1.4. 構造化フィールド体 構造化されるフィールドの作成と読み取りを助けるために、空白行 （CRLFの封入によって折り重ねることを許す）の自由な挿入が語彙トー クン（字句）間で許されます。この空白行の明示的な構文がある構造化 フィールド用の構文仕様を隠すことでなく、別の「語彙」分析器の存在 が想定されています。この分析器は、上に述べた様に単なるテキスト列 である非構造化フィールドボディに当てはまりません。分析器は、語彙 August 13, 1982 - 6 - RFC #822 Standard for ARPA Internet Text Messages 的なシンボル列としてフィールドのボディを構成する、折り重ねられた テキストの解釈を提供します。 これらのシンボルは： - individual special characters - quoted-strings - domain-literals - comments - atoms これらのシンボルのうち最初の四つは自己識別子です。Atomはことなり ます；自己識別シンボルと空白行によって識別されます。atomsと引用列 の再生のために、正確に一つのスペースがあると想定され、それらの間 に使用されるべきです。（また、「空白行」についての「説明」セク ションで、多元連続LWSP-charsnoの処理に関する規則に注意してくださ い。） そこで、例えば、アドレスフィールドの折り重ねられたボディは、 ":sysmail"@ Some-Group. Some-Org, Muhammed.(I am the greatest) Ali @(the)Vegas.WBA August 13, 1982 - 7 - RFC #822 Standard for ARPA Internet Text Messages 以下の語彙的シンボルとタイプに分析されます： :sysmail quoted string @ special Some-Group atom . special Some-Org atom , special Muhammed atom . special (I am the greatest) comment Ali atom @ atom (the) comment Vegas atom . special WBA atom アドレス内のデーターの正式な表現は以下の文字列になります： ":sysmail"@Some-Group.Some-Org と Muhammed.Ali@Vegas.WBA 注意： 表示のためやそのような構造化された情報を別のシステムに渡す 　　　 際、メールプロトコールが提供するように、ピリオド（"."）も 　　　 しくはアットマーク("@")で分離されたs間に空白行はな 　　　 く、その他のs全ての間にただ一つのスペースが来なけれ 　　　 ばなりません。また、ヘッダーは「折り重ね」書式になっていな 　　　 ければなりません。 August 13, 1982 - 8 - RFC #822 Standard for ARPA Internet Text Messages 3.2. ヘッダーフィールド定義 これらの規則はフィールド・メタ構文、特殊なタイプもしくは内部構 文問題を除いて、を示しています。この目的はフィールドの探知の機会を与 えることです；また一行にうまくはまる各フィールドのイメージを、高次レ ベル解析に、提示します。 field = field-name ":" [ field-body ] CRLF field-name = 1* field-body = field-body-contents [CRLF LWSP-char field-body] field-body-contents = August 13, 1982 - 9 - RFC #822 Standard for ARPA Internet Text Messages 3.3. 語彙トークン（語彙字句） 以下の規則は、基本的な語彙解析を定義するのに使われていて、高次 レベル解析にトークンを送り込みます。文献のANSI資料をみて下さい。 ; ( Octal, Decimal.) CHAR = ; ( 0-177, 0.-127.) ALPHA = ; (101-132, 65.- 90.) ; (141-172, 97.-122.) DIGIT = ; ( 60- 71, 48.- 57.) CTL = ; ( 177, 127.) CR = ; ( 15, 13.) LF = ; ( 12, 10.) SPACE = ; ( 40, 32.) HTAB = ; ( 11, 9.) <"> = ; ( 42, 34.) CRLF = CR LF LWSP-char = SPACE / HTAB ; semantics = SPACE linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE ; CRLF => folding specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word. delimiters = specials / linear-white-space / comment text = atoms, specials, CR & bare LF, but NOT ; comments and including CRLF> ; quoted-strings are ; NOT recognized. atom = 1* quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or ; quoted chars. qtext = , ; => may be folded "\" & CR, and including linear-white-space> domain-literal = "[" *(dtext / quoted-pair) "]" August 13, 1982 - 10 - RFC #822 Standard for ARPA Internet Text Messages dtext = may be folded "]", "\" & CR, & including linear-white-space> comment = "(" *(ctext / quoted-pair / comment) ")" ctext = may be folded ")", "\" & CR, & including linear-white-space> quoted-pair = "\" CHAR ; may quote any char phrase = 1*word ; Sequence of words word = atom / quoted-string 3.4. 説明 3.4.1. 引用 文字によっては、識別語彙トークンのように、特別な解釈用に予約され ています。非解釈データーとしてこれの使用を許すには、引用機構が提 供されています。文字を引用符号で囲うには、バックスラッシュ("\")が 先行します。 この機構はまだ一般的ではありません。文字は語彙構造のサブセット内 だけで引用符号で囲まれるかもしれない。特に、引用囲いは以下の中で の使用に限られている： - quoted-string - domain-literal - comment これらの構成内では、引用はCRと"\"とトークンを識別する文字（例え ば、コメント用の "("と")" ）が必要です。しかし、引用は引用はどん な文字でも許されます。 注意： 特に、引用はatom内では許されていません。例えばaddr-specの 　　 ローカル部分（local-part）は特別な文字が来る必要がある場合、 　　 引用文字が使用されなければなりません。従って、以下のような 　　 仕様： Full\ Name@Domain は、正しくなく、以下のように特定されなければなりません： "Full Name"@Domain August 13, 1982 - 11 - RFC #822 Standard for ARPA Internet Text Messages 3.4.2. 空白スペース 注意： 構造化フィールドでは、多元空白行ASCII文字（つまり、タブと 　　　 スペース）は単一スペースとして処理され、どのようなシンボル 　　　 をも囲います。全てのヘッダーフィールドでは、少なくとも一つ 　　　 のLWSP-charは必要な唯一の場所は折り重ねられたフィールドの 　　　 連続行の最初です。 この文書に従ってテキストを解釈しない過程（例えば、メールプロト コールサーバー）にテキストを渡す場合、空白行（linear-white- space）文字はピリオド（"."）もしくはアットマーク（"@"）との 間に来るべきではありません。性格にただ一つのスペースが、任意の空 注意： この標準基準に適合するシステム内では、識別子のリストにある 　　　 ものはどれでも許され、LWSP-charsもその前と／もしくは後に来 　　　 るかもしれません。 メール送信（例えば、ヘッダー生成）プログラムの書き手は、ASCII HT （水平タブ）文字の、別のネットワークホストでの現われ方のインター ネット一般の定義はないことを了解すべきです；従って、メッセージ ヘッダーでのタブの使用は、許されているはいますが、薦められません。 3.4.3. コメント コメントは一式のASCII文字で、一対の括弧で囲われており、引用文字列 内にはきません。コメント構成はメッセージ発信者がテキストに付け加 えことができ、人である読み手に有用ですが書式構文は無視します。コ メントは、メッセージがこの標準基準に従って解釈される対象である 間、保持されるべきです。しかし、コメントはメールサービスでプロト コール交換中といった、別の場合には含まれてはいけません。 コメントは入れ子になり、それ故に非引用左括弧がコメント文字列に来 たら対応する右括弧も来なければなりません。コメントが二つの語彙的 なシンボル、二つのアトム（atom）といった、間の識別子として働く場 合メールプロトコールサーバーに連続体を渡す時のように連続体を再生 する目的にとって、単一スペースと語彙的には同じです。コメントは、 構造化されたフィールドのフィールドボディ内にだけでそのようなもの として認められます。 コメントが多行で「折り重ね」である場合、そのときは折り重ね用の構 文に忠実でなければなりません。（上記の「"長いヘッダーフィールドの August 13, 1982 - 12 - RFC #822 Standard for ARPA Internet Text Messages 折り重ね"に関するメッセージの語彙的な分析」と以下の"大文字小文字 非依存"のセクションを参照）。正式な意味はコメントで非引用CRLFを何 ら見ない、特別な解析プログラムはそれらの存在に注意したいものもあ りますが、ことに注意してください。これらプログラムにとって、コメ ントの部分であるCRLFとして"CRLF LWSP-char"を解釈するのは理に適っ ています；例えばCRLFは保たれLWSP-charは取り除かれます。引用CRLF （例えば、CRついでLFに続かされるバックシュラッシュ）はなお少なく とも一つのLWSP-charが続かなければなりません。 3.4.4. 区切り（識別）と引用文字 引用文字（バックスラッシュ）と構文単位を区別する文字は一般的に区 別されたまた引用された部分のデーターとして取り上げられません。特 に、引用文字列（quoted-string）を定義した引用マークとコメントを定 義した括弧と続く文字を引用するバックスラッシュは、引用文字列・コ メントもしくは引用された文字の一部ではありません。引用文字列の部 分である引用マーク・コメントの部分である括弧・そのどちらかの部分 であるバックスラッシュは、各々引用文字バックスラッシュ（"\"）に よって先行されなければなりません。構文は引用文字列もしくはコメン ト内でどんな文字でも引用されることに注意してください；しかし、或 種の文字だけはデーターとして含まれるように引用されてはいけませ ん。これらの文字は代替テキストグループ（例えば、ctext もしくは qtext）の部分ではないものです。 この規則の一つの例外は、単一スペースがフレーズ（句）内の一連の単 語間には存在し、この解釈は、創作者がその単語間に置いた、空白文字 （LWSP-chars）の実際の数には関係ないということです。一つ以上のス ペースを含むのは、創作者は空白文字を引用文字列の部分にしなければ なりません。 引用文字列を区分する引用マークと続く文字列を引用するバックスラッ シュは、その文字列が、この仕様書に従ってデーターを解釈しない処理 過程（例えばメールプロトコールサーバー）に引き渡された時引用文字 列に伴われるべきではありません。 3.4.5. 引用された文字列＝引用文字列（QUOTED-STRINGS） 許された所（例えば構造化されたフィールドの単語＝words）で、引用文 字列は単一シンボルとして取り扱われます。つまり、引用文字列は構文 的にはアトム＝atomと同じです。引用文字列は多行に「折り重ね」に なっている場合、そのときは折り重ねの構文に付きしたがなければなり August 13, 1982 - 13 - RFC #822 Standard for ARPA Internet Text Messages ません。（前述の「長いヘッダーフィールド」の「メッセージの語彙分 析」セクションと後述の「大文字小文字独立」セクションを参照）　従 って、公式の意味では引用文字列内にあるむきだしのCRLFをみることは ありません；しかし、特殊な解析プログラムはそれらの存在を知りたい かもしれません。そのようなプログラムにとって、引用文字列の部分で あるCRLFとして"CRLF LWSP-char"を解釈するのは理に適っています；例 えば、CRLFは保存されLWSP-charは抜き取られるます。引用CRLF（例え ば、CR次いでLFにつながるバックスラッシュ）はも折り課さね規則の対 象ですが、引用文字（バックスラッシュ）の存在は、そのCRLFは引用文 字列へのデーターであることを明示的に示唆しています。最初に続く LWSP-charを取り去ることも、引用CRLFを解析する時、適切です。 3.4.6. 括弧文字（BRACKETING CHARACTERS） 組で来なければならない括弧の一タイプがあり、お互いの中で入れ子さ れる組を持つかもしれません： o 括弧("(" と ")") はコメントを指すのに使われます。 一致した組で来なければならない三つのタイプの括弧があり、入れ子さ れません。 o コロン/セミ-コロン（":" と ";"）は、アドレス仕様で使われ、 アドレスの包含リストは一つのグループとして処理されなけれ ばならないことを指しています。 o 鈎括弧（ "<" と ">" ）は、機械-使用可能参照（例えば、 メールボックスを識別する）、機械に資源への経路を教えるこ とを内容にしている、の存在を示唆するのに使われます。 o 大（角）括弧（"[" と "]"）は、ドメイン字義（domain- literal）の存在を示唆し、普通の名前解釈機構を経て直接利用 するにはどれが適切なドメイン名であるかを示唆します。 3.4.7. 大文字小文字の区別なし 注意されるものを除いて、アルファベット文字列は大文字と小文字のど んな組み合わせで表現されるかもしれません。ケース情報（大文字小文 August 13, 1982 - 14 - RFC #822 Standard for ARPA Internet Text Messages 字情報）の保存を必要とする構文単位は： - text - qtext - dtext - ctext - quoted-pair - local-part, except "Postmaster" その他の構文単位を一致には、ケース情報は無視されなければなりませ ん。例えば、フィールド名で"From"・"FROM"・"from"そして"FroM"でさ え構文的には同等で、全て同等に処理されるべきです。 これらの単位を生成する場合アルファベット文字の大文字と小文字の混 在も使われるかもしれません。この仕様書で示している例はメッセージ 制作過程のために示唆されています。 注意： 予約されたローカル部分（local-part）アドレス、"Postmaster"、 は例外です。 "Postmaster"の値が解釈される際、"POSTMASTER" や"postmaster"を含む如何なるケース混在（大文字小文字混在） でも受け入れられなければなりません。 3.4.8. 長いヘッダーフィールドの折り重ね 各ヘッダーフィールドは、フィールド名とそのボディでCDLFで終わるも のから構成される、正確に一つの行で表現されるかもしれません；これ がパーサーが見ているものです。読み易さのために、長いヘッダーフィ ールドは実際のフィールドでは多元行に「折り重ね」られるかもしれま せん。「長い」とは、普通65もしくは72文字以上を意味すると解釈され ます。前者の長さが、シンプルな表示ソフトウェアーの最もシンプルな 端末でメッセージを閲覧する場合、制限として働きます；しかしこの制 限はこの仕様書は課せていません。 注意： 表示ソフトウェアーによっては、しばしば選択的に行を、端末表 示に合わせて、折り重ねすることができます。そのような例で は、サーバー提供の折り重ねが表示ソフトウェアーを操作できま す。 3.4.9. バックスペース文字（BACKSPACE CHARACTERS） ASCII BS（バックスペース、十進値 8）は、重印をもたらすために、テ キストと引用文字列に含まれるかもしれません。しかし、テキストと引 用文字列の始まりより左に重印をもたらすバックスペースの使用は如何 なるものでも禁止されています。 August 13, 1982 - 15 - RFC #822 Standard for ARPA Internet Text Messages 3.4.10. ネットワーク特有の転送 均一でないネットワーク経由転送中、データーをネットワークのローカ ル慣例に強制的に適合させる必要があるかもしれません。例えばCRだけ があれば、CRはLFに続けられ、CRLFを作り、もしくは によって 続けられることが要求されるかもしれません。そのような転送は、メッ セージがそのネットワークを出る際、反対のことが行われます。 ネットワークの境界を越えていく際、メッセージは二つのモジュール （プログラム構成単位）通過するものとして処理されるべきです。「当 該」ネットワークを通る移動が許されるのに必要なネット特有の転送を なんでも内容としている、最初のモジュールに入ります。次いで、この モジュールに手渡します： o 反転転送（Transformation Reversal） 「当該」ネットワークの特質が取り除かれ、メッセージはこの 仕様書で特定された正式な書式に戻されます。 o 転送（Transformation） 「次」のネットワークのローカルの特質がメッセージに課せられ ます。 +------------------+ ネットAから ==> | ネットAの | | 特質を除去 | +------------------+ || \/ 　標準に適合 || \/ +------------------+ | ネットBの | ==> ネットBへ | 特質を課せる | +------------------+ [#^] August 13, 1982 - 16 - RFC #822 Standard for ARPA Internet Text Messages 4. メッセージ仕様 4.1. 構文 注意： この命名規約作品によれば、構文はフィールド、もしあれば、に 　　　 よっては特別な順位でなければならないと示唆しています。ヘッ 　　　 ダーフィールドは、メッセージはヘッダーの後に来なければならな 　　　 いということ以外、なんら特殊な順位でくることを要求されていま 　　　 せん。ヘッダーフィールドは、もしあれば、"Return-Path"・ 　　　 "Received"・"Date"・"From"・"Subject"・"Sender"・"To"・"cc" 　　　 その他の順位で送信されることが薦められています。 この仕様書は殆どのフィールドの多元出現を許しています。例外と して解釈がここで特定されてなく、その使用が薦められていませ ん。 色々なフィールドのボディ用の以下の構文は、各フィールドボディを 単一のながい文字列（もしくは行）として説明してあるものと考えられなけ ればなりません。上述の「長いヘッダーフィールド」についての「メッセー ジの語彙分析」セクションでこのような長い列は、実際の転送されるメッ セージがどのようにして、一行以上に表現されるかを示唆しています。 message = fields *( CRLF *text ) ;最初のヌール行の 　　　　　　　　　　　　　　　　　　　　　　; 後のものは全て ; メセージボディです fields = dates ; Creation time, source ; author id & one 1*destination ; address required *optional-field ; others optional source = [ trace ] ; net traversals originator ; original mail [ resent ] ; forwarded trace = return ; path to sender 1*received ; receipt tags return = "Return-path" ":" route-addr ; return address received = "Received" ":" ; one per relay ["from" domain] ; sending host ["by" domain] ; receiving host ["via" atom] ; physical path *("with" atom) ; link/mail protocol ["id" msg-id] ; receiver msg id ["for" addr-spec] ; initial form August 13, 1982 - 17 - RFC #822 Standard for ARPA Internet Text Messages ";" date-time ; time received originator = authentic ; authenticated addr [ "Reply-To" ":" 1#address] ) authentic = "From" ":" mailbox ; Single author / ( "Sender" ":" mailbox ; 実際の送信者 "From" ":" 1#mailbox) ; Multiple authors ; or not sender resent = resent-authentic [ "Resent-Reply-To" ":" 1#address] ) resent-authentic = = "Resent-From" ":" mailbox / ( "Resent-Sender" ":" mailbox "Resent-From" ":" 1#mailbox ) dates = orig-date ; Original [ resent-date ] ; Forwarded orig-date = "Date" ":" date-time resent-date = "Resent-Date" ":" date-time destination = "To" ":" 1#address ; Primary / "Resent-To" ":" 1#address / "cc" ":" 1#address ; Secondary / "Resent-cc" ":" 1#address / "bcc" ":" #address ; Blind carbon / "Resent-bcc" ":" #address optional-field = / "Message-ID" ":" msg-id / "Resent-Message-ID" ":" msg-id / "In-Reply-To" ":" *(phrase / msg-id) / "References" ":" *(phrase / msg-id) / "Keywords" ":" #phrase / "Subject" ":" *text / "Comments" ":" *text / "Encrypted" ":" 1#2word / extension-field ; To be defined / user-defined-field ; May be pre-empted msg-id = "<" addr-spec ">" ; Unique message id August 13, 1982 - 18 - RFC #822 Standard for ARPA Internet Text Messages extension-field = user-defined-field = 4.2. 転（返）送（FORWARDING） システムによっては、メール受信者が送信の元のヘッダーを保存した メッセージに新しいフィールドを追加して、返送できます。この標準はそ のようなサービスをサポートし、フィールド名に"Resent-"を付けます。 文字列"Resent-"がフィールド名を始める時はいつでも、このフィール ドは名前に接頭語がついていないファイルと同じ意味を持っています。 しかしメッセージは、"Resent-"フィールドを添え付けるオリジナルな 受信者によって返送されたと想定されます。この新しいフィールドは、 等価でオリジナルなフィールドより、より新しいものとして処理され ます。例えば"Resent-From"、メッセージを返送人を指し、それとは対 照的に"From"フィールドはオリジナルな著者を指します。 そのような先行する情報の使用は、関係者の交流要求に依存します。 例えばこの標準は、"Resent-From:" アドレスが何時返事を受け取るべ きかを指定せず、その代わりにそれらを"From:"アドレスに送信しま す。 注意： 一般的に"Resent-"フィールドは、オリジナルなフィールド一式と独 立の情報一式を内容としているものとして処理されるべきです。一 式の情報は別のものから自動的に取ってこられるべきではありませ ん。多元部分"Resent-"フィールド、同じタイプの、解釈は未定義で す。 この仕様書の後半で、正しい"Resent-"フィールドの出現は、名前がこ の接頭語を内容としていないフィールドの出現と同じに処理されます。 August 13, 1982 - 19 - RFC #822 Standard for ARPA Internet Text Messages 4.3. トレース（追跡）フィールド トレース（追跡）はメッセージの検査追跡を提供するのに使われま す。更に、メッセージの送り手まで元に戻ることを指します。 既知の"via" と "with"の値のリストは、Network Information Center, SRI International, Menlo Park, California.に登録されて います。 4.3.1. リターン経路（RETURN-PATH） このフィールドは、メッセージをその受信者に配達する最終転送システ ムによって付け加えられます。このフィールドは、アドレスとメッセー ジの起点者に遡るルートについての確実な情報を内容にするよう、意図 されています。 注意： "Reply-To"フィールドは、原送信者とサーバーによって返答への 経路を教えるために、付け加えられ、それとは対照的に"Return-Path" フィールドは原送信者へ遡る経路を同定するのに使用されます。 構文はルート仕様は選択的と示唆していますが、試み毎にこのフィール ドにその情報を提供するようにされるべきです。 4.3.2. 受け取り手（RECEIVED） このフィールドの写しは、メッセージを中継する各転送サービスによっ て付け加えられます。このフィールドの情報は、転送トラブルの追跡に とって大変有用です。 送信と受信ホスト名と受け取り時間が特定されるかもしれません。"via" パラメーターはそのメッセージが送られて来た物理的な機構、Arpanet もしくはPhonenetのように、は何かを示唆するために使用され、"with" パラメーターはメールもしくは接続レベルのプロトコール、SMTPメール プロトコールもしくはX.25転送プロトコールのように、を示唆するのに 使われるかもしれません。 注意： 幾つかの "with"パラメーターは、使用されたプロトコール一式 を全て特定するために、あります。 転送サービスによってはメールを待ち行列に入れるものもあります； メッセージに当てるインターネットメッセージ識別子が、"id"パラメー ターを使って、書き留められるかもしれません。送信ホストは行き先ア ドレス仕様、受信ホストが拡張や変換によって再解釈するを使う際、受 August 13, 1982 - 20 - RFC #822 Standard for ARPA Internet Text Messages 信ホストは、"for"パラメーターを使って、オリジナルの仕様を記録した いかもしれません。例えば、メールの写しが配布リストのメンバーに送 られる場合このパラメーターがリストを特定するのに使われたオリジナ ルなアドレスを記録するのに使用されるかもしれません。 4.4. 送信者フィールド 標準は、 From・Sender・Reply-To・Resent-From・Resent-Senderそし てResent-Reply-Toフィールドで可能な組み合わせのサブセットだけし か許しません。この制限は意図的なものです。 4.4.1. FROM / RESENT-FROM このフィールドはこのメッセージを送信したい人の同定を内容としてい ます。メッセージ作成過程が、このフィールドは単一で正式に認可され た、メッセージを入力した代行手段（人・システムもしくは処理過程） を示唆している、機械であることを放棄すべきです。これがない場合は "Sender"フィールドが来なければなりません。"From"がこの方法を放棄 されている場合"Sender"フィールドは"From"フィールドにともない選択 的で冗長です。全ての例で、"From"フィールドのアドレスは機械利用可 能な（addr-specs）ものでなければならなく、命名リスト（グループ） を内容としないかもしれません。 4.4.2. SENDER / RESENT-SENDER このフィールドは、メッセージを送信する代行手段（人・シシテムもし くは過程）の権威付けられた同定を内容とします。送信者がメッセージ 著者でない場合に使用するかもしくは著者の仲間グループの誰が実際に メッセージを送信したかを示唆するのに使用することを意図していま す。"Sender"フィールドの内容が完全に"From"フィールドの付け加えで あるなら、 "Sender"フィールドは来る必要がありませんし、その使用は 薦められません（正しいのすが）。特に、"Sender"フィールドは、"From" フィールドと同じでないなら、来なければなりません。 送信メールボックス仕様は、標準アドレスでなく特別な代行手段（例え ば、人の利用者もしくはコンピュータープログラム）に対応せねばなら ない言葉列を含んでいます。これは、フィールドがメール送信に責任あ る単一代行手段（人・システムもしくは過程）を同定し単にメールが送 信されるメールボックスの名前を含むだけではないという考え、を示唆 しています。例えば、割り当てられたログイン名の場合名前それ自体で は十分ではありません。ローカル部分のアドレス単位、この代行手段に 照合する、はコンピューター用語もしくは（例えば）ネットワークテキ ストメッセージの外で使用される一般的な人照合でないと考えられてい ます。 August 13, 1982 - 21 - RFC #822 Standard for ARPA Internet Text Messages "Sender"フィールドによって提供されるこの重要な機能はメール送信に 責任ある代行手段の同定でそしてコンピュータープログラムはその振る 舞いに責任を取ることができないので、コンピュータープログラムは メッセージを生成する際"Sender" フィールドメールボックス仕様の一部 として参照されるそのプログラムにどの人が責任をとるかが強く推奨さ れています。 4.4.3. REPLY-TO / RESENT-REPLY-TO このフィールドはどの応答に送信されるべきかをメールボックスに示唆 する一般的な機構を提供します。この機能の三つの典型的な使い方が区 別されます。最初の例は、著者（群）が決まったメールベースのメール ボックスを持たないかもしれない、従って代替機構を指定することを希 望する例です。二番目の例は、著者が追加した人に応答に気付き責任を 持ってもらいたい例です。多少異なる使い方は、自動的な配布サービス を備え付けられている"text message teleconferencing"グループで幾ら か助けになるかもしれません；teleconferenceに提出された全てのメッ セージの"Reply-To"フィールドにそのサービスアドレスを含みます； 次いで参加者は、自身の提案の正しい配布を保証するために参照提出に 答えることができます。 注意： "Return-Path"フィールドはメール転送サービスによって、最終 配達の時点で、付け加えられます。これはメッセージの原著者へ 遡る経路を同定する意図です。"Reply-To"フィールドはメッセー ジ原著者によって付け加えられ、返事の方向付けをするのがその 意図です。 4.4.4. FROM / SENDER / REPLY-TOの自動利用 （AUTOMATIC USE OF FROM / SENDER / REPLY-TO） メッセージへの応答用のアドレスリストを自動的に生成するシステムの ためには、以下の勧告がなされています： o "Sender"フィールドメールボックスは、オリジナルなメッセー ジの転送もしくは配達での如何なる問題の覚書を送信すべきで す。"Sender"がないなら、 "From"フィールドメールボックスが 使われるべきです。 o "Sender"フィールドメールボックスは、受信者の返答メッセー ジで、自動的に使用されるべきではありません。 o "Reply-To"フィールドがあるならば、返答はそのフィールドで 示唆されているアドレス、"From"フィールドで示唆されている アドレスではなく、に送るべきです。 August 13, 1982 - 22 - RFC #822 Standard for ARPA Internet Text Messages o "From"フィールドあり"Reply-To"がない場合、返答は"From" フィールドで示唆されているアドレスに送信されるべきです。 時には受信者はそのメッセージをはじめた人と実際に交流したいと思う こともあるかもしれません。そのような場合"Sender"のアドレスを使う のは理に適っています。 この勧告で、著者（originator）フィールドの自動利用のことだけが意 図され、応答がその他のメッセージ受信者にも送られることを示唆する ことが意図されていません。どんな追加機能が提供されるかを決めるの は、各々のメール取り扱いプログラムしだいです。 付録Aに事例をあげています。 4.5. 受信者フィールド 4.5.1. TO / RESENT-TO このフィールドはメッセージの主要な受取人の同定を内容とします。 4.5.2. CC / RESENT-CC このフィールドはメッセージの副次的な（情報を求める）受取人の同定 を内容とします。 4.5.3. BCC / RESENT-BCC このフィールドはメッセージの追加受取人の同定を内容とします。この フィールドの内容は、主要な受取人と副次的な受取人に送信されるメッ セージの写しには含まれません。システムによっては、著者の写しにだ け"Bcc"のテキストを含むことを選ぶものもあり、一方別のものは"Bcc" リストで示唆された人全てに送られるテキストに、それも含むかもしれ ません。 4.6. 参照フィールド 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID このフィールドはユニークな識別子（ローカル部分のおアドレス単 位）を内容とし、これはこのメッセージのこの版を照合します。メッ セージ識別子の唯一性は生成したホストによって保証されます。この識 別子は、機械判読性で人に必要な意味合いではないことを意図していま す。メッセージ識別子は特殊なメッセージの正確に一つの例示にふさわ しいものです；それに続くメッセージ版は各々、新しい識別子を受け取 August 13, 1982 - 23 - RFC #822 Standard for ARPA Internet Text Messages るべきです。 4.6.2. IN-REPLY-TO このフィールドの内容は、このメッセージが答える直前の通信者を 同定します。メッセージ識別子がこのフィールドで使用されているら、 msg-id仕様書式を使わなければならないことに注意してください。 4.6.3. 参照（REFERENCES） このフィールドの内容は、メッセージが照合している別の通信者を 同定します。メッセージ識別子が使用されているなら、 msg-id仕様書式 をしようしなければならないことに注意してください。 4.6.4. キーワード（KEYWORDS） このフィールドは、コンマで区切られた、キーワードもしくはプ レーズ（句）を内容としています。 4.7. その他のフィールド 4.7.1. 表題（SUBJECT） これはメッセージの要約を提供することもしくその性質を示唆する ことを意図しています。 4.7.2. コメント（COMMENTS） テキストに、メッセージのボディの内容を邪魔することなく、メッ セージにコメントを付け加えることを許しています。 4.7.3. 暗号化（ENCRYPTED） 時には、データー暗号がメッセージ内容のプライヴァシーを増すた めに、使用されます。メッセージボディ、その内容を個人的なものにす るために、が暗号化されているなら、「暗号化」ファイルが、暗号の事 実を知らせ、その性質を示唆するために、使用されます。最初の パラメーターは、そのボディを暗号化するのに使われたソフトウェアー を指し、二番目、選択性の、は適切な復元キーの選択で受信者を 助けます。このコード単語は、受信者が持っているキー表への索引とし て閲覧されるかもしれません。 注意： 残念ながら、ヘッダーは内容・情報と同様に封筒を内容にしなけ ればなりません。その結果暗号化されないままにしておくことが 必要で、従ってメール転送サービスはアクセスするかもしれませ ん。名前・アドレスそして表題（Subject）フィールド内容は微妙 August 13, 1982 - 24 - RFC #822 Standard for ARPA Internet Text Messages な情報を内容としているので、この要求はメッセージのプライバ シーそのものを制限します。 暗号ソフトウェアー名は、Net-work Information Center, SRI International, Menlo Park, Cali-fornia に登録されています。 4.7.4. 拡張-フィールド（EXTENSION-FIELD） 一定数の共通フィールドがこの文書で定義されています。ネット ワークメール要求が指示するように、追加フィールドは標準化されるか もしれません。名前選択で適度に安全な利用者定義フィールド（user- defined-fields）を提供するために、"X-" 文字列ではじまる名前をもた ない拡張フィールドを提供します。 拡張フィールドの名前は、the Network Information Center, SRI International, Menlo Park, California に登録されます。 4.7.5. 利用者-定義フィールド（USER-DEFINED-FIELD） ネットワークメールの個人の利用者は、追加ヘッダーフィールドを 自由に定義利用できます。そのようなフィールドはこの文書もしくは拡 張フィールドの定義でまだ使用されていない名前を持たなければなりま せんし、これら利用者定義フィールド（user-defined-fields）の構文全 部がこの仕様書のフィールド区別と折り重ねの規則に適合しなければな りません。拡張フィールド公開過程によって、利用者定義フィールド （user-defined-fields）の名前は先に専有されているかもしれません。 注意： 前置き的な"X-"文字列は拡張フィールドの名前に使用されませ ん。これは、保護された一式の名前で利用者定義フィールド（user- defined-fields）を提供しています。 [#^] August 13, 1982 - 25 - RFC #822 Standard for ARPA Internet Text Messages 5. 日付と時刻仕様 5.1. 構文 date-time = [ day "," ] date time ; dd mm yy ; hh:mm:ss zzz day = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" date = 1*2DIGIT month 2DIGIT ; day month year ; e.g. 20 Jun 82 month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" time = hour zone ; ANSI and Military hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] ; 00:00:00 - 23:59:59 zone = "UT" / "GMT" ; 世界時（Universal Time） ; North American : UT / "EST" / "EDT" ; Eastern: - 5/ - 4 / "CST" / "CDT" ; Central: - 6/ - 5 / "MST" / "MDT" ; Mountain: - 7/ - 6 / "PST" / "PDT" ; Pacific: - 8/ - 7 / 1ALPHA ; Military: Z = UT; ; A:-1; (J not used) ; M:-12; N:+1; Y:+12 / ( ("+" / "-") 4DIGIT ) ; ローカル差 ; 時間+分 (HHMM) 5.2. 意味 あれば、曜日による日（day-of-week）が日仕様によって言外にいわれ た日でなければなりません。 時間帯は幾つかの方法で示唆されるかもしれません。 "UT"は世界時= Universal Time（正式にはグリニッジ平均時"Greenwich Mean Time"言われ る）；"GMT"は世界時への照合として同意されています。軍標準は各ゾーン で単一文字を使用しています。"Z"は世界時です。"A"は一時間前、"M"は12 時間前を示唆しています。"N"は一時間後で、"Y"は12時間後を示唆していま す。文字"J" は使用されていません。その他の残りの二つの形式はANSI 標 準 X3.51-1975から取られています。ひとつはUTからの差の量の明示的な示 唆を許し；もう一つは北米での時間帯を示唆するのにコンマ三文字連続体を 使用します。 [#^] August 13, 1982 - 26 - RFC #822 Standard for ARPA Internet Text Messages 6. アドレス仕様 6.1. 構文 address = mailbox ; one addressee / group ; named list group = phrase ":" [#mailbox] ";" mailbox = addr-spec ; simple address / phrase route-addr ; name & addr-spec route-addr = "<" [route] addr-spec ">" route = 1#("@" domain) ":" ; path-relative addr-spec = local-part "@" domain ; global address local-part = word *("." word) ; uninterpreted ; case-preserved domain = sub-domain *("." sub-domain) sub-domain = domain-ref / domain-literal domain-ref = atom ; symbolic reference 6.2. 意味 メールボックスは、ファイル貯蔵に必然的に関連しない概念的な実体 です。例えば、サイトによっては行プリンターにメールを印刷し、出力をそ のアドレスの机に配達することを選ぶかもしれません。 メールボックス仕様は、人・システム・過程の名前参照・ドメイン依 存文字列そして名前-ドメイン（name-domain）参照からなります。名前-ド メイン（name-domain）参照は一連のサブ-ドメインを特定します。ドメイン 依存文字列は、最終サブ-ドメインによる場合を除いて、解釈されません； 残りのメールサービスは単に文字列として転送するだけです。 6.2.1. ドメイン（DOMAINS） name-domain（ドメイン名）は一式の登録された（メール）名です。 name-domain（ドメイン名）仕様は下位name-domain（ドメイン名）もし くは末端ドメイン依存文字列に分解します。従って、ドメイン仕様は拡 張性で幾つもの登録レベルを許容します。 August 13, 1982 - 27 - RFC #822 Standard for ARPA Internet Text Messages ドメイン名は、世界規模で論理的で階層構造化アドレス体系をなしてい ます。このモデルは、アドレス仕様が登録名に関わり転送経路に結び付 けられる必要はないという点で、論理的なものです。モデルの階層構造 は、方向付けられたグラフ、木樹状と言われ、というのも木の根元から 階層構造の如何なる結節点へも行く単一な経路があるからです。実際に 一つ以上の経路が存在するなら、それは別のアドレスと考えられます。 根元の結節（ルートノード）は全てのアドレスに共通です；従って、そ れは照合されません。その子がドメイン名のトップレベル"top-level"を 構成します。通常、サーバーはその全ドメイン仕様と全てのトップレベ ルドメイン名にアクセスします。 ドメイン接近階層のトップは -- 根元（ルート）の子 -- は、ドメイン 仕様で最も右のフィールドによって示唆されます。その子はその左に、 そのまた子はその左にと続きます。 グループによっては公式な登録サービスを提供しています；これらは特 別な機械に論理的に依存しないドメイン名を構成しています。さらに、 それらの会員は通常名前表に登録されているので、ネットワークと機械 は事実上ドメイン名を組み立てています。 公式な登録の例で、組織（ organization ）は、この書式のアドレスの ためのアドレス=ルート割り当てを提供する（配布された）データーベー スを装備しています。 person@registry.organization "organization"は、如何なる特殊な交流ネットワークから分離した、論 理的な実体であることに注意してください。 Note that "organization" is a logical entity, separate from any particular communication network. "organization"にアクセスする機構は広く入手可能です。この機構は順 に登録例示を探します；その場所はアドレス仕様に示唆されていません。 "organization"名の下で操作しているシステムが、下位の登録を見付け 出す方法を知っていると推測されています。次いでその登録は、メール 仕様を何処に送るかを決めるために、人＝"person"文字列を使用します。 後者のネットワーク指向例は、以下のような単純な直接的な添え付け-関 連アドレス仕様を許します： user@host.network 一旦そのネットワーク（network）にアクセスすれば、メッセージは直接 ホストに行きそしてそのホストが利用者名を解決しその利用者の郵便箱 にメッセージを置くと期待されています。 August 13, 1982 - 28 - RFC #822 Standard for ARPA Internet Text Messages にメッセージを置くと期待されています。 6.2.2. 省略されたドメイン仕様（ABBREVIATED DOMAIN SPECIFICATION） ドメイン階層内ではどのレベルも可能なので、全指定アドレスの仕様は 不便なこともあります。この標準では、特別な場合省略されたドメイン 仕様も許されています： 送信者のアドレスについては、最左翼のサブ-ドメインをレベルNと いいます。ヘッダーアドレスで、レベルN（例えば、右の）以上のサ ブ-ドメインの全てが、送信者のそれと同じならば、その時はこの仕 様で現われる必要はありません。そうでない場合はアドレスは全部 指定されなくてはなりません。 この機能はローカルドメインの承認に従います。個々のサブドメイ ンは、全ドメイン仕様を提供するために、メールに元を発する会員 システムを要求するかもしれません。許されれば、省略は、メッ セージが送信者のサブ-ドメインにある間だけ、存在します。 この機構の使用は、全トップレベル名を保存するために、送信者の サブドメインを要求し、というのも全仕様は省略仕様から区別され ることができなければならないからです。 例えば、送信者のアドレスが： sender@registry-A.registry-1.organization-X そして、受信者のアドレスが： recipient@registry-B.registry-1.organization-X そして、別の人アドレスが： recipient@registry-C.registry-2.organization-X そこで、".registry-1.organization-X" はメッセージで特定される必要 はありませんが、"registry-C.registry-2" は特定されなければなりま せん。つまり、最初の二つのアドレスは省略されるかもしれませんが、 三番目のアドレスは完全に特定されなければなりません。 メッセージがドメイン境界を越える場合、アドレス全てが、右端にトッ プレベルドメイン名で終る、完全な書式で特定されなければなりませ When a message crosses a domain boundary, all addresses must be specified in the full format, ending with the top-level name-domain in the right-most field. It is the responsibility of mail forwarding services to ensure that addresses conform August 13, 1982 - 29 - RFC #822 Standard for ARPA Internet Text Messages ん。アドレスがこの要求に適合しているかを確認することは、メール返 却サービスの責任です。省略アドレスに場合、中継サービスは必要な展 開をしなければなりません。アドレス省略の全ての存在の位置を決める ことは、そのようなサービスにとって、しばしば困難です。例えば、 メッセージのボディ内でそのような省略を見付け出すことは出来ませ ん。"Return-Path"フィールドが、これらのエラーからの回復の際、受信 者を助けます。 Note: When passing any portion of an addr-spec onto a process which does not interpret data according to this stan- dard (e.g., mail protocol servers). There must be NO LWSP-chars preceding or following the at-sign or any delimiting period ("."), such as shown in the above examples, and only ONE SPACE between contiguous s. 6.2.3. ドメイン用語（DOMAIN TERMS） domain-refは登録・ネットワークもしくはホストの公式名でなければな りません。それは、サブドメイン名内で、記号照合です。協調ホスト名 ではなくネットワークホストアドレスといったより基本的な（プリミ ティブな）情報を使って、その様な照合を解決する標準機構を迂回する ことが時には必要です。 A domain-ref must be THE official name of a registry, network, or host. It is a symbolic reference, within a name sub- domain. At times, it is necessary to bypass standard mechan- isms for resolving such references, using more primitive information, such as a network host address rather than its associated host name. この標準は、そのような照合を許すために、 domain-literal構成を提供 しています。その内容は、解釈されるサブドメインの要求と適合してい なければなりません。 To permit such references, this standard provides the domain- literal construct. Its contents must conform with the needs of the sub-domain in which it is interpreted. ARPAインターネットないのドメインを照合するdomain-literalは、 Request for Comments #822で記載されているように、十進値で記載さ れている8ビットフィールドで、32ビットインターネットアドレスを特定 します。例えば： Domain-literals which refer to domains within the ARPA Inter- net specify 32-bit Internet addresses, in four 8-bit fields noted in decimal, as described in Request for Comments #820, "Assigned Numbers." For example: [10.0.3.19] 注意： DOMAIN-LITERALSの使用はあまり薦められません。完全でない名 前表といった一時的なシステム制限を迂回する手段としてだけに許され ます。 Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It is permitted only as a means of bypassing temporary system limitations, such as name tables which are not complete. トップレベルドメイン名やARPAインターネット上のドメイン名は、ネッ トワーク情報センター・国際SRI・Menlo Park, Californiaに登録されて います。 The names of "top-level" domains, and the names of domains under in the ARPA Internet, are registered with the Network Information Center, SRI International, Menlo Park, California. 6.2.4. ドメイン依存ローカル文字列（DOMAIN-DEPENDENT LOCAL STRING） The local-part of an addr-spec in a mailbox specification (i.e., the host's name for the mailbox) is understood to be August 13, 1982 - 30 - RFC #822 Standard for ARPA Internet Text Messages whatever the receiving mail protocol server allows. For exam- ple, some systems do not understand mailbox references of the form "P. D. Q. Bach", but others do. This specification treats periods (".") as lexical separators. Hence, their presence in local-parts which are not quoted- strings, is detected. However, such occurrences carry NO semantics. That is, if a local-part has periods within it, an address parser will divide the local-part into several tokens, but the sequence of tokens will be treated as one uninter- preted unit. The sequence will be re-assembled, when the address is passed outside of the system such as to a mail pro- tocol service. For example, the address: First.Last@Registry.Org is legal and does not require the local-part to be surrounded with quotation-marks. (However, "First Last" DOES require quoting.) The local-part of the address, when passed outside of the mail system, within the Registry.Org domain, is "First.Last", again without quotation marks. 6.2.5. ローカル部分とドメインの均衡（BALANCING LOCAL-PART AND DOMAIN） In some cases, the boundary between local-part and domain can be flexible. The local-part may be a simple string, which is used for the final determination of the recipient's mailbox. All other levels of reference are, therefore, part of the domain. For some systems, in the case of abbreviated reference to the local and subordinate sub-domains, it may be possible to specify only one reference within the domain part and place the other, subordinate name-domain references within the local-part. This would appear as: mailbox.sub1.sub2@this-domain Such a specification would be acceptable to address parsers which conform to RFC #733, but do not support this newer Internet standard. While contrary to the intent of this stan- dard, the form is legal. Also, some sub-domains have a specification syntax which does not conform to this standard. For example: sub-net.mailbox@sub-domain.domain August 13, 1982 - 31 - RFC #822 Standard for ARPA Internet Text Messages uses a different parsing sequence for local-part than for domain. Note: As a rule, the domain specification should contain fields which are encoded according to the syntax of this standard and which contain generally-standardized information. The local-part specification should con- tain only that portion of the address which deviates from the form or intention of the domain field. 6.2.6. 多元メールボックス（MULTIPLE MAILBOXES） An individual may have several mailboxes and wish to receive mail at whatever mailbox is convenient for the sender to access. This standard does not provide a means of specifying "any member of" a list of mailboxes. A set of individuals may wish to receive mail as a single unit (i.e., a distribution list). The construct permits specification of such a list. Recipient mailboxes are speci- fied within the bracketed part (":" - ";"). A copy of the transmitted message is to be sent to each mailbox listed. This standard does not permit recursive specification of groups within groups. While a list must be named, it is not required that the con- tents of the list be included. In this case, the
serves only as an indication of group distribution and would appear in the form: name:; Some mail services may provide a group-list distribution facility, accepting a single mailbox reference, expanding it to the full distribution list, and relaying the mail to the list's members. This standard provides no additional syntax for indicating such a service. Using the address alternative, while listing one mailbox in it, can mean either that the mailbox reference will be expanded to a list or that there is a group with one member. 6.2.7. 明示的な経路仕様（EXPLICIT PATH SPECIFICATION） At times, a message originator may wish to indicate the transmission path that a message should follow. This is called source routing. The normal addressing scheme, used in an addr-spec, is carefully separated from such information; the portion of a route-addr is provided for such occa- sions. It specifies the sequence of hosts and/or transmission August 13, 1982 - 32 - RFC #822 Standard for ARPA Internet Text Messages services that are to be traversed. Both domain-refs and domain-literals may be used. Note: The use of source routing is discouraged. Unless the sender has special need of path restriction, the choice of transmission route should be left to the mail tran- sport service. 6.3. 予約アドレス（RESERVED ADDRESS） 正しいアドレスを知らないで、メールをサイトに送信することが、し ばしば必要になります。例えば、メールシステム機能不全があるかもしれま せんし、利用者がそのサイトで人の正しいアドレスを見付け出したと思って いるかもしれません。 この仕様書は、一つの予約された郵便箱アドレス（ローカルな）、そ のサイトで正しいとされねばならない、を特定します。そのアドレスに送る メールは、そのサイトのメールシステムに責任ある人もしくは一般的なサイ ト操作の責任を持った人への道筋を決めます。この予約されたローカルのア ドレス名： Postmaster それで、"Postmaster@domain"は正しいものであるとして要求されます。 注意： この予約されたローカル部分は、アルファベットの大文字小文字を 区別しなくて、"POSTMASTER"・"postmas-ter"そして"poStmASteR"で さえも受け入れます。 [#^] August 13, 1982 - 33 - RFC #822 Standard for ARPA Internet Text Messages 7. 文献 ANSI. "USA Standard Code for Information Interchange," X3.4. American National Standards Institute: New York (1968). Also in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand- book", NIC 7104. ANSI. "Representations of Universal Time, Local Time Differen- tials, and United States Time Zone References for Information Interchange," X3.51-1975. American National Standards Insti- tute: New York (1975). Bemer, R.W., "Time and the Computer." In: Interface Age (Feb. 1979). Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther- ford and Appleton Laboratory: Didcot, England. Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E. "Standardizing Network Mail Headers," ARPANET Request for Comments No. 561, Network Information Center No. 18516; SRI International: Menlo Park (September 1973). Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D. "Grapevine: An Exercise in Distributed Computing," Communica- tions of the ACM 25, 4 (April 1982), 260-274. Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A. "Standard for the Format of ARPA Network Text Message," ARPANET Request for Comments No. 733, Network Information Center No. 41952. SRI International: Menlo Park (November 1977). Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Net- work Information Center No. 7104 (NTIS AD A003890). SRI International: Menlo Park (April 1976). Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass. (1969). Levin, R. and Schroeder, M. "Transport of Electronic Messages through a Network," TeleInformatics 79, pp. 29-33. North Holland (1979). Also as Xerox Palo Alto Research Center Technical Report CSL-79-4. Myer, T.H. and Henderson, D.A. "Message Transmission Protocol," ARPANET Request for Comments, No. 680, Network Information Center No. 32116. SRI International: Menlo Park (1975). August 13, 1982 - 34 - RFC #822 Standard for ARPA Internet Text Messages NBS. "Specification of Message Format for Computer Based Message Systems, Recommended Federal Information Processing Standard." National Bureau of Standards: Gaithersburg, Maryland (October 1981). NIC. Internet Protocol Transition Workbook. Network Information Center, SRI-International, Menlo Park, California (March 1982). Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized Agent for Locating Named Objects in a Distributed Environ- ment," OPD-T8103. Xerox Office Products Division: Palo Alto, CA. (October 1981). Postel, J.B. "Assigned Numbers," ARPANET Request for Comments, No. 820. SRI International: Menlo Park (August 1982). Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request for Comments, No. 821. SRI International: Menlo Park (August 1982). Shoch, J.F. "Internetwork naming, addressing and routing," in Proc. 17th IEEE Computer Society International Conference, pp. 72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C. Su, Z. and Postel, J. "The Domain Naming Convention for Internet User Applications," ARPANET Request for Comments, No. 819. SRI International: Menlo Park (August 1982). [#^] August 13, 1982 - 35 - RFC #822 Standard for ARPA Internet Text Messages 付録 A. 事例 A.1. アドレス（ADDRESSES） A.1.1. Alfred Neuman A.1.2. Neuman@BBN-TENEXA これら二つの"Alfred Neuman"の例は、ローカルホストのメール送 信（配布）プログラム（また時には「メーラー="mailer"と言われま す）と遠隔ホストのメール・プロトコール（手順）が関わる範囲で、全 く構文的です。最初の例で、"Neuman@BBN-TENEXA" が完全に受信者を特 定しますので、"Alfred Neuman"はメーラーによって無視されます。二 番目の例はなんら余分な情報を内容にしてなくて、またこれも "Neuman@BBN-TENEXA" が意図された受信者です。 注意： メッセージがドメイン名（name-domain）境界を越えていく際、 これら仕様が変更、残りの階層を知らせるのにトップレベル から開 始しするといった、されなければなりません。 A.1.3. "George, Ted" この書式は、単一メールボックスが数人の利用者によって割り当て られていることを知らせるのに使われます。引用文字列はオリジナルホ ストのメーラーによって無視されます、というのも"Shared@Group.Arpanet" が行き先メールボックスを完全に特定しているからです。 A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US "(the Stilt)"はコメントで、始めのシステムのメーラーに手渡さ れた、宛先メールボックスアドレスに含まれません。アドレスのローカル 部分は"Wilt.Chamberlain"という文字列で、最初と二番目の単語の間にス ペースはありません。 A.1.5. アドレス一覧（Address Lists） Gourmets: Pompous Person , Childs@WGBH.Boston, Galloping Gourmet@ ANT.Down-Under (Australian National Television), Cheapie@Discount-Liquors;, Cruisers: Port@Portugal, Jones@SEA;, Another@Somewhere.SomeOrg August 13, 1982 - 36 - RFC #822 Standard for ARPA Internet Text Messages このグループリストの例は、コメント使用と、アドレスとグループの混 在を示しています。 A.2. 著者（創作者）項目（ORIGINATOR ITEMS） A.2.1. 著者送信（Author-sent） George Jonesが自身のホストに "Jones"としてログインします。彼 はメールを自分自身に送信します。 From: Jones@Group.Org もしくは From: George Jones A.2.2. 秘書（事務局）送信（Secretary-sent） George Jonesは自身のホスト上のJonesとしてログインします。か れの秘書は、彼のための秘書としてログインしている。そのメールへの 返答メールは、Georgeに行かなければなりません。 From: George Jones Sender: Secy@Other-Group A.2.3. 割り当てられたディレクトリ利用者用秘書送信 （Secretary-sent, for user of shared directory） George Jonesの秘書がGeorgeのためにメールを送信します。返事は Georgeへ行くべきです。 From: George Jones Sender: Secy@Other-Group "Jones"と"<"の間にスペースは必要ありませんが、スペースを追加する ことは読み易さを高めます（別の例で見るように）。 A.2.4. 一人の著者による委員会活動 　　　 （Committee activity, with one author） Georgeは委員会のメンバーです。彼のメッセージへの返答を全ての 委員会メンバーに行かせたいと思っています。 From: George Jones Sender: Jones@Host Reply-To: The Committee: Jones@Host.Net, Smith@Other.Org, Doe@Somewhere-Else; 注意： Georgeが委員会の列挙に自分自身を含めていないなら、来るだろ うと思っている返答を得られません；"Reply-to"があると、"From"フィド August 13, 1982 - 37 - RFC #822 Standard for ARPA Internet Text Messages ールで命名されている人への返答送信を置き代えます。 A.2.5. 著者の全代理人としての秘書の行動 （Secretary acting as full agent of author） George Jonesは彼の秘書（Secy@Host）に、グループとしてかれの 資格で彼のためにメッセージを送信してもらいたい。彼は秘書に全ての 返事を取り扱ってもらいたい。 From: George Jones Sender: Secy@Host Reply-To: Secy@Host A.2.6. オンラインメールボックスでない利用者の代理 （Agent for user without online mailbox） Georgeの友達Sarahが来ています。Georgeの秘書は、コンピュー ターランドにいるSarahの友達に或るメールを送ります。返事は、登録で メールボックスがJonesとなっている、Georgeに行くべきです。 From: Sarah Friendly Sender: Secy-Name Reply-To: Jones@Registry. A.2.7. 委員会のメンバーの代理 （Agent for member of a committee） Georgeの秘書は、委員会の全メンバーによって共同で制作された、 メッセージを送信します。名はFromフィールドでは許されていな いので、委員会の名前は特定されていないことに注意してください。 From: Jones@Host, Smith@Other-Host, Doe@Somewhere-Else Sender: Secy@SHost August 13, 1982 - 38 - RFC #822 Standard for ARPA Internet Text Messages A.3. 完全なヘッダー（COMPLETE HEADERS） A.3.1. 最小要求（Minimum required） Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT From: Jones@Registry.Org or From: Jones@Registry.Org Bcc: To: Smith@Registry.Org "Bcc" フィールドは空かもしれませんし、一方"To"フィールドは少なく とも一つアドレスが来ることが必須であることに注意してください。 A.3.2. 追加フィールドを使用（Using some of the additional fields） Date: 26 Aug 76 1430 EDT From: George Jones Sender: Secy@SHOST To: "Al Neuman"@Mad-Host, Sam.Irving@Other-Host Message-ID: A.3.3. あなたに届くのと同じ複雑な例 （About as complex as you're going to get） Date : 27 Aug 76 0932 PDT From : Ken Davis Subject : Re: The Syntax in the RFC Sender : KSecy@Other-Host Reply-To : Sam.Irving@Reg.Organization To : George Jones , Al.Neuman@MAD.Publisher cc : Important folk: Tom Softwood , "Sam Irving"@Other-Host;, Standard Distribution: /main/davis/people/standard@Other-Host, "standard.dist.3"@Tops-20-Host>; Comment : Sam is away on business. He asked me to handle his mail for him. He'll be able to provide a more accurate explanation when he returns next week. In-Reply-To: , George's message X-Special-action: This is a sample of user-defined field- names. There could also be a field-name "Special-action", but its name might later be preempted Message-ID: <4231.629.XYzi-What@Other-Host> [#^] August 13, 1982 - 39 - RFC #822 Standard for ARPA Internet Text Messages B. 簡潔なフィールド解析 メールリーダーソフトウェアーによっては、最小の処理だけで、構造 化されたフィールドボディを無視し、非構造化フィールドボディと同じよう にそれらを処理したしたいものもあります。そのようなソフトウェアーは識 別することだけを求めています： o メッセージボディからヘッダーフィールド o フィールドに続く行からフィールドの開始 o フィールド内容からフィールド名 以下の構文の規則の省略一式はこの目的に十分です。それはメッセー ジの制限された閲覧を記載し、この仕様書の主な部分で提供されている構文 規則のサブセット（下位集合）です。小さな一つの例外は、フィールドボ ディの内容はテキストだけから構成されていることです： B.1. 構文 message = *field *(CRLF *text) field = field-name ":" [field-body] CRLF field-name = 1* field-body = *text [CRLF LWSP-char field-body] B.2. 意味 ヘッダーはメッセージボディの前にき、ヌール行（すなわち、二つの 連続したCRLF）によって終ります。 ヘッダーフィールドに続く行は、スペースもしくはHTAB文字で始ま り、一方フィールドを始める行は印字可能な文字、コロンではない、で始ま ります。 フィールド名は一つ以上の印字可能な文字（コロン・スペースそして 制御文字を除く）から構成されています。フィールド名は一行に収まらなく てはなりません。フィールド名を比較する際大文字小文字は区別されません。 [#^] August 13, 1982 - 40 - RFC #822 Standard for ARPA Internet Text Messages C. RFC #733との違い 以下で、この仕様書とArpanet Request for Comments #733、 "Standard for the Format of ARPA Network Text Messages"、との相 違を要約しています。相違は、当該仕様書での項目順に、リストされてい ます。 C.1. フィールド定義 C.1.1. フィールド名 These now must be a sequence of printable characters. They may not contain any LWSP-chars. C.2. 語彙トクン C.2.1. SPECIALS The characters period ("."), left-square bracket ("["), and right-square bracket ("]") have been added. For presentation purposes, and when passing a specification to a system that does not conform to this standard, periods are to be contigu- ous with their surrounding lexical tokens. No linear-white- space is permitted between them. The presence of one LWSP- char between other tokens is still directed. C.2.2. アトム（ATOM） Atoms may not contain SPACE. C.2.3. 特別なテキスト ctext and qtext have had backslash ("\") added to the list of prohibited characters. C.2.4. ドメイン（DOMAINS） The lexical tokens and have been added. C.3. メッセージ仕様 C.3.1. 軌跡（TRACE） The "Return-path:" and "Received:" fields have been specified. August 13, 1982 - 41 - RFC #822 Standard for ARPA Internet Text Messages C.3.2. FROM The "From" field must contain machine-usable addresses (addr- spec). Multiple addresses may be specified, but named-lists (groups) may not. C.3.3. RESENT The meta-construct of prefacing field names with the string "Resent-" has been added, to indicate that a message has been forwarded by an intermediate recipient. C.3.4. DESTINATION A message must contain at least one destination address field. "To" and "CC" are required to contain at least one address. C.3.5. IN-REPLY-TO The field-body is no longer a comma-separated list, although a sequence is still permitted. C.3.6. REFERENCE The field-body is no longer a comma-separated list, although a sequence is still permitted. C.3.7. 暗号化（ENCRYPTED） A field has been specified that permits senders to indicate that the body of a message has been encrypted. C.3.8. 拡張-フィールド（EXTENSION-FIELD） Extension fields are prohibited from beginning with the char- acters "X-". C.4. 日付と時刻仕様（DATE AND TIME SPECIFICATION） C.4.1. 簡素化（SIMPLIFICATION） Fewer optional forms are permitted and the list of three- letter time zones has been shortened. C.5. アドレス仕様（ADDRESS SPECIFICATION） August 13, 1982 - 42 - RFC #822 Standard for ARPA Internet Text Messages C.5.1. アドレス（ADDRESS） The use of quoted-string, and the ":"-atom-":" construct, have been removed. An address now is either a single mailbox reference or is a named list of addresses. The latter indi- cates a group distribution. C.5.2. グループ（GROUPS） Group lists are now required to to have a name. Group lists may not be nested. C.5.3. メールボックス（MAILBOX） A mailbox specification may indicate a person's name, as before. Such a named list no longer may specify multiple mailboxes and may not be nested. C.5.4. 経路アドレス（ROUTE ADDRESSING） Addresses now are taken to be absolute, global specifications, independent of transmission paths. The construct has been provided, to permit explicit specification of transmis- sion path. RFC #733's use of multiple at-signs ("@") was intended as a general syntax for indicating routing and/or hierarchical addressing. The current standard separates these specifications and only one at-sign is permitted. C.5.5. AT記号（AT-SIGN） The string " at " no longer is used as an address delimiter. Only at-sign ("@") serves the function. C.5.6. ドメイン（DOMAINS） Hierarchical, logical name-domains have been added. C.6. 予約アドレス（RESERVED ADDRESS） The local-part "Postmaster" has been reserved, so that users can be guaranteed at least one valid address at a site. [#^] August 13, 1982 - 43 - RFC #822 Standard for ARPA Internet Text Messages D. 構文規則のアルファベット順一覧 address = mailbox ; one addressee / group ; named list addr-spec = local-part "@" domain ; global address ALPHA = ; (101-132, 65.- 90.) ; (141-172, 97.-122.) atom = 1* authentic = "From" ":" mailbox ; Single author / ( "Sender" ":" mailbox ; Actual submittor "From" ":" 1#mailbox) ; Multiple authors ; or not sender CHAR = ; ( 0-177, 0.-127.) comment = "(" *(ctext / quoted-pair / comment) ")" CR = ; ( 15, 13.) CRLF = CR LF ctext = may be folded ")", "\" & CR, & including linear-white-space> CTL = ; ( 177, 127.) date = 1*2DIGIT month 2DIGIT ; day month year ; e.g. 20 Jun 82 dates = orig-date ; Original [ resent-date ] ; Forwarded date-time = [ day "," ] date time ; dd mm yy ; hh:mm:ss zzz day = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" delimiters = specials / linear-white-space / comment destination = "To" ":" 1#address ; Primary / "Resent-To" ":" 1#address / "cc" ":" 1#address ; Secondary / "Resent-cc" ":" 1#address / "bcc" ":" #address ; Blind carbon / "Resent-bcc" ":" #address DIGIT = ; ( 60- 71, 48.- 57.) domain = sub-domain *("." sub-domain) domain-literal = "[" *(dtext / quoted-pair) "]" domain-ref = atom ; symbolic reference dtext = may be folded "]", "\" & CR, & including linear-white-space> extension-field = August 13, 1982 - 44 - RFC #822 Standard for ARPA Internet Text Messages field = field-name ":" [ field-body ] CRLF fields = dates ; Creation time, source ; author id & one 1*destination ; address required *optional-field ; others optional field-body = field-body-contents [CRLF LWSP-char field-body] field-body-contents = field-name = 1* group = phrase ":" [#mailbox] ";" hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] ; 00:00:00 - 23:59:59 HTAB = ; ( 11, 9.) LF = ; ( 12, 10.) linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE ; CRLF => folding local-part = word *("." word) ; uninterpreted ; case-preserved LWSP-char = SPACE / HTAB ; semantics = SPACE mailbox = addr-spec ; simple address / phrase route-addr ; name & addr-spec message = fields *( CRLF *text ) ; Everything after ; first null line ; is message body month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" msg-id = "<" addr-spec ">" ; Unique message id optional-field = / "Message-ID" ":" msg-id / "Resent-Message-ID" ":" msg-id / "In-Reply-To" ":" *(phrase / msg-id) / "References" ":" *(phrase / msg-id) / "Keywords" ":" #phrase / "Subject" ":" *text / "Comments" ":" *text / "Encrypted" ":" 1#2word / extension-field ; To be defined / user-defined-field ; May be pre-empted orig-date = "Date" ":" date-time originator = authentic ; authenticated addr [ "Reply-To" ":" 1#address] ) phrase = 1*word ; Sequence of words August 13, 1982 - 45 - RFC #822 Standard for ARPA Internet Text Messages qtext = , ; => may be folded "\" & CR, and including linear-white-space> quoted-pair = "\" CHAR ; may quote any char quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or ; quoted chars. received = "Received" ":" ; one per relay ["from" domain] ; sending host ["by" domain] ; receiving host ["via" atom] ; physical path *("with" atom) ; link/mail protocol ["id" msg-id] ; receiver msg id ["for" addr-spec] ; initial form ";" date-time ; time received resent = resent-authentic [ "Resent-Reply-To" ":" 1#address] ) resent-authentic = = "Resent-From" ":" mailbox / ( "Resent-Sender" ":" mailbox "Resent-From" ":" 1#mailbox ) resent-date = "Resent-Date" ":" date-time return = "Return-path" ":" route-addr ; return address route = 1#("@" domain) ":" ; path-relative route-addr = "<" [route] addr-spec ">" source = [ trace ] ; net traversals originator ; original mail [ resent ] ; forwarded SPACE = ; ( 40, 32.) specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word. sub-domain = domain-ref / domain-literal text = atoms, specials, CR & bare LF, but NOT ; comments and including CRLF> ; quoted-strings are ; NOT recognized. time = hour zone ; ANSI and Military trace = return ; path to sender 1*received ; receipt tags user-defined-field = word = atom / quoted-string August 13, 1982 - 46 - RFC #822 Standard for ARPA Internet Text Messages zone = "UT" / "GMT" ; Universal Time ; North American : UT / "EST" / "EDT" ; Eastern: - 5/ - 4 / "CST" / "CDT" ; Central: - 6/ - 5 / "MST" / "MDT" ; Mountain: - 7/ - 6 / "PST" / "PDT" ; Pacific: - 8/ - 7 / 1ALPHA ; Military: Z = UT; <"> = ; ( 42, 34.) [#^] August 13, 1982 - 47 - RFC #822