/
286.txt
294 lines (218 loc) · 13.5 KB
/
286.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
[9] [CODE(822)@en[[[Message-ID:]]]] [[頭欄]]は、 [[RFC 822]] およびその派生仕様において、
当該[[メッセージ]]の固有識別子を記述する[[頭欄]]です。また、
その固有識別子を[DFN[[RUBYB[メッセージ]@en[message]] ID]]と呼び、たまに [DFN[mid]] と略されます。
* 仕様書
- [5] [[RFC 4409]] ([[IETF]] [[提案標準]])
<urn:ietf:rfc:4409>
-- [CSECTION@en[8.3. Add 'Message-ID']]
- [8] [CITE@en[RFC 4356 - Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail]]
<http://tools.ietf.org/html/rfc4356#page-9>
- [7] [CITE@en[RFC 5598 - Internet Mail Architecture]]
<http://tools.ietf.org/html/rfc5598#section-3.4.1>
* 構文
**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
などに違反します。)
** [CODE[%]]
[23] [[メッセージ識別子]]では [CODE[%]] を用いることが認められています。
実際生成時の区切子としてよく使われています。
[24] [[インターネットメール]]で完結している限りはそれで良かったのですが、
[CODE[mid:]] [[URL]] や[[メーリングリスト]]の[[アーカイブ]]の [[Webページ]]の
[[URL]] などで[[メッセージID]]が [[URL]] の一部に使われるとき、
問題となることがあります。 [CODE[%]] は [[URL]] では[[パーセント符号化]]して
[CODE[%25]] と書かなければなりません。しかし迂闊な[[ソフトウェア]]はこれを実装するのを忘れているため、
[CODE[%]] が含まれる[[メール]]を正しく扱えなかったりします。
;; [26] 実例こそ確認されていませんが、 [[Webメール]]でもそのような不具合がある可能性があります。
[25] 従って、[[相互運用性]]のため、[[メッセージ識別子]]には [CODE[%]]
を含めるべきではありません。
**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 ) )
* MSA との関係
[6] [[MSA]] は、[[メッセージ]]に
[CODE(822)@en[[[Message-ID]]:]] [[欄]]に含まれない場合や
[[RFC 2822]] に照らして[[妥当]]な[[構文]]ではない場合、
[CODE(822)@en[[[Message-ID]]:]] [[欄]]を追加または置換[['''して構いません''']]。
[SRC@en[[[RFC 4409]] 8.3]]
* 各仕様における定義
- [[電子メイル記事仕様におけるMessage-IDの定義]]
- [[電子ニュース記事仕様におけるMessage-IDの定義]]
-- [[電子ニュース記事使用におけるMessage-IDの定義]]
typo スマソ
[FIG(short list)[
- [CODE(MIME)@en[[[message/partial]]]] [CODE(MIME)@en[[[id]]]] [[引数]]
]FIG]
* Message-ID の生成
Message-ID を定義する各仕様にそれぞれいかに固有の識別子を生成するか
についての説明があります。
次の Internet-Draft は各方法を紹介したり推奨される方法を
定義したりしています。
- [[draft-ietf-usefor-message-id-01]]
- [[draft-ietf-usefor-msg-id-alt-00]]
** 主題変更を示す「_-_」記法
** son-of-RFC1036 6.5. References 抜粋
[FIG(quote)[
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?
参考: 「_-_」は本当に意味があるのでしょうか?
]FIG]
* 関門での Message-ID 書き換え
- [[son-of-RFC1036の関門でのMessage-ID対応]]
違プロトコル間でのメッセージ交換はそう稀なことでもありませんが、
各プロトコル間で Message-ID またはそれに相当するものの
書式が一致していることは稀なことでしょう:-) そのような場合に、
Message-ID を書き換える必要が出てきます。
もっとも身近なところでは、電子メイルと電子ニュースで
メッセージ交換する場合、電子メイルの方が Message-ID の自由度が
高いので、電子メイル→電子ニュース関門では Message-ID を
書き換えなければならないかもしれません。
** MMS との変換
[10] [[MMS]] から[[インターネット・メール]]への変換時には、 [CODE(822)@en[[[Message-ID:]]]]
[[頭欄]]はそのまま残さなければ[['''なりません''']]。元々存在しなかった場合には [[RFC 2822]]
にのっとり生成しなければ[['''なりません''']]。 [SRC[>>8]]
* 関連
[20]
-識別子の定義
--[[Message-ID:領域]]
--[[Content-ID:領域]]
--See also [[Received:領域]]
-識別子の参照 (See also [[記事の返信]])
--[[References:領域]]
--[[In-Reply-To:領域]]
--[[See-Also:領域]]
--[[Supersedes:領域]]
--[[Control:領域]] (See also [[Subject:領域]])
-[[Article-I.D.:領域]]
-[[X-UIDL:領域]]
-[[XRef:領域]]
[11] [[MMS]] には [CODE(822)@en[[[Message-ID:]]]] の他に [CODE(822)@en[[[X-Mms-Message-Id:]]]]
もあります。
* 歴史
** HTTP
[1] [HTTP92] では、値は [[URI]] でした。この URI は資源を取り寄せるために使うものではなく、ニュースのメッセージ ID のように意味の無い文字列でした。 (HTTP だから WWW っぽく、メイル・アドレスではなく URI を構文に選んだのでしょう。)
[2] >>1 結局無くなったわけですが、案外 [[ETag:]] 欄あたりに引き継がれたのかもしれません。
[14] [[RFC 4229]] は [[HTTP92]] を出典に状態「[[provisional]]」で[[IANA登録簿]]に登録しています
[SRC[>>13]]。
[REFS[
- [4] [CITE[Object Header lines in HTTP]] ([TIME[2002-04-11 00:31:17 +09:00]] 版) <http://www.w3.org/Protocols/HTTP/Object_Headers.html#message-id>
- [13] [CITE@en[RFC 4229 - HTTP Header Field Registrations]] ([TIME[2014-11-02 18:53:20 +09:00]] 版) <http://tools.ietf.org/html/rfc4229#section-2.2.4>
]REFS]
** メモ
[1] [WEAK[2003-01-25 16:04]] ''[[名無しさん]]'': [[qmail]] の error message mail の [[Message-ID]] は元メッセージの Message-ID と同じことがあるそうです。困ったもんです。
[21] [CODE(ABNF)["@"]] を含まない Content-ID を良く見かけます。ほぼ間違いなくそれは [[HTMLメイル]]でした。 [[MUA]] などは [CODE(ABNF)["@"]] がない [ABBR[CID] [Content-ID]] も受け入れてあげるのが親切ですが、 (大抵はうざいだけの [[HTMLメイル]]に使われているので) あえて対応することもないかもしれません:-) ([[text/html媒体型]]を上手く利用する人 (が使う [[UA]]) は変な CID を生成しないでしょう、ってことで。)
[3]
[CODE(ABNF)[%x0D]] の入った Message-ID なんて実際にあるのか...
([[名無しさん]] [WEAK[2004-04-20 08:48:20 +00:00]])
[12] [CITE@en[RFC 4975 - The Message Session Relay Protocol (MSRP)]]
( ([TIME[2012-02-26 13:20:50 +09:00]] 版))
<http://tools.ietf.org/html/rfc4975#page-37>
[15] [CITE@en[draft-goland-http-reliability-00 - SOA-Reliability (SOA-Rity) for HTTP]]
( ([TIME[2014-11-18 19:43:49 +09:00]] 版))
<https://tools.ietf.org/html/draft-goland-http-reliability-00#section-3>
[16] [CITE@en[RFC 4130 - MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)]]
( ([TIME[2014-09-21 21:13:43 +09:00]] 版))
<http://tools.ietf.org/html/rfc4130#appendix-A.1>
[17] [CITE@en[RFC 5536 - Netnews Article Format]]
( ([TIME[2014-09-21 18:14:06 +09:00]] 版))
<http://tools.ietf.org/html/rfc5536#section-1.5>
[18] [CITE@en[RFC 5536 - Netnews Article Format]]
( ([TIME[2014-09-21 18:14:06 +09:00]] 版))
<http://tools.ietf.org/html/rfc5536#section-3.1.3>
[19] [CITE@en[RFC 2392 - Content-ID and Message-ID Uniform Resource Locators]]
( ([TIME[2014-12-22 15:20:11 +09:00]] 版))
<https://tools.ietf.org/html/rfc2392>