(Obsoletes RFC0733)
(Updated by RFC1123, RFC1138, RFC1148, RFC1327, RFC2156)
(Also STD0011) (Status: STANDARD)
Yasutaka Kato 加藤泰孝
<email:y.kato@personal.email.ne.jp>
<email:ykato-ind@umin.ac.jp>
［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. 命名規則
鈎括弧は（"<"、">"）は一般に使用されていません。規則の名前は、
"<name>"でなく単に名前そのものです。引用符号はその通りの文字（大文字
かもしくは小文字であるかもしれない）を囲います。或る種の基本的な規則
は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. *規則： 反復
要素の前の"*"文字は、繰り返しを指します。書式は：
<l>*<m>element
は、要素の最低<l>そして最高<m>出現を指します。既定値は0から無限大で、
"*(element)" は0を含めてどんな数値でもとります；"1*element" は少なく
とも一つを必要とします；そして "1*2element" は一つもしくは二つを許容
します。
2.5. [規則]： 選択
大括弧は選択性の要素を囲います； "[foo bar]" は "*1(foo bar)"
と同じものです。
2.6. n規則（NRULE）： 特別な反復
"<n>(element)" は "<n>*<n>(element)" と同じです；つまり、
正確に<n> (element) が出現します。かくて、2DIGITは2-数値、そして
3ALPHAは三つのアルファベット文字列です。
August 13, 1982 - 3 - RFC #822
Standard for ARPA Internet Text Messages
2.7. #規則： リスト
"#"構成は、"*" と似ていて、以下のように定義されます：
<l>#<m>element
最低<l>そして最高<m>要素、一つ以上のコンマ（","）でお互い分離され
た、を指します。これは有効なリスト書式を大変容易に作成します； '
(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" <ddd @Org>, JJV @ BBN
は、以下のように表現できます：
To: "Joe & J. Harvey" <ddd @ Org>,
JJV@BBN
や
To: "Joe & J. Harvey"
<ddd@ Org>, JJV
@BBN
や
To: "Joe &
J. Harvey" <ddd @ Org>, 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から126の間の十進値文字）。field-bodyはCRもしくはLFを
除いたASCII文字から構成されているかもしれません（CR と／若くはLF
が実際のテキストに来ていても、フィールドを折り重ねることで除去さ
れます）。
ヘッダーの或る種のフィールドボディは、システムによっては解析した
いと思う、内部構文に従って解釈されるかもしれません。例では、
フィールドにデーターとアドレスが来ています。別のフィールド、
注意： 単なる<text>以外と定義されたフィールドボディのあるフィー
ルドは、構造化されたフィールドとして処理されなければなり
ません。
Field-names・非構造化フィールドボディそして構造化フィール
ドボディは、自身の独立の、「語彙」分析によって、お互いに情
報を調べています。
3.1.3. 非構造化フィールド体（FIELD BODIES）
フィールドによっては、"Subject" と "Comments" のように、構造化は
ないと考えられ、単にメッセージボディの<text>として処理されます。
「折り重ね」の規則はこれらのフィールドに、数行を写すそのような
フィールドボディは、少なくとも一つの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
注意： 表示のためやそのような構造化された情報を別のシステムに渡す
際、メールプロトコールが提供するように、ピリオド（"."）も
しくはアットマーク("@")で分離された<words>s間に空白行はな
く、その他の<word>s全ての間にただ一つのスペースが来なけれ
ばなりません。また、ヘッダーは「折り重ね」書式になっていな
ければなりません。
August 13, 1982 - 8 - RFC #822
Standard for ARPA Internet Text Messages
3.2. ヘッダーフィールド定義
これらの規則はフィールド・メタ構文、特殊なタイプもしくは内部構
文問題を除いて、を示しています。この目的はフィールドの探知の機会を与
えることです；また一行にうまくはまる各フィールドのイメージを、高次レ
ベル解析に、提示します。
field = field-name ":" [ field-body ] CRLF
field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
field-body = field-body-contents
[CRLF LWSP-char field-body]
field-body-contents =
<ASCII文字が、以下のセクションで定義されているように、
フィールドボディを作りあげていて、atom・引用列そして
特別なトークン（字句）からもしくは他のテキストからな
っています>
August 13, 1982 - 9 - RFC #822
Standard for ARPA Internet Text Messages
3.3. 語彙トークン（語彙字句）
以下の規則は、基本的な語彙解析を定義するのに使われていて、高次
レベル解析にトークンを送り込みます。文献のANSI資料をみて下さい。
; ( Octal, Decimal.)
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
ALPHA = <any ASCII alphabetic character>
; (101-132, 65.- 90.)
; (141-172, 97.-122.)
DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
CR = <ASCII CR, carriage return> ; ( 15, 13.)
LF = <ASCII LF, linefeed> ; ( 12, 10.)
SPACE = <ASCII SP, space> ; ( 40, 32.)
HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
<"> = <ASCII quote mark> ; ( 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 = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.
atom = 1*<any CHAR except specials, SPACE and CTLs>
quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
; quoted chars.
qtext = <any CHAR excepting <">, ; => 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 = <any CHAR excluding "[", ; => may be folded
"]", "\" & CR, & including
linear-white-space>
comment = "(" *(ctext / quoted-pair / comment) ")"
ctext = <any CHAR excluding "(", ; => 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）文字はピリオド（"."）もしくはアットマーク（"@"）と<word>の
間に来るべきではありません。性格にただ一つのスペースが、任意の空
注意： この標準基準に適合するシステム内では、識別子のリストにある
ものはどれでも許され、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を作り、もしくは <null >によって
続けられることが要求されるかもしれません。そのような転送は、メッ
セージがそのネットワークを出る際、反対のことが行われます。
ネットワークの境界を越えていく際、メッセージは二つのモジュール
（プログラム構成単位）通過するものとして処理されるべきです。「当
該」ネットワークを通る移動が許されるのに必要なネット特有の転送を
なんでも内容としている、最初のモジュールに入ります。次いで、この
モジュールに手渡します：
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 =
<Any field which is defined in a document
published as a formal extension to this
specification; none will have names beginning
with the string "X-">
user-defined-field =
<Any field which has not been defined
in this specification or published as an
extension to this specification; names for
such fields must be unique and may be
pre-empted by published extensions>
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）
時には、データー暗号がメッセージ内容のプライヴァシーを増すた
めに、使用されます。メッセージボディ、その内容を個人的なものにす
るために、が暗号化されているなら、「暗号化」ファイルが、暗号の事
実を知らせ、その性質を示唆するために、使用されます。最初の <word>
パラメーターは、そのボディを暗号化するのに使われたソフトウェアー
を指し、二番目、選択性の<word>、は適切な復元キーの選択で受信者を
助けます。このコード単語は、受信者が持っているキー表への索引とし
て閲覧されるかもしれません。
注意： 残念ながら、ヘッダーは内容・情報と同様に封筒を内容にしなけ
ればなりません。その結果暗号化されないままにしておくことが
必要で、従ってメール転送サービスはアクセスするかもしれませ
ん。名前・アドレスそして表題（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
<word>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 <group> 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 <address>
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 <group> 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 <route> 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 <Neuman@BBN-TENEXA>
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>
この書式は、単一メールボックスが数人の利用者によって割り当て
られていることを知らせるのに使われます。引用文字列はオリジナルホ
ストのメーラーによって無視されます、というのも"Shared@Group.Arpanet"
が行き先メールボックスを完全に特定しているからです。
A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US
"(the Stilt)"はコメントで、始めのシステムのメーラーに手渡さ
れた、宛先メールボックスアドレスに含まれません。アドレスのローカル
部分は"Wilt.Chamberlain"という文字列で、最初と二番目の単語の間にス
ペースはありません。
A.1.5. アドレス一覧（Address Lists）
Gourmets: Pompous Person <WhoZiWhatZit@Cordon-Bleu>,
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 <Jones@Group.Org>
A.2.2. 秘書（事務局）送信（Secretary-sent）
George Jonesは自身のホスト上のJonesとしてログインします。か
れの秘書は、彼のための秘書としてログインしている。そのメールへの
返答メールは、Georgeに行かなければなりません。
From: George Jones <Jones@Group>
Sender: Secy@Other-Group
A.2.3. 割り当てられたディレクトリ利用者用秘書送信
（Secretary-sent, for user of shared directory）
George Jonesの秘書がGeorgeのためにメールを送信します。返事は
Georgeへ行くべきです。
From: George Jones<Shared@Group.Org>
Sender: Secy@Other-Group
"Jones"と"<"の間にスペースは必要ありませんが、スペースを追加する
ことは読み易さを高めます（別の例で見るように）。
A.2.4. 一人の著者による委員会活動
（Committee activity, with one author）
Georgeは委員会のメンバーです。彼のメッセージへの返答を全ての
委員会メンバーに行かせたいと思っています。
From: George Jones <Jones@Host.Net>
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 <Group@Host>
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 <Secy@Registry>
Sender: Secy-Name <Secy@Registry>
Reply-To: Jones@Registry.
A.2.7. 委員会のメンバーの代理
（Agent for member of a committee）
Georgeの秘書は、委員会の全メンバーによって共同で制作された、
メッセージを送信します。<group>名は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<Group@Host>
Sender: Secy@SHOST
To: "Al Neuman"@Mad-Host,
Sam.Irving@Other-Host
Message-ID: <some.string@SHOST>
A.3.3. あなたに届くのと同じ複雑な例
（About as complex as you're going to get）
Date : 27 Aug 76 0932 PDT
From : Ken Davis <KDavis@This-Host.This-net>
Subject : Re: The Syntax in the RFC
Sender : KSecy@Other-Host
Reply-To : Sam.Irving@Reg.Organization
To : George Jones <Group@Some-Reg.An-Org>,
Al.Neuman@MAD.Publisher
cc : Important folk:
Tom Softwood <Balsa@Tree.Root>,
"Sam Irving"@Other-Host;,
Standard Distribution:
/main/davis/people/standard@Other-Host,
"<Jones>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: <some.string@DBM.Group>, 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*<any CHAR, excluding CTLs, SPACE, and ":">
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 <domain-literal> and <dtext> 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 <route> 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 = <any ASCII alphabetic character>
; (101-132, 65.- 90.)
; (141-172, 97.-122.)
atom = 1*<any CHAR except specials, SPACE and CTLs>
authentic = "From" ":" mailbox ; Single author
/ ( "Sender" ":" mailbox ; Actual submittor
"From" ":" 1#mailbox) ; Multiple authors
; or not sender
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
comment = "(" *(ctext / quoted-pair / comment) ")"
CR = <ASCII CR, carriage return> ; ( 15, 13.)
CRLF = CR LF
ctext = <any CHAR excluding "(", ; => may be folded
")", "\" & CR, & including
linear-white-space>
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 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 = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
domain = sub-domain *("." sub-domain)
domain-literal = "[" *(dtext / quoted-pair) "]"
domain-ref = atom ; symbolic reference
dtext = <any CHAR excluding "[", ; => may be folded
"]", "\" & CR, & including
linear-white-space>
extension-field =
<Any field which is defined in a document
published as a formal extension to this
specification; none will have names beginning
with the string "X-">
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 =
<the ASCII characters making up the field-body, as
defined in the following sections, and consisting
of combinations of atom, quoted-string, and
specials tokens, or else consisting of texts>
field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
group = phrase ":" [#mailbox] ";"
hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
; 00:00:00 - 23:59:59
HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
LF = <ASCII LF, linefeed> ; ( 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 = <any CHAR excepting <">, ; => 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 = <ASCII SP, space> ; ( 40, 32.)
specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
/ "," / ";" / ":" / "\" / <"> ; string, to use
/ "." / "[" / "]" ; within a word.
sub-domain = domain-ref / domain-literal
text = <any CHAR, including bare ; => 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 =
<Any field which has not been defined
in this specification or published as an
extension to this specification; names for
such fields must be unique and may be
pre-empted by published extensions>
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;
<"> = <ASCII quote mark> ; ( 42, 34.)
[#^]
August 13, 1982 - 47 - RFC #822