3. 構文
3.1. 序論
本節で与えられる構文は、インターネットメッセージの合法な構文を定義します。本仕様に適合するメッセージは、本節の構文に適合しなければなりません (MUST)。本節に選択肢があり、そのうちの 1 つを生成すべき (SHOULD) である場合、それは本文中か、構文の隣のコメントで示されます。
定義された各式について、構文と用途の短い説明が与えられ、続いて ABNF による構文が与えられ、続いて意味論的な分析が与えられます。以下に挙げるプリミティブトークンで、他に規定のないものは、[RFC5234] の付録 B.1 の「コアルール」から取られています。すなわち CR、LF、CRLF、HTAB、SP、WSP、DQUOTE、DIGIT、ALPHA、および VCHAR です。
一部の定義には、名前が "obs-" で始まる非終端記号があります。これらの "obs-" 要素は、セクション 4 の廃止された構文で定義されるトークンを指します。すべての場合において、これらの生成規則は、合法なインターネットメッセージを生成するという目的のためには無視されるものであり、そのようなメッセージの一部として使用されてはなりません (MUST NOT)。しかし、メッセージを解釈する際には、これらのトークンは合法な構文の一部として尊重されなければなりません (MUST)。この意味で、セクション 3 は無視されるべき "obs-" 要素を含む、メッセージ生成のための文法を定義し、一方セクション 4 はメッセージ解釈のための文法を追加します。
3.2. 字句トークン
以下の規則は、高レベルのパーサーにトークンを供給する、基盤となる字句解析器を定義するために使用されます。本節は、構造化ヘッダーフィールド本体で使用されるトークンを定義します。
注意: 本仕様の読者は、これらの字句トークンが、本文書の後半の低レベルおよび高レベルの両方の構文でどのように使用されるかに特に注意を払う必要があります。特に、セクション 3.2.2 で定義される空白トークンとコメントトークンは、ここで定義される低レベルのトークンで使用され、それらの低レベルのトークンは、後に定義される高レベルのトークンの一部として使用されます。したがって、空白とコメントは、特定の定義に明示的に現れない場合でも、高レベルのトークンで許されることがあります。
3.2.1. 引用文字
一部の文字は、字句トークンを区切る場合のように、特別な解釈のために予約されています。これらの文字を解釈されないデータとして使用できるようにするために、引用機構が提供されています。
quoted-pair = ("\" (VCHAR / WSP)) / obs-qp
quoted-pair が現れるところではどこでも、それはその文字単独として解釈されます。すなわち、quoted-pair の一部として現れる "" 文字は、意味論的には「不可視」です。
注意: "" 文字は、quoted-pair の一部ではない形でメッセージに現れることがあります。quoted-pair に現れない "" 文字は、意味論的に不可視ではありません。本仕様で quoted-pair が現在現れるのは、ccontent、qcontent、およびセクション 4 の obs-dtext だけです。
3.2.2. 折り返し空白とコメント
空白文字は、折り返しで使用される空白 (セクション 2.2.3 で記述) を含めて、ヘッダーフィールド本体の多くの要素の間に現れることがあります。また、コメントとして扱われる文字列は、丸括弧で囲まれた文字として構造化フィールド本体に含めることができます。以下は、折り返し空白 (FWS) とコメントの構成要素を定義します。
丸括弧で囲まれた文字列は、セクション 3.2.4 で定義される「引用文字列 (quoted-string)」の中に現れない限り、コメントと見なされます。コメントは入れ子にすることができます。
本仕様には、コメントと FWS を自由に挿入できる箇所がいくつかあります。その構文に対応するために、コメントおよび/または FWS が現れることがある箇所のために、追加のトークン "CFWS" が定義されています。しかし、本仕様で CFWS が現れる箇所では、折り返されたヘッダーフィールドのある行が WSP 文字だけからなり他の何も含まないようになる形で挿入してはなりません (MUST NOT)。
FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
; Folding white space
ctext = %d33-39 / ; Printable US-ASCII
%d42-91 / ; characters not including
%d93-126 / ; "(", ")", or "\"
obs-ctext
ccontent = ctext / quoted-pair / comment
comment = "(" *([FWS] ccontent) [FWS] ")"
CFWS = (1*([FWS] comment) [FWS]) / FWS
本仕様全体を通じて、(折り返し空白トークンである) FWS が現れるところでは、セクション 2.2.3 で論じた折り返しを行うことができる箇所であることを示します。メッセージ中で折り返しが現れるところではどこでも (すなわち、CRLF の後に任意の WSP が続くものを含むヘッダーフィールド本体)、本仕様に従ってそのヘッダーフィールドに対してこれ以上の意味論的な分析が行われる前に、展開 (CRLF の除去) が行われます。すなわち、FWS に現れる任意の CRLF は、意味論的には「不可視」です。
コメントは通常、構造化フィールド本体において、人間が読める情報テキストを与えるために使用されます。コメントは FWS を含むことが許されているため、コメント内では折り返しが許されます。また、コメント内では quoted-pair が許されているため、丸括弧とバックスラッシュの文字は、quoted-pair として現れる限り、コメント内に現れることができます。意味論的には、囲んでいる丸括弧はコメントの一部ではありません。コメントとは、2 つの丸括弧の間に含まれるものです。先に述べたように、任意の quoted-pair における "" と、コメント内に現れる任意の FWS における CRLF は、意味論的に「不可視」であり、したがってコメントの一部でもありません。
構造化ヘッダーフィールド内の字句トークンの間に現れる FWS、comment、または CFWS の連なりは、意味論的には単一のスペース文字として解釈されます。
3.2.3. アトム
構造化ヘッダーフィールド本体におけるいくつかの生成規則は、単に特定の基本文字の文字列です。そのような生成規則はアトム (atom) と呼ばれます。
一部の構造化ヘッダーフィールド本体は、atext の連なりの中でのピリオド文字 (".", ASCII 値 46) も許容します。その目的のために、追加のトークン "dot-atom" が定義されています。
注意: "specials" トークンは、本仕様の他のどこにも現れません。それは単に、可視の (すなわち、制御文字でも空白文字でもない) 文字のうち、atext に現れないものです。これは、メッセージを字句解析するツールを使用する実装者にとって有用であるという理由だけで提供されています。specials の各文字は、字句解析におけるトークン化の区切り点を示すために使用することができます。
atext = ALPHA / DIGIT / ; Printable US-ASCII
"!" / "#" / ; characters not including
"$" / "%" / ; specials. Used for atoms.
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
atom = [CFWS] 1*atext [CFWS]
dot-atom-text = 1*atext *("." 1*atext)
dot-atom = [CFWS] dot-atom-text [CFWS]
specials = "(" / ")" / ; Special characters that do
"<" / ">" / ; not appear in atext
"[" / "]" /
":" / ";" /
"@" / "\" /
"," / "." /
DQUOTE
atom と dot-atom はともに、それを構成する文字列からなる単一の単位として解釈されます。意味論的には、残りの文字を囲む任意のコメントと FWS はアトムの一部ではありません。アトムとは、atom における atext 文字の連なり、または dot-atom における atext 文字と "." 文字だけです。
3.2.4. 引用文字列
アトムで許される文字以外の文字を含む文字列は、文字が引用符 (DQUOTE、ASCII 値 34) 文字で囲まれる引用文字列形式で表現することができます。
qtext = %d33 / ; Printable US-ASCII
%d35-91 / ; characters not including
%d93-126 / ; "\" or the quote character
obs-qtext
qcontent = qtext / quoted-pair
quoted-string = [CFWS]
DQUOTE *([FWS] qcontent) [FWS] DQUOTE
[CFWS]
引用文字列は 1 つの単位として扱われます。すなわち、引用文字列は意味論的にはアトムと同一です。引用文字列は FWS を含むことが許されているため、折り返しが許されます。また、引用文字列内では quoted-pair が許されているため、引用符とバックスラッシュの文字は、quoted-pair として現れる限り、引用文字列内に現れることができます。
意味論的には、引用符文字の外側の任意の CFWS も、引用符文字自体も、引用文字列の一部ではありません。引用文字列とは、2 つの引用符文字の間に含まれるものです。先に述べたように、任意の quoted-pair における "" と、引用文字列内に現れる任意の FWS/CFWS における CRLF は、意味論的に「不可視」であり、したがって引用文字列の一部でもありません。
3.2.5. その他のトークン
追加の 3 つのトークンが定義されています。すなわち、アトムおよび/または引用文字列の組み合わせのための word と phrase、および非構造化ヘッダーフィールドや構造化ヘッダーフィールド内の一部の箇所で使用するための unstructured です。
word = atom / quoted-string
phrase = 1*word / obs-phrase
unstructured = (*([FWS] VCHAR) *WSP) / obs-unstruct
3.3. 日付と時刻の仕様
日付と時刻の値は、いくつかのヘッダーフィールドに現れます。本節は、完全な日付と時刻の仕様のための構文を規定します。日付時刻の仕様全体を通じて折り返し空白が許されていますが、FWS が現れる各箇所 (必須であれ任意であれ) では単一のスペースを使用することが推奨されます (RECOMMENDED)。一部の古い実装は、より長い折り返し空白の連なりを正しく解釈しないでしょう。
date-time = [ day-of-week "," ] date time [CFWS]
day-of-week = ([FWS] day-name) / obs-day-of-week
day-name = "Mon" / "Tue" / "Wed" / "Thu" /
"Fri" / "Sat" / "Sun"
date = day month year
day = ([FWS] 1*2DIGIT FWS) / obs-day
month = "Jan" / "Feb" / "Mar" / "Apr" /
"May" / "Jun" / "Jul" / "Aug" /
"Sep" / "Oct" / "Nov" / "Dec"
year = (FWS 4*DIGIT FWS) / obs-year
time = time-of-day zone
time-of-day = hour ":" minute [ ":" second ]
hour = 2DIGIT / obs-hour
minute = 2DIGIT / obs-minute
second = 2DIGIT / obs-second
zone = (FWS ( "+" / "-" ) 4DIGIT) / obs-zone
day は月の日を表す数値です。year は 1900 年以降の任意の数値の年です。
time-of-day は、示された日付の真夜中からの時間、分、および任意で秒の数を指定します。
日付と time-of-day は現地時刻を表すべきです (SHOULD)。
zone は、その日付と time-of-day が表す協定世界時 (UTC、以前は "Greenwich Mean Time" と呼ばれていました) からのオフセットを指定します。"+" または "-" は、time-of-day が Universal Time より進んでいる (すなわち、東にある) か、遅れている (すなわち、西にある) かを示します。先頭の 2 桁は Universal Time との時間差を示し、末尾の 2 桁は Universal Time との追加の分の差を示します。(したがって、+hhmm は +(hh * 60 + mm) 分を意味し、-hhmm は -(hh * 60 + mm) 分を意味します。) Universal Time のタイムゾーンを示すには "+0000" という形式を使用すべきです (SHOULD)。"-0000" も Universal Time を示しますが、これは、時刻が Universal Time 以外の現地タイムゾーンにある可能性のあるシステムで生成され、その日付時刻が現地タイムゾーンについての情報を含まないことを示すために使用されます。
日付時刻の仕様は意味論的に妥当でなければなりません (MUST)。すなわち、day-of-week (含まれる場合) はその日付によって示される曜日でなければならず (MUST)、数値の day-of-month は 1 から、指定された月 (指定された年における) に許される日数の間でなければならず (MUST)、time-of-day は 00:00:00 から 23:59:60 までの範囲でなければならず (MUST) (秒数は閏秒を考慮しています。[RFC1305] を参照してください)、zone の末尾の 2 桁は 00 から 59 までの範囲でなければなりません (MUST)。
3.4. アドレス仕様
アドレスは、メッセージの送信者と受信者を示すために、いくつかのメッセージヘッダーフィールドに現れます。アドレスは、単一のメールボックスであるか、メールボックスのグループであるかのいずれかです。
address = mailbox / group
mailbox = name-addr / addr-spec
name-addr = [display-name] angle-addr
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] /
obs-angle-addr
group = display-name ":" [group-list] ";" [CFWS]
display-name = phrase
mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
address-list = (address *("," address)) / obs-addr-list
group-list = mailbox-list / CFWS / obs-group-list
メールボックスはメールを受け取ります。それは、必ずしもファイルの保存に関係するわけではない概念的な実体です。たとえば、一部のサイトでは、メールをプリンターに印刷し、その出力を受取人の机に届けることを選ぶかもしれません。
通常、メールボックスは 2 つの部分から構成されます。(1) 受信者の名前 (人またはシステムであり得ます) を示す任意の表示名で、メールアプリケーションのユーザーに表示することができるものと、(2) 山括弧 ("<" と ">") で囲まれた addr-spec アドレスです。メールボックスには、addr-spec アドレスが受信者の名前も山括弧もなしに単独で現れる、別の単純な形式があります。インターネットの addr-spec アドレスはセクション 3.4.1 で記述されています。
注意: 一部の旧式の実装は、addr-spec が山括弧なしで現れる単純な形式を使用していましたが、addr-spec の後に続くコメントとして、丸括弧内に受信者の名前を含めていました。コメント内の情報の意味は規定されていないため、実装は、メールボックスに関連付けられた表示名を指定するために、旧式の形式ではなくメールボックスの完全な name-addr 形式を使用すべきです (SHOULD)。また、一部の旧式の実装はコメントを解釈するため、そのような実装を混乱させないように、コメントは一般にアドレスフィールドで使用すべきではありません (SHOULD NOT)。
複数のメールボックスを単一の単位として扱うことが望ましい場合 (すなわち、配布リストの場合)、group 構成要素を使用することができます。group 構成要素により、送信者は名前付きの受信者グループを示すことができます。これは、グループの表示名を与え、その後にコロンを続け、その後に任意の数 (0 および 1 を含む) のメールボックスのカンマ区切りリストを続け、セミコロンで終わることによって行われます。メールボックスのリストは空にすることができるため、group 構成要素を使用することは、それらの受信者のいずれについても個々のメールボックスアドレスを実際に提供することなく、メッセージが 1 つ以上の名前付き受信者集合に送信されたことを受信者に伝える簡単な方法でもあります。
3.4.1. addr-spec 仕様
addr-spec は、ローカルで解釈される文字列の後にアットマーク文字 ("@"、ASCII 値 64) が続き、その後にインターネットドメインが続く、特定のインターネット識別子です。ローカルで解釈される文字列は、引用文字列か dot-atom のいずれかです。その文字列を dot-atom として表現できる場合 (すなわち、atext 文字、または atext 文字で囲まれた "." 以外の文字を含まない場合)、dot-atom 形式を使用すべきであり (SHOULD)、引用文字列形式は使用すべきではありません (SHOULD NOT)。addr-spec の "@" の周囲には、コメントと折り返し空白を使用すべきではありません (SHOULD NOT)。
注意: ここでは、addr-spec のドメイン部分について自由な構文が与えられています。しかし、ドメイン部分には、他のプロトコル (たとえば、[RFC1034]、[RFC1035]、[RFC1123]、[RFC5321]) によって規定され、そこで使用されるアドレス指定情報が含まれます。したがって、実装は、アドレスが使用される文脈におけるアドレスの構文に適合する義務があります。
addr-spec = local-part "@" domain
local-part = dot-atom / quoted-string / obs-local-part
domain = dot-atom / domain-literal / obs-domain
domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
dtext = %d33-90 / ; Printable US-ASCII
%d94-126 / ; characters not including
obs-dtext ; "[", "]", or "\"
ドメイン部分は、メールが配送される地点を識別します。dot-atom 形式では、これは [RFC1034]、[RFC1035]、および [RFC1123] で記述されるインターネットドメイン名 (ホスト名またはメール交換機名のいずれか) として解釈されます。domain-literal 形式では、ドメインは特定のホストのリテラルのインターネットアドレスとして解釈されます。どちらの場合も、アドレス指定がどのように使用され、メッセージが特定のホストへどのように伝送されるかは、[RFC5321] のような別個の文書で扱われています。これらの機構は本文書の適用範囲外です。
local-part の部分はドメイン依存の文字列です。アドレスでは、それは単に、特定のホスト上で特定のメールボックスの名前として解釈されます。
3.5. メッセージ全体の構文
メッセージはヘッダーフィールドから構成され、任意でメッセージ本文が続きます。メッセージ内の行は、CRLF を除いて最大 998 文字でなければなりません (MUST) が、行は CRLF を除いて 78 文字に制限することが推奨されます (RECOMMENDED)。(説明についてはセクション 2.1.1 を参照してください。) メッセージ本文では、text 規則に列挙されたすべての文字を使用してもよい (MAY) ものの、US-ASCII 制御文字 (値 1 から 8、11、12、および 14 から 31) の使用は、受信者による表示のための解釈が保証されないため、推奨されません。
message = (fields / obs-fields)
[CRLF body]
body = (*(*998text CRLF) *998text) / obs-body
text = %d1-9 / ; Characters excluding CR
%d11 / ; and LF
%d12 /
%d14-127
ヘッダーフィールドは意味情報の大部分を担っており、セクション 3.6 で定義されます。本文は、本仕様の目的においては解釈されない、単なる一連のテキスト行です。
3.6. フィールド定義
メッセージのヘッダーフィールドはここで定義されます。すべてのヘッダーフィールドは同じ一般的な構文構造を持ちます。すなわち、フィールド名、その後にコロン、その後にフィールド本体です。各ヘッダーフィールドの具体的な構文は、以降の節で定義されます。
注意: 以降の節における各フィールドの ABNF 構文では、各フィールド名の後に必要なコロンが続いています。しかし、簡潔さのために、構文のテキストによる説明ではコロンに言及しないことがあります。それにもかかわらず、コロンは必要です。
ヘッダーフィールドが特定の順序であることは保証されないことに注意することが重要です。それらは任意の順序で現れることがあり、インターネット上を伝送される際にときどき並べ替えられることが知られています。しかし、本仕様の目的においては、メッセージが伝送または変換されるときにヘッダーフィールドを並べ替えるべきではありません (SHOULD NOT)。さらに重要なことに、トレースヘッダーフィールドと再送ヘッダーフィールドは並べ替えてはならず (MUST NOT)、メッセージの先頭に付加されたブロックとして保持されるべきです (SHOULD)。詳細についてはセクション 3.6.6 と 3.6.7 を参照してください。
唯一必須のヘッダーフィールドは、作成日フィールドと発信者アドレスフィールドです。他のすべてのヘッダーフィールドは構文的には任意です。より多くの情報は、この定義に続く表に含まれています。
fields = *(trace
*optional-field /
*(resent-date /
resent-from /
resent-sender /
resent-to /
resent-cc /
resent-bcc /
resent-msg-id))
*(orig-date /
from /
sender /
reply-to /
to /
cc /
bcc /
message-id /
in-reply-to /
references /
subject /
comments /
keywords /
optional-field)
次の表は、各フィールドがメッセージのヘッダーセクションに現れることができる回数の制限と、それらのフィールドの使用に関する特別な制限を示します。最小列または最大列の値の隣のアスタリスク ("*") は、特別な制限が注記列にあることを示します。
+----------------+--------+------------+----------------------------+
| Field | Min | Max number | Notes |
| | number | | |
+----------------+--------+------------+----------------------------+
| trace | 0 | unlimited | Block prepended - see |
| | | | 3.6.7 |
| resent-date | 0* | unlimited* | One per block, required if |
| | | | other resent fields are |
| | | | present - see 3.6.6 |
| resent-from | 0 | unlimited* | One per block - see 3.6.6 |
| resent-sender | 0* | unlimited* | One per block, MUST occur |
| | | | with multi-address |
| | | | resent-from - see 3.6.6 |
| resent-to | 0 | unlimited* | One per block - see 3.6.6 |
| resent-cc | 0 | unlimited* | One per block - see 3.6.6 |
| resent-bcc | 0 | unlimited* | One per block - see 3.6.6 |
| resent-msg-id | 0 | unlimited* | One per block - see 3.6.6 |
| orig-date | 1 | 1 | |
| from | 1 | 1 | See sender and 3.6.2 |
| sender | 0* | 1 | MUST occur with |
| | | | multi-address from - see |
| | | | 3.6.2 |
| reply-to | 0 | 1 | |
| to | 0 | 1 | |
| cc | 0 | 1 | |
| bcc | 0 | 1 | |
| message-id | 0* | 1 | SHOULD be present - see |
| | | | 3.6.4 |
| in-reply-to | 0* | 1 | SHOULD occur in some |
| | | | replies - see 3.6.4 |
| references | 0* | 1 | SHOULD occur in some |
| | | | replies - see 3.6.4 |
| subject | 0 | 1 | |
| comments | 0 | unlimited | |
| keywords | 0 | unlimited | |
| optional-field | 0 | unlimited | |
+----------------+--------+------------+----------------------------+
各フィールドの正確な解釈は、以降の節で記述されます。
3.6.1. 作成日フィールド
作成日フィールドは、フィールド名 "Date" と、それに続く日付時刻の仕様から構成されます。
orig-date = "Date:" date-time CRLF
作成日は、メッセージの作成者がそのメッセージを完成し、メール配送システムに入れる準備ができたと示した日付と時刻を指定します。たとえば、これはアプリケーションプログラムでユーザーが「送信」または「投稿」ボタンを押した時刻であるかもしれません。いずれの場合も、メッセージが実際に伝送される時刻を伝えることは特に意図しておらず、むしろ、人間その他のメッセージの作成者が、メッセージを伝送可能な最終形にした時刻を伝えることを意図しています。(たとえば、ネットワークに接続していない携帯コンピュータのユーザーは、配送のためにメッセージをキューに入れるかもしれません。作成日は、ユーザーがメッセージをキューに入れた日付と時刻を含むことを意図しており、ユーザーがメッセージを送信するためにネットワークに接続した時刻ではありません。)
3.6.2. 発信者フィールド
メッセージの発信者フィールドは、from フィールド、(該当する場合には) sender フィールド、および任意で reply-to フィールドから構成されます。from フィールドは、フィールド名 "From" と、1 つ以上のメールボックス仕様のカンマ区切りリストから構成されます。from フィールドが mailbox-list に複数のメールボックス仕様を含む場合、フィールド名 "Sender" と単一のメールボックス仕様を含む sender フィールドがメッセージに現れなければなりません (MUST)。どちらの場合も、フィールド名 "Reply-To" と 1 つ以上のアドレスのカンマ区切りリストを含む任意の reply-to フィールドも含めることができます (MAY)。
from = "From:" mailbox-list CRLF
sender = "Sender:" mailbox CRLF
reply-to = "Reply-To:" address-list CRLF
発信者フィールドは、メッセージの送信元のメールボックスを示します。"From:" フィールドはメッセージの著者、すなわちメッセージの執筆に責任を持つ人またはシステムのメールボックスを指定します。"Sender:" フィールドは、メッセージの実際の伝送に責任を持つ主体のメールボックスを指定します。たとえば、秘書が他の人のためにメッセージを送信する場合、秘書のメールボックスが "Sender:" フィールドに現れ、実際の著者のメールボックスが "From:" フィールドに現れます。メッセージの発信者が単一のメールボックスで示すことができ、著者と伝送者が同一である場合、"Sender:" フィールドは使用すべきではありません (SHOULD NOT)。そうでなければ、両方のフィールドが現れるべきです (SHOULD)。
注意: 伝送者の情報は常に存在します。"Sender:" フィールドがないことは、メッセージの伝送に責任を持つ主体が指定されていないことを意味すると誤って受け取られることがあります。この不在は、伝送者が著者と同一であり、したがって "Sender:" フィールドに重複して置かれていないことだけを意味します。
発信者フィールドはまた、メッセージに返信する際に必要となる情報も提供します。"Reply-To:" フィールドが存在する場合、それはメッセージの著者が返信を送ることを提案するアドレスを示します。"Reply-To:" フィールドがない場合、返信は、返信を作成する人が別途指定しない限り、既定で "From:" フィールドで指定されたメールボックスに送られるべきです (SHOULD)。
すべての場合において、"From:" フィールドには、メッセージの著者に属さないメールボックスを含めるべきではありません (SHOULD NOT)。返信の宛先アドレスを形成する方法の詳細については、セクション 3.6.3 も参照してください。
3.6.3. 宛先アドレスフィールド
メッセージの宛先フィールドは、可能な 3 つのフィールドから構成され、いずれも同じ形式です。すなわち、"To"、"Cc"、または "Bcc" のいずれかであるフィールド名と、それに続く 1 つ以上のアドレス (メールボックス構文またはグループ構文のいずれか) のカンマ区切りリストです。
to = "To:" address-list CRLF
cc = "Cc:" address-list CRLF
bcc = "Bcc:" [address-list / CFWS] CRLF
宛先フィールドはメッセージの受信者を指定します。各宛先フィールドは 1 つ以上のアドレスを持つことができ、それらのアドレスはメッセージの意図された受信者を示します。3 つのフィールドの唯一の違いは、それぞれがどのように使用されるかです。
"To:" フィールドは、メッセージの主要な受信者のアドレスを含みます。
"Cc:" フィールド (ここで "Cc" は、カーボン紙を使ってタイプライターで複写を取るという意味での "Carbon Copy" を意味します) は、メッセージを受け取ることになる他の人々のアドレスを含みますが、メッセージの内容は彼らに向けられたものではないかもしれません。
"Bcc:" フィールド (ここで "Bcc" は "Blind Carbon Copy" を意味します) は、そのアドレスがメッセージの他の受信者に明かされるべきでないメッセージ受信者のアドレスを含みます。"Bcc:" フィールドの使用方法には 3 通りあります。第 1 の場合では、"Bcc:" フィールドを含むメッセージが送信のために準備されるとき、("Bcc:" フィールドで指定されたものを含む) すべての受信者にメッセージの写しが送られるにもかかわらず、"Bcc:" 行は削除されます。第 2 の場合では、"To:" 行と "Cc:" 行で指定された受信者には、上記のように "Bcc:" 行が削除されたメッセージの写しが送られますが、"Bcc:" 行の受信者には、"Bcc:" 行を含むメッセージの別個の写しが届きます。(「Bcc:」フィールドに複数の受信者アドレスがある場合、一部の実装は実際に、その特定の受信者のアドレスだけを含む "Bcc:" を伴うメッセージの写しを各受信者に別々に送信します。) 最後に、"Bcc:" フィールドはアドレスを含まないことがあるため、"Bcc:" フィールドは、ブラインドコピーが誰かに送られたことを受信者に示すアドレスなしで送信することができます。"Bcc:" フィールドでどの方法を使用するかは実装依存ですが、それぞれの議論については本文書の「セキュリティに関する考慮事項」の節を参照してください。
メッセージが他のメッセージへの返信である場合、元のメッセージの著者のメールボックス ("From:" フィールドのメールボックス) または "Reply-To:" フィールド (存在する場合) で指定されたメールボックスは、通常は返信の主要な受信者となるため、返信の "To:" フィールドに現れることができます (MAY)。宛先フィールドを持つメッセージへの返信を送る場合、著者に加えて、メッセージのすべての受信者に返信の写しを送ることがしばしば望ましいです。そのような返信が形成されるとき、元のメッセージの "To:" および "Cc:" フィールドのアドレスは、通常は返信の二次的な受信者であるため、返信の "Cc:" フィールドに現れることができます (MAY)。元のメッセージに "Bcc:" フィールドが存在する場合、そのフィールドのアドレスは返信の "Bcc:" フィールドに現れることができます (MAY) が、"To:" または "Cc:" フィールドに現れるべきではありません (SHOULD NOT)。
注意: 一部のメールアプリケーションには、元のメッセージの宛先アドレスを返信の宛先アドレスに含める自動返信コマンドがあります。それらの返信コマンドがどのように振る舞うかは実装依存であり、本文書の適用範囲外です。特に、元のメッセージに "Reply-To:" フィールドがあった場合に元の宛先アドレスを含めるかどうかは、ここでは扱いません。
3.6.4. 識別フィールド
セクション 3.6 の表では任意として列挙されていますが、すべてのメッセージは "Message-ID:" フィールドを持つべきです (SHOULD)。さらに、返信メッセージは、以下で記述するように、また適切に応じて "In-Reply-To:" および "References:" フィールドを持つべきです (SHOULD)。
"Message-ID:" フィールドは、単一の一意なメッセージ識別子を含みます。"References:" および "In-Reply-To:" フィールドはそれぞれ、任意で CFWS で区切られた 1 つ以上の一意なメッセージ識別子を含みます。
メッセージ識別子 (msg-id) の構文は、山括弧文字 "<" と ">" で囲まれた、addr-spec 構成要素の制限された版です。addr-spec とは異なり、この構文は "@" の左側に dot-atom-text 形式のみを許し、メッセージ識別子のどこにも内部 CFWS を持ちません。
注意: addr-spec と同様に、msg-id の "@" の右側には自由な構文が与えられています。しかし、本節の後半で、その "@" の右側にドメインを使用することが推奨されます (RECOMMENDED)。繰り返しますが、ドメイン構成要素の構文は、他のプロトコル (たとえば、[RFC1034]、[RFC1035]、[RFC1123]、[RFC5321]) によって規定され、そこで使用されます。したがって、実装は、アドレスが使用される文脈におけるアドレスの構文に適合する義務があります。
message-id = "Message-ID:" msg-id CRLF
in-reply-to = "In-Reply-To:" 1*msg-id CRLF
references = "References:" 1*msg-id CRLF
msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]
id-left = dot-atom-text / obs-id-left
id-right = dot-atom-text / no-fold-literal / obs-id-right
no-fold-literal = "[" *dtext "]"
"Message-ID:" フィールドは、特定のメッセージの特定の版を参照する一意なメッセージ識別子を提供します。メッセージ識別子の一意性は、それを生成するホストによって保証されます (以下を参照してください)。このメッセージ識別子は機械可読であることを意図しており、必ずしも人間にとって意味があるわけではありません。メッセージ識別子は、特定のメッセージのちょうど 1 つの版に関係します。メッセージへのその後の改訂はそれぞれ新しいメッセージ識別子を受け取ります。
注意: メッセージが「変更される」が、それらの変更がそのメッセージの新しい実体化を構成せず、したがってメッセージが新しいメッセージ識別子を取得しない場合が多数あります。たとえば、メッセージが伝送システムに導入されるとき、それらはしばしば、トレースフィールド (セクション 3.6.7 で記述) や再送フィールド (セクション 3.6.6 で記述) のような追加のヘッダーフィールドを先頭に付加されます。そのようなヘッダーフィールドの追加はメッセージの同一性を変えないため、元の "Message-ID:" フィールドが保持されます。すべての場合において、"Message-ID:" フィールドが変わるかどうかを決定するのは、メッセージの送信者が伝えたい意味 (すなわち、これが同じメッセージなのか異なるメッセージなのか) であり、メッセージに現れる (または現れない) 特定の構文上の違いではありません。
"In-Reply-To:" および "References:" フィールドは、メッセージへの返信を作成するときに使用されます。それらは元のメッセージのメッセージ識別子と、他のメッセージのメッセージ識別子を保持します (たとえば、それ自体が返信であったメッセージへの返信の場合)。"In-Reply-To:" フィールドは、新しいメッセージが返信であるところのメッセージを識別するために使用することができ、"References:" フィールドは、会話の「スレッド」を識別するために使用することができます。
メッセージへの返信を作成するとき、結果として得られるメッセージの "In-Reply-To:" および "References:" フィールドは次のように構成されます。
"In-Reply-To:" フィールドは、このメッセージが返信であるところのメッセージ (「親メッセージ」) の "Message-ID:" フィールドの内容を含みます。親メッセージが複数ある場合、"In-Reply-To:" フィールドはすべての親の "Message-ID:" フィールドの内容を含みます。親メッセージのいずれにも "Message-ID:" フィールドがない場合、新しいメッセージは "In-Reply-To:" フィールドを持ちません。
"References:" フィールドは、親の "References:" フィールドの内容 (もしあれば) と、それに続く親の "Message-ID:" フィールドの内容 (もしあれば) を含みます。親メッセージが "References:" フィールドを含まないが、単一のメッセージ識別子を含む "In-Reply-To:" フィールドを持つ場合、"References:" フィールドは、親の "In-Reply-To:" フィールドの内容と、それに続く親の "Message-ID:" フィールドの内容 (もしあれば) を含みます。親が "References:"、"In-Reply-To:"、"Message-ID:" のいずれのフィールドも持たない場合、新しいメッセージは "References:" フィールドを持ちません。
注意: 一部の実装は、"References:" フィールドを解析して「議論のスレッド」を表示します。これらの実装は、新しい各メッセージが単一の親への返信であると仮定し、したがって "References:" フィールドを後ろ向きにたどって、そこに列挙された各メッセージの親を見つけることができると考えます。したがって、複数の親を持つ返信のために "References:" フィールドを形成しようとすることは推奨されません。その方法は本文書では定義されていません。
メッセージ識別子 (msg-id) 自体は、メッセージのグローバルに一意な識別子でなければなりません (MUST)。メッセージ識別子の生成者は、msg-id が一意であることを保証しなければなりません (MUST)。これを達成するために使用できるアルゴリズムはいくつかあります。msg-id は addr-spec と同様の構文を持つ (引用文字列、コメント、および折り返し空白が許されないことを除いて同一である) ため、よい方法は、メッセージ識別子が作成されたホストのドメイン名 (またはドメインリテラルの IP アドレス) を "@" の右側に置き (ドメイン名と IP アドレスは通常一意であるため)、現在の絶対的な日付と時刻の組み合わせを、システム上で利用可能な他の現在一意な (おそらく連番の) 識別子 (たとえば、プロセス ID 番号) とともに左側に置くことです。他のアルゴリズムも機能しますが、右側がある種のドメイン識別子 (ホスト自身のものであれそうでなかれ) を含み、メッセージ識別子の生成者がそのドメインの範囲内で左側の一意性を保証できるようにすることが推奨されます (RECOMMENDED)。
意味論的には、山括弧文字は msg-id の一部ではありません。msg-id とは、2 つの山括弧文字の間に含まれるものです。
3.6.5. 情報フィールド
情報フィールドはすべて任意です。"Subject:" および "Comments:" フィールドは、セクション 2.2.1 で定義される非構造化フィールドであり、したがってテキストや折り返し空白を含むことができます。"Keywords:" フィールドは、1 つ以上の語または引用文字列のカンマ区切りリストを含みます。
subject = "Subject:" unstructured CRLF
comments = "Comments:" unstructured CRLF
keywords = "Keywords:" phrase *("," phrase) CRLF
これらの 3 つのフィールドは、メッセージに関する情報を持つ、人間が読める内容のみを持つことを意図しています。"Subject:" フィールドは最も一般的であり、メッセージの話題を識別する短い文字列を含みます。返信で使用される場合、フィールド本体は文字列 "Re: " (ラテン語の "in re" の略で、「〜のことについて」を意味します) で始まり、その後に元のメッセージの "Subject:" フィールド本体の内容が続くことがあります (MAY)。これを行う場合、リテラル文字列 "Re: " の出現は 1 つだけにすべきです (SHOULD)。他の文字列を使用したり、1 つより多く出現させたりすると、望ましくない結果につながる可能性があるためです。"Comments:" フィールドは、メッセージの本文のテキストに関する追加のコメントを含みます。"Keywords:" フィールドは、受信者にとって有用であるかもしれない重要な語や句のカンマ区切りリストを含みます。
3.6.6. 再送フィールド
再送フィールドは、ユーザーによって伝送システムに再導入されたメッセージに追加すべきです (SHOULD)。これが行われるたびに、別個の再送フィールドの組を追加すべきです (SHOULD)。メッセージの特定の再送に対応する再送フィールドのすべては、まとめてグループ化すべきです (SHOULD)。再送フィールドの新しい組はそれぞれメッセージの先頭に付加されます。すなわち、再送フィールドの最も新しい組がメッセージのより先頭に現れます。再送フィールドが追加されるとき、メッセージ内の他のフィールドは変更されません。
各再送フィールドは、構文の他の場所にある特定のフィールドに対応します。たとえば、"Resent-Date:" フィールドは "Date:" フィールドに対応し、"Resent-To:" フィールドは "To:" フィールドに対応します。いずれの場合も、フィールド本体の構文は、対応するフィールドについて先に与えられた構文と同一です。
再送フィールドが使用されるとき、"Resent-From:" および "Resent-Date:" フィールドを送らなければなりません (MUST)。"Resent-Message-ID:" フィールドを送るべきです (SHOULD)。"Resent-Sender:" が "Resent-From:" と同一になる場合、"Resent-Sender:" は使用すべきではありません (SHOULD NOT)。
resent-date = "Resent-Date:" date-time CRLF
resent-from = "Resent-From:" mailbox-list CRLF
resent-sender = "Resent-Sender:" mailbox CRLF
resent-to = "Resent-To:" address-list CRLF
resent-cc = "Resent-Cc:" address-list CRLF
resent-bcc = "Resent-Bcc:" [address-list / CFWS] CRLF
resent-msg-id = "Resent-Message-ID:" msg-id CRLF
再送フィールドは、メッセージがユーザーによって伝送システムに再導入されたことを識別するために使用されます。再送フィールドを使用する目的は、メッセージが、元のすべてのフィールドが同じままの状態で、あたかも元の送信者によって直接送られたかのように最終受信者に見えるようにすることです。再送フィールドの各組は、特定の再送イベントに対応します。すなわち、メッセージが複数回再送される場合、再送フィールドの各組は個々の時点についての識別情報を与えます。再送フィールドは厳密に情報提供用です。それらは、返信またはメッセージに対するそのような自動操作の通常の処理で使用してはなりません (MUST NOT)。
注意: メッセージを伝送システムに再導入して再送フィールドを使用することは、「転送 (forwarding)」とは異なる操作です。「転送」には 2 つの意味があります。転送の一方の意味は、メール閲覧プログラムがユーザーによって、メッセージの写しを他の人に転送するように指示され得ることであり、転送されたメッセージを新しいメッセージの本文にします。この意味での転送されたメッセージは、元の送信者から来たようには見えず、メッセージの転送者からのまったく新しいメッセージです。転送はまた、メール伝送プログラムがメッセージを受け取り、それを最終配送のために別の宛先へ転送することを意味することもあります。再送ヘッダーフィールドは、いずれの種類の転送にも使用することを意図していません。
再送の発信者フィールドは、メッセージを再送した人またはシステムのメールボックスを示します。通常の発信者フィールドと同様に、2 つの形式があります。再送を行っている個人のメールボックスを含む単純な "Resent-From:" 形式と、1 人の個人 ("Resent-Sender:" フィールドで識別されます) が 1 人以上の他の人 ("Resent-From:" フィールドで識別されます) のためにメッセージを再送する、より複雑な形式です。
注意: 再送されたメッセージに返信するとき、返信は他のどのメッセージに対する場合とまったく同じように振る舞い、元の "From:"、"Reply-To:"、"Message-ID:"、およびその他のフィールドを使用します。再送フィールドは情報提供用にすぎず、返信の通常の処理で使用してはなりません (MUST NOT)。
"Resent-Date:" は、再送メッセージがメッセージの再送者によって発送された日付と時刻を示します。"Date:" フィールドと同様に、それはメッセージが実際に伝送された日付と時刻ではありません。
"Resent-To:"、"Resent-Cc:"、および "Resent-Bcc:" フィールドは、それぞれ "To:"、"Cc:"、および "Bcc:" フィールドと同一に機能しますが、元のメッセージの受信者ではなく、再送メッセージの受信者を示す点が異なります。
"Resent-Message-ID:" フィールドは、再送メッセージの一意な識別子を提供します。
3.6.7. トレースフィールド
トレースフィールドは、任意の "Return-Path:" フィールドと 1 つ以上の "Received:" フィールドから構成されるヘッダーフィールドのグループです。"Return-Path:" ヘッダーフィールドは、任意の addr-spec を囲む 1 対の山括弧を含みます。"Received:" フィールドは、(空である可能性のある) トークンのリストと、それに続くセミコロンおよび日付時刻の仕様を含みます。各トークンは、word、angle-addr、addr-spec、または domain でなければなりません。トレースフィールドの構文には、[RFC5321] のようにその使用を規定する仕様によって、さらなる制限が適用されます。
trace = [return]
1*received
return = "Return-Path:" path CRLF
path = angle-addr / ([CFWS] "<" [CFWS] ">" [CFWS])
received = "Received:" *received-token ";" date-time CRLF
received-token = word / angle-addr / addr-spec / domain
トレースフィールドのインターネットメールでの使用についての完全な議論は [RFC5321] に含まれています。本仕様の目的においては、トレースフィールドは厳密に情報提供用であり、それらの形式的な解釈は本文書の適用範囲外です。
3.6.8. 任意フィールド
フィールドは、本文書で他に規定されていないメッセージに現れることがあります。それらは optional-field の構文に適合しなければなりません (MUST)。これは、SP とコロンを除く印刷可能な US-ASCII 文字からなるフィールド名と、それに続くコロン、それに続く非構造化構文に適合する任意のテキストです。
任意フィールドのフィールド名は、本文書の他のどこかで規定されたいずれのフィールド名とも同一であってはなりません (MUST NOT)。
optional-field = field-name ":" unstructured CRLF
field-name = 1*ftext
ftext = %d33-57 / ; Printable US-ASCII
%d59-126 ; characters not including
; ":".
本仕様の目的においては、任意フィールドは解釈されません。