メッセージID

Message-ID: ヘッダー (電子メール)

[9] Message-ID: 頭欄は、 RFC 822 およびその派生仕様において、 当該メッセージの固有識別子を記述する頭欄です。また、 その固有識別子をメッセージ (message) IDと呼び、たまに mid と略されます。

仕様書

構文

Message-ID と Content-ID の角括弧は ID の一部かどうか

[22] 仕様書によって、一部であると言っていたり、ないと言ってたりします。 RFC 2822 はないという見解のようです。

mid:, cid: URL は、角括弧を省いたものを URI の一部として 利用しています。このように外部の構造の部分として使う場合は、 角括弧を取り除いて使うのが良さげです。角括弧は冗長です。

(とはいえ、場合によってはそういう時でも、角括弧つきのものを うけいれるのが良いでしょう。人に優しく原則です。)

壊れた識別子

Message-ID, Content-ID が例にでてくる RFC のなかに、 間違って角括弧が必要なのに書いてないのが幾つかあります。 例えば、 RFC 1341 [MIME] で Message-ID が角括弧なし の例が幾つも載ってたりします。

実際のメッセージで角括弧が無い MID/CID がどれだけあるのか 分かりませんが、実装は出来れば対応するべきでしょう。 (といっても References: や In-Reply-To: でそれをやられると、 構文解析が少し面倒になるなあ。)

どこだったかの携帯電話から送られてくる電子メイルは、 <hogehoge@foo.example のように、角括弧が片方しかない MID が使われてました。しかもかなり長い時期続いてました。 (現在どうなってるかは分かりません。) ですから、実装は こうしたものも受け入れるべきでしょう。

もちろんどちらの場合も、角括弧を適当に補ったものを MID/CID とすることになるでしょう。 References/In-Reply-To にその MID を入れるときは、補ったものを入れるべきです。 (または、入れないか。そのどちらかでないと、 RFC 822/2822 などに違反します。)

%

[23] メッセージ識別子では % を用いることが認められています。 実際生成時の区切子としてよく使われています。

[24] インターネットメールで完結している限りはそれで良かったのですが、 mid: URLメーリングリストアーカイブWebページURL などでメッセージIDURL の一部に使われるとき、 問題となることがあります。 %URL ではパーセント符号化して %25 と書かなければなりません。しかし迂闊なソフトウェアはこれを実装するのを忘れているため、 % が含まれるメールを正しく扱えなかったりします。

[26] 実例こそ確認されていませんが、 Webメールでもそのような不具合がある可能性があります。

[25] 従って、相互運用性のため、メッセージ識別子には % を含めるべきではありません。

要注意文字

[27] 他にメッセージIDでよく使われるものの URL での扱いに注意が必要な文字として、 =+ があります。

BNF

 Message-ID = "Message-ID:" CFWS msg-id [CFWS] / obs-Message-ID
 Content-ID = "Content-ID" [FWS] ":" [CFWS] 822.msg-id [CFWS]
 References = "References:" CFWS msg-id-list [CFWS] / obs-References
 In-Reply-To = "In-Reply-To:" CFWS msg-id-list [CFWS] / obs-In-Reply-To
 
 822.msg-id = msg-id / obs-msg-id
 msg-id = "<" id-left "@" id-right ">"
 id-left = dot-atom / no-fold-quote
 id-right = dot-atom / no-fold-literal
 msg-id-list = msg-id *( CFWS msg-id ) / obs-msg-id-list
 obs-Message-ID = "Message-ID" [FWS] ":" [CFWS] obs-msg-id-content [CFWS]
 obs-msg-id-content = mach-host-phrase	;; RFC 724
                    / mach-id	;; RFC 733
                    / obs-msg-id	;; RFC 2822 obsolete
 obs-References = "References" [FWS] ":" msg-id-list [CFWS] 
 obs-References = "In-Reply-To" [FWS] ":" msg-id-list [CFWS] 
 obs-msg-id-list = [ 724.reference-item-list	;; RFC 724
                   / 733.ref-item-list	;; RFC 733
                   / *(obs-phrase / msg-id )	;; RFC [2]822
                   ]
 mach-host-phrase = "<" [724.CFWS] host-phrase [724.CFWS] ">"
 host-phrase = 724.phrase [724.CFWS] host-indicator
 host-indicator = at-indicator [724.CFWS] host-name
 at-indicator = 724.CFWS "at" 724.CFWS / "@"
 host-name = 724.atom / ipv4-address
 724.phrase = 724.word *( [724.CFWS] 724.word )
 724.word = 724.atom / 724.quoted-string
 724.atom = 1*724.atext
 724.atext = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'"
           / "*" / "+" / "-" / "." / "/" / "=" / "?" / "[" 
           / "\" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~"
 724.quoted-string = <"> ( (%x00-07 / %x09-%7F) *(%x00-7F) / <""> ) <">
 	;; <""> は <"> と解される。単一の <"> を除くと書いてない
 	;; けど、常識的には駄目なのでしょう。
 724.CFWS = *([FWS] 724.comment) (([FWS] 724.comment) / FWS)
 724.comment = "(" ( (%x00-27 / %x29-7F) / 724.comment ) ")"
 	;; CRLF が入っちゃ駄目。
 mach-id = "<" [CFWS] host-phrase [CFWS] ">"
 733.host-phrase = 733.phrase [CFWS] 733.host-indicator
 733.host-indicator =  1*( ( CFWS "at" CFWS / "@" ) [CFWS] node )
 node = word / 1*DIGIT
 733.atom = 1*733.atext
 733.atext = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'"
           / "*" / "+" / "-" / "." / "/" / "=" / "?" / "[" 
           / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~"
 obs-msg-id = "<" [CFWS] 822.addr-spec [CFWS] ">"
 822.addr-spec = 822.local-part [CFWS] "@" [CFWS] 822.domain
 822.local-part = obs-dot-word
 822.domain = obs-dot-atom / domain-literal
 724.reference-item-list = 724.reference-item
             *( [724.CFWS] "," [724.CFWS] 724.reference-item )
 724.reference-item = 724.phrase / mach-host-phrase
 733.ref-item-list = ( 733.phrase / mach-id )
             *( [733.CFWS] "," [733.CFWS] ( 733.phrase / mach-id ) )

インターネットメール以外

[29] Mozilla Thunderbirdフィードリーダー機能のメッセージでは

Message-Id: http://host.example/path/to/entry.html@localhost.localdomain

のようなメッセージIDが生成されます。 左側は素片識別子が付き得る絶対URLっぽいです。

MSA との関係

[6] MSA は、メッセージMessage-ID: に含まれない場合や RFC 2822 に照らして妥当構文ではない場合、 Message-ID: を追加または置換して構いませんRFC 4409 8.3

各仕様における定義

typo スマソ

Message-ID の生成

Message-ID を定義する各仕様にそれぞれいかに固有の識別子を生成するか についての説明があります。

次の Internet-Draft は各方法を紹介したり推奨される方法を 定義したりしています。

主題変更を示す「_-_」記法

son-of-RFC1036 6.5. References 抜粋

The followup agent MUST not delete any message ID whose local part ends with "_-_" (underscore (ASCII 95), hyphen (ASCII 45), underscore); followup agents are urged to use this form to mark subject changes, and to avoid using it otherwise.

返信代理者は地域部分が「_-_」 (下線 (ASCII 95), ハイフン (ASCII 45), 下線) で終わるメッセイジ ID を削除してはいけません。 返信代理者はこの形式を主題 subject が変更された印として使い、 他の用途で使うのを避けることを推奨します。

NOTE: Subject changes are difficult to determine, but they are significant as possible beginnings of new threads. The "_-_" convention is provided so that posting agents (which have more information about subjects) can flag articles containing a subject change in a way that followup agents can detect without access to the articles themselves. The sequence is chosen as one that is fairly unlikely to occur by accident.

参考: 主題変更は決定が難しいですが、新スレッドの始まりの可能性がある 重要なものです。「_-_」慣習があるので (主題についてより情報を持っている) 投稿代理者は返信代理者が記事自身に接続無しに主題が変更されたことが 分かるように記事に印をつけることが出来ます。

NOTE: Is "_-_" really worth having?

参考: 「_-_」は本当に意味があるのでしょうか?

関門での Message-ID 書き換え

違プロトコル間でのメッセージ交換はそう稀なことでもありませんが、 各プロトコル間で Message-ID またはそれに相当するものの 書式が一致していることは稀なことでしょう:-) そのような場合に、 Message-ID を書き換える必要が出てきます。

もっとも身近なところでは、電子メイルと電子ニュースで メッセージ交換する場合、電子メイルの方が Message-ID の自由度が 高いので、電子メイル→電子ニュース関門では Message-ID を 書き換えなければならないかもしれません。

MMS との変換

[10] MMS からインターネット・メールへの変換時には、 Message-ID: 頭欄はそのまま残さなければなりません。元々存在しなかった場合には RFC 2822 にのっとり生成しなければなりません>>8

文脈

[28] RFC 2801 - Internet Open Trading Protocol - IOTP Version 1.0, , https://tools.ietf.org/html/rfc2801#section-3.3.1

関連

[20]

[11] MMS には Message-ID: の他に X-Mms-Message-Id: もあります。

歴史

HTTP

[1] [HTTP92] では、値は URI でした。この URI は資源を取り寄せるために使うものではなく、ニュースのメッセージ ID のように意味の無い文字列でした。 (HTTP だから WWW っぽく、メイル・アドレスではなく URI を構文に選んだのでしょう。)

[2] >>1 結局無くなったわけですが、案外 ETag: 欄あたりに引き継がれたのかもしれません。

[14] RFC 4229HTTP92 を出典に状態「provisional」でIANA登録簿に登録しています >>13

メモ

[1] 2003-01-25 16:04 名無しさん: qmail の error message mail の Message-ID は元メッセージの Message-ID と同じことがあるそうです。困ったもんです。

[21] "@" を含まない Content-ID を良く見かけます。ほぼ間違いなくそれは HTMLメイルでした。 MUA などは "@" がない CID も受け入れてあげるのが親切ですが、 (大抵はうざいだけの HTMLメイルに使われているので) あえて対応することもないかもしれません:-) (text/html媒体型を上手く利用する人 (が使う UA) は変な CID を生成しないでしょう、ってことで。)

[3] %x0D の入った Message-ID なんて実際にあるのか... (名無しさん 2004-04-20 08:48:20 +00:00)

[12] RFC 4975 - The Message Session Relay Protocol (MSRP) ( ( 版)) http://tools.ietf.org/html/rfc4975#page-37

[15] draft-goland-http-reliability-00 - SOA-Reliability (SOA-Rity) for HTTP ( ( 版)) https://tools.ietf.org/html/draft-goland-http-reliability-00#section-3

[16] RFC 4130 - MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2) ( ( 版)) http://tools.ietf.org/html/rfc4130#appendix-A.1

[17] RFC 5536 - Netnews Article Format ( ( 版)) http://tools.ietf.org/html/rfc5536#section-1.5

[18] RFC 5536 - Netnews Article Format ( ( 版)) http://tools.ietf.org/html/rfc5536#section-3.1.3

[19] RFC 2392 - Content-ID and Message-ID Uniform Resource Locators ( ( 版)) https://tools.ietf.org/html/rfc2392