この文書はRFC 2822 の "3.6.4. Identification fields" を邦訳したものです。ほとんど即席で訳したものなので誤訳が含まれている可能性があります。厳密に理解したい方は原文をお読み下さい。誤訳の指摘を歓迎します。見つけたらメールを下さい。なお、この訳には次のコピーライトが適応されます。
Copyright (C) The Internet Society (2000). All Rights Reserved.
任意ではあるが、各メッセージは "Message-ID:" フィールドを持つべき(SHOULD)である。さらに、返信メッセージは以降に記述するように適切な "In-Reply-To:" と "References:" のフィールドを持つべき(SHOULD)である。
"Message-ID:" フィールドには唯一無二のメッセージ識別子が含まれる。"References:" フィールドと "In-Reply-To:" フィールドには一つ以上の唯一無二のメッセージ識別子がそれぞれ含まれる。複数のメッセージ識別子は CFWS によって任意に切り離される（訳注：CFWS とは comment and/or folding white space のこと。つまり、コメントや空白文字や改行などによってメッセージ識別子は区切られるということ）
メッセージ識別子 (msg-id) はアングルブラケット文字 "<" と ">"に囲まれる addr-spec の構成に似ている。しかし、その内部に CFWS は含まない。
message-id = "Message-ID:" msg-id CRLF in-reply-to = "In-Reply-To:" 1*msg-id CRLF references = "References:" 1*msg-id CRLF msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] id-left = dot-atom-text / no-fold-quote / obs-id-left id-right = dot-atom-text / no-fold-literal / obs-id-right no-fold-quote = DQUOTE *(qtext / quoted-pair) DQUOTE no-fold-literal = "[" *(dtext / quoted-pair) "]"
"Message-ID:" フィールドは特定のメッセージの特定の版を参照する唯一無二のメッセージ識別子を提供する。メッセージ識別子が唯一無二であることはそれを生成するホストによって保証される（以降を参照）。このメッセージ識別子はマシンが読めることを意図していて、必ずしも人間にとって意味がある必要はない。メッセージ識別子は特定のメッセージの正確に一つの instantiation に関係する。続いて起こるメッセージの改訂はそれぞれ新しいメッセージ識別子を受け取る。(訳者疑問：instantiation ってどういう意味？)
注釈：メッセージが変えられたとき多くのinstances がある。しかし、その改変はメッセージの新しいinstantiation を構成しない。そのため、メッセージは新しいメッセージ識別子を得ないだろう。例えば、メッセージが配送システムに渡される場合、trace フィールド（セクション3.6.7に記述）や resent フィールド（セクション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 に文法が似ている（ comments や folding white space が許容されない点を除いて同じである）ので、メッセージ識別子の "@" の右側に生成されるホストのドメイン名やドメインリテラル IP アドレスを置き、左側に現在の日時とシステムに適応される他の唯一な（たぶん連続的な）識別子（例えば、プロセス ID 番号）との組合わせを置くのは良い方法である。左側に日時を右側にドメイン名やドメインリテラルを使うのは二つのホストが同じドメイン名や IP アドレスを同時に使わないので、唯一であることを保証することを可能にする。他のアルゴリズムを使われるのであれば、メッセージ識別子の生成者がそのドメインの範囲内で左側の唯一さを保証できるような（ホスト自身や他の）ドメイン識別子を右側に含むことを推奨します(RECOMMENDED)。
意味的には、アングルブラケット文字は msg-id の部分を構成しない。msg-id は二つのアングルブラケット文字の間に含まれるものである。