1
2
3
4
5
6
7Network Working Group R. Chandhok
8Request for Comments: 2919 G. Wenger
9Category: Standards Track QUALCOMM, Inc.
10 March 2001
11
12
13 List-Id:
14 A Structured Field and Namespace for the
15 Identification of Mailing Lists
16
17Status of this Memo
18
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
24
25Copyright Notice
26
27 Copyright (C) The Internet Society (2001). All Rights Reserved.
28
29Abstract
30
31 Software that handles electronic mailing list messages (servers and
32 user agents) needs a way to reliably identify messages that belong to
33 a particular mailing list. With the advent of list management
34 headers, it has become even more important to provide a unique
35 identifier for a mailing list regardless of the particular host that
36 serves as the list processor at any given time.
37
38 The List-Id header provides a standard location for such an
39 identifier. In addition, a namespace for list identifiers based on
40 fully qualified domain names is described. This namespace is
41 intended to guarantee uniqueness for list owners who require it,
42 while allowing for a less rigorous namespace for experimental and
43 personal use.
44
45 By including the List-Id field, list servers can make it easier for
46 mail clients to provide automated tools for users to perform list
47 functions. The list identifier can serve as a key to make many
48 automated processing tasks easier, and hence more widely available.
49
501. Introduction
51
52 Internet mailing lists have evolved into fairly sophisticated forums
53 for group communication and collaboration; however, corresponding
54 changes in the underlying infrastructure have lagged behind. Recent
55
56
57
58Chandhok & Wenger Standards Track [Page 1]
59
60RFC 2919 List-Id March 2001
61
62
63 proposals like [RFC2369] have expanded the functionality that the MUA
64 can provide by providing more information in each message sent by the
65 mailing list distribution software.
66
67 Actually implementing such functionality in the MUA depends on the
68 ability to accurately identify messages as belonging to a particular
69 mailing list. The problem then becomes what attribute or property to
70 use to identify a mailing list. The most likely candidate is the
71 submission address of the mailing list itself. Unfortunately, when
72 the list server host, the list processing software, or the submission
73 policy of the list changes the submission address itself can change.
74 This causes great difficulty for automated processing and filtering.
75
76 In order to further automate (and make more accurate) the processing
77 a software agent can do, there needs to be some unique identifier to
78 use as an identifier for the mailing list. This identifier can be
79 simply used for string matching in a filter, or it can be used in
80 more sophisticated systems to uniquely identify messages as belonging
81 to a particular mailing list independent of the particular host
82 delivering the actual messages. This identifier can also act as a
83 key into a database of mailing lists.
84
85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
87 document are to be interpreted as described in RFC 2119.
88
892. The List Identifier Syntax
90
91 The list identifier will, in most cases, appear like a host name in a
92 domain of the list owner. In other words, the domain name system is
93 used to delegate namespace authority for list identifiers just as it
94 has been used to distribute that authority for other internet
95 resources.
96
97 Using the domain name system as a basis for the list identifier
98 namespace is intended to leverage an existing authority structure
99 into a new area of application. By using the domain name system to
100 delegate list identifier namespace authority, it becomes instantly
101 clear who has the right to create a particular list identifier, and
102 separates the list identifier from any particular delivery host or
103 mechanism. Only the rights-holder of a domain or subdomain has the
104 authority to create list identifiers in the namespace of that domain.
105 For example, only the rights-holder to the "acm.org" domain has the
106 authority to create list identifiers in "acm.org" domain.
107
108
109
110
111
112
113
114Chandhok & Wenger Standards Track [Page 2]
115
116RFC 2919 List-Id March 2001
117
118
119 While it is perfectly acceptable for a list identifier to be
120 completely independent of the domain name of the host machine
121 servicing the mailing list, the owner of a mailing list MUST NOT
122 generate list identifiers in any domain namespace for which they do
123 not have authority. For example, a mailing list hosting service may
124 choose to assign list identifiers in their own domain based
125 namespace, or they may allow their clients (the list owners) to
126 provide list identifiers in a namespace for which the owner has
127 authority.
128
129 If the owner of the list does not have the authority to create a list
130 identifier in a domain-based namespace, they may create unmanaged
131 list identifiers in the special unmanaged domain "localhost". This
132 would apply to personal users, or users unable to afford domain name
133 registration fees.
134
135 The syntax for a list identifier in ABNF [RFC2234] follows:
136
137 list-id = list-label "." list-id-namespace
138
139 list-label = dot-atom-text
140
141 list-id-namespace = domain-name / unmanaged-list-id-namespace
142
143 unmanaged-list-id-namespace = "localhost"
144
145 domain-name = dot-atom-text
146
147 Where:
148
149 dot-atom-text is defined in [DRUMS]
150
151 "localhost" is a reserved domain name is defined in [RFC2606]
152
153 In addition, a list identifier (list-id) MUST NOT be longer than 255
154 octets in length, for future compatibility. It should be noted that
155 "localhost" is not valid for the domain-name rule.
156
1573. The List-Id Header Field
158
159 This document presents a header field which will provide an
160 identifier for an e-mail distribution list. This header SHOULD be
161 included on all messages distributed by the list (including command
162 responses to individual users), and on other messages where the
163 message clearly applies to this particular distinct list. There MUST
164 be no more than one of each field present in any given message.
165
166
167
168
169
170Chandhok & Wenger Standards Track [Page 3]
171
172RFC 2919 List-Id March 2001
173
174
175 This field MUST only be generated by mailing list software, not end
176 users.
177
178 The contents of the List-Id header mostly consist of angle-bracket
179 ('<', '>') enclosed identifier, with internal whitespace being
180 ignored. MTAs MUST NOT insert whitespace within the brackets, but
181 client applications should treat any such whitespace, that might be
182 inserted by poorly behaved MTAs, as characters to ignore.
183
184 The list header fields are subject to the encoding and character
185 restrictions for mail headers as described in [RFC822].
186
187 The List-Id header MAY optionally include a description by including
188 it as a "phrase" [DRUMS] before the angle-bracketed list identifier.
189 The MUA MAY choose to use this description in its user interface;
190 however, any MUA that intends to make use of the description should
191 be prepared to properly parse and decode any encoded strings or other
192 legal phrase components. For many MUAs the parsing of the List-Id
193 header will simply consist of extracting the list identifier from
194 between the delimiting angle brackets.
195
196 The syntax of the List-Id header follows:
197
198 list-id-header = "List-ID:" [phrase] "<" list-id ">" CRLF ../webmail/api.go:1952
199
200 where phrase and CRLF are as defined in [DRUMS]. Unlike most headers
201 in [RFC822], the List-Id header does not allow free insertion of
202 whitespace and comments around tokens. Any descriptive text must be
203 presented in the optional phrase component of the header.
204
205 Examples:
206
207List-Id: List Header Mailing List <list-header.nisto.com>
208List-Id: <commonspace-users.list-id.within.com>
209List-Id: "Lena's Personal Joke List"
210 <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost>
211List-Id: "An internal CMU List" <0Jks9449.list-id.cmu.edu>
212List-Id: <da39efc25c530ad145d41b86f7420c3b.052000.localhost>
213
2144. Persistence of List Identifiers
215
216 Although the list identifier MAY be changed by the mailing list
217 administrator this is not desirable. (Note that there is no
218 disadvantage to changing the description portion of the List-Id
219 header.) A MUA may not recognize the change to the list identifier
220 because the MUA SHOULD treat a different list identifier as a
221 different list. As such the mailing list administrator SHOULD avoid
222 changing the list identifier even when the host serving the list
223
224
225
226Chandhok & Wenger Standards Track [Page 4]
227
228RFC 2919 List-Id March 2001
229
230
231 changes. On the other hand, transitioning from an informal
232 unmanaged-list-id-namespace to a domain namespace is an acceptable
233 reason to change the list identifier. Also if the focus of the list
234 changes sufficiently the administrator may wish to retire the
235 previous list and its associated identifier to start a new list
236 reflecting the new focus.
237
2385. Uniqueness of List Identifiers
239
240 This proposal seeks to leverage the existing administrative process
241 already in place for domain name allocation. In particular, we
242 exploit the fact that domain name ownership creates a namespace that
243 by definition can be used to create unique identifiers within the
244 domain.
245
246 In addition, there must be a mechanism for identification of mailing
247 lists that are administrated by some entity without administrative
248 access to a domain. In this case, general heuristics can be given to
249 reduce the chance of collision, but it cannot be guaranteed. If a
250 list owner requires a guarantee, they are free to register a domain
251 name under their control.
252
253 It is suggested, but not required, that list identifiers be created
254 under a subdomain of "list-id" within any given domain. This can
255 help to reduce internal conflicts between the administrators of the
256 subdomains of large organizations. For example, list identifiers at
257 "within.com" are generated in the subdomain of "list-id.within.com".
258
259 List-IDs not ending with ".localhost" MUST be globally unique in
260 reference to all other mailing lists.
261
262 List owners wishing to use the special "localhost" namespace for
263 their list identifier SHOULD use the month and year (in the form
264 MMYYYY) that they create the list identifier as a "subdomain" of the
265 "localhost" namespace. In addition, some portion of the list
266 identifier MUST be a randomly generated string. List owners
267 generating such identifiers should refer to [MSGID] for further
268 suggestions on generating a unique identifier, and [RFC1750] for
269 suggestions on generating random numbers. In particular, list
270 identifiers that have a random component SHOULD contain a hex
271 encoding of 128 bits of randomness (resulting in 32 hex characters)
272 as part of the list identifier
273
274 Thus, list identifiers such as
275 <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost> and
276 <da39efc25c530ad145d41b86f7420c3b.051998.localhost> conform to these
277 guidelines, while <lenas-jokes.021999.localhost> and
278
279
280
281
282Chandhok & Wenger Standards Track [Page 5]
283
284RFC 2919 List-Id March 2001
285
286
287 <mylist.localhost> do not. A particular list owner with several
288 lists MAY choose to use the same random number subdomain when
289 generating list identifiers for each of the lists.
290
291 List-IDs ending with ".localhost" are not guaranteed to be globally
292 unique.
293
2946. Operations on List Identifiers
295
296 There is only one operation defined for list identifiers, that of
297 case insensitive equality (See Section 3.4.7., CASE INDEPENDENCE
298 [RFC822]). The sole use of a list identifier is to identify a
299 mailing list, and the sole use of the List-Id header is to mark a
300 particular message as belonging to that list. The comparison
301 operation MUST ignore any part of the List-Id header outside of the
302 angle brackets, the MUA MAY choose to inform the user if the
303 descriptive name of a mailing list changes.
304
3057. Supporting Nested Lists
306
307 A list that is a sublist for another list in a nested mailing list
308 hierarchy MUST NOT modify the List-Id header field; however, this
309 will only be possible when the nested mailing list is aware of the
310 relationship between it and its "parent" mailing lists. If a mailing
311 list processor encounters a List-Id header field from any unexpected
312 source it SHOULD NOT pass it through to the list. This implies that
313 mailing list processors may have to be updated to properly support
314 List-Ids for nested lists.
315
3168. Security Considerations
317
318 There are very few new security concerns generated with this
319 proposal. Message headers are an existing standard, designed to
320 easily accommodate new types. There may be concern with headers
321 being forged, but this problem is inherent in Internet e-mail, not
322 specific to the header described in this document. Further, the
323 implications are relatively harmless.
324
325 As mentioned above, mail list processors SHOULD NOT allow any user-
326 originated List-Id fields to pass through to their lists, lest they
327 confuse the user and have the potential to create security problems.
328
329 On the client side, a forged list identifier may break automated
330 processing. The list identifier (in its current form) SHOULD NOT be
331 used as an indication of the authenticity of the message.
332
333
334
335
336
337
338Chandhok & Wenger Standards Track [Page 6]
339
340RFC 2919 List-Id March 2001
341
342
3439. Acknowledgements
344
345 The numerous participants of the List-Header [LISTHEADER] and
346 ListMom-Talk [LISTMOM] mailing lists contributed much to the
347 formation and structure of this document.
348
349 Grant Neufeld <grant@acm.org> focused much of the early discussion,
350 and thus was essential in the creation of this document.
351
352References
353
354 [LISTHEADER] "List-Header" Mail list. list-header@list.nisto.com
355 <http://www.nisto.com/listspec/mail/>
356 <http://www.nisto.com/listspec/>
357
358 [LISTMOM] "ListMom-Talk" Mail list. listmom-talk@skyweyr.com
359 <http://cgi.skyweyr.com/ListMom.Home>
360
361 [MSGID] J. Zawinski, M. Curtin, "Recommendations for generating
362 Message IDs", Work in Progress.
363
364 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet
365 Text Messages", RFC 822, August 1982.
366
367 [RFC1750] Eastlake, D., Crocker S. and J. Schiller, "Randomness
368 Recommendations for Security", RFC 1750, December 1994.
369
370 [RFC2234] Crocker, D. and P. Overell. "Augmented BNF for Syntax
371 Specifications: ABNF", RFC 2234, November 1997.
372
373 [RFC2369] Neufeld G. and J. Baer, "The Use of URLs as Meta-Syntax
374 for Core Mail List Commands and their Transport through
375 Message Header Fields", RFC 2369, July 1998.
376
377 [RFC2606] Eastlake, 3rd, D., and S. Panitz. "Reserved Top Level
378 DNS Names", BCP 32, RFC 2606, June 1999.
379
380 [RFC2822] Resnick, P., Editor, "Internet Message Format Standard",
381 STD 11, RFC 2822, March 2001.
382
383
384
385
386
387
388
389
390
391
392
393
394Chandhok & Wenger Standards Track [Page 7]
395
396RFC 2919 List-Id March 2001
397
398
399Authors' Addresses
400
401 Ravinder Chandhok
402 QUALCOMM, Inc.
403 5775 Morehouse Drive
404 San Diego, CA 92121 USA
405
406 EMail: chandhok@qualcomm.com
407
408
409 Geoffrey Wenger
410 QUALCOMM, Inc.
411 5775 Morehouse Drive
412 San Diego, CA 92121 USA
413
414 EMail: gwenger@qualcomm.com
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450Chandhok & Wenger Standards Track [Page 8]
451
452RFC 2919 List-Id March 2001
453
454
455Full Copyright Statement
456
457 Copyright (C) The Internet Society (2001). All Rights Reserved.
458
459 This document and translations of it may be copied and furnished to
460 others, and derivative works that comment on or otherwise explain it
461 or assist in its implementation may be prepared, copied, published
462 and distributed, in whole or in part, without restriction of any
463 kind, provided that the above copyright notice and this paragraph are
464 included on all such copies and derivative works. However, this
465 document itself may not be modified in any way, such as by removing
466 the copyright notice or references to the Internet Society or other
467 Internet organizations, except as needed for the purpose of
468 developing Internet standards in which case the procedures for
469 copyrights defined in the Internet Standards process must be
470 followed, or as required to translate it into languages other than
471 English.
472
473 The limited permissions granted above are perpetual and will not be
474 revoked by the Internet Society or its successors or assigns.
475
476 This document and the information contained herein is provided on an
477 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
478 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
479 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
480 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
481 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
482
483Acknowledgement
484
485 Funding for the RFC Editor function is currently provided by the
486 Internet Society.
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506Chandhok & Wenger Standards Track [Page 9]
507
508