summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5064.txt
blob: 0921e9e28e5a537e825c513e409dc69d027dd744 (plain) (blame)
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
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
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
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
Network Working Group                                          M. Duerst
Request for Comments: 5064                      Aoyama Gakuin University
Category: Standards Track                                  December 2007


                  The Archived-At Message Header Field

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This memo defines a new email header field, Archived-At:, to provide
   a direct link to the archived form of an individual email message.

Table of Contents

   1. Introduction ....................................................2
   2. Header Field Definition .........................................2
      2.1. Syntax .....................................................2
      2.2. Multiple Archived-At Header Fields .........................3
      2.3. Interaction with Message Fragmentation and Reassembly ......3
      2.4. Syntax Extension for Internationalized Message Headers .....3
      2.5. The X-Archived-At Header Field .............................4
   3. Implementation and Usage Considerations .........................4
      3.1. Formats of Archived Message ................................4
      3.2. Implementation Considerations ..............................4
      3.3. Usage Considerations .......................................5
   4. Security Considerations .........................................6
   5. IANA Considerations .............................................7
      5.1. Registration of the Archive-At Header Field ................7
      5.2. Registration of the X-Archived-At Header Field .............7
   6. Acknowledgments .................................................8
   7. References ......................................................8
      7.1. Normative References .......................................8
      7.2. Informative References .....................................8










Duerst                      Standards Track                     [Page 1]
^L
RFC 5064          The Archived-At Message Header Field     December 2007


1.  Introduction

   [RFC2369] defines a number of header fields that can be added to
   Internet messages such as those sent by email distribution lists or
   in netnews [RFC1036].  One of them is the List-Archive header field
   that describes how to access archives for the list.  This allows
   access to the archives as a whole, but not an individual message.

   There is often a need or desire to refer to the archived form of a
   single message.  For more detailed usage scenarios, please see
   Section 3.3.  This memo defines a new header, Archived-At, to refer
   to a single message at an archived location.  This provides quick
   access to the location of a mailing list message in the list archive.
   It can also be used independently of mailing lists, for example in
   connection with legal requirements to archive certain messages.

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in [RFC2119].

2.  Header Field Definition

2.1.  Syntax

   For the Archived-At header field, the field name is "Archived-At".
   The field body consist of a URI [STD66] enclosed in angle brackets
   ('<', '>').  The URI MAY contain folding whitespace (FWS, [RFC2822]),
   which is ignored.  Mail Transfer Agents (MTAs) MUST NOT insert
   whitespace within the angle brackets, but client applications SHOULD
   ignore any whitespace, which might have been inserted by poorly
   behaved MTAs.  The URI points to an archived version of the message.
   See Section 3.1 for more details.

   This header field is subject to the encoding and character
   restrictions for mail headers as described in [RFC2822].

   More formally, the header field is defined as follows in Augmented
   BNF (ABNF) according to [RFC4234]:

      archived-at = "Archived-At:" [FWS] "<" folded-URI ">" CRLF
      folded-URI  = <URI, but free insertion of FWS permitted>

   where URI is defined in [STD66], and CRLF and FWS are defined in
   [RFC2822].

   To convert a folded-URI to a URI, first apply standard [RFC2822]
   unfolding rules (replacing FWS with a single SP), and then delete any
   remaining un-encoded SP characters.



Duerst                      Standards Track                     [Page 2]
^L
RFC 5064          The Archived-At Message Header Field     December 2007


   This syntax is kept simple in that only one URI per header field is
   allowed.  In this respect, the syntax is different from [RFC2369].
   Also, comments are not allowed.

2.2.  Multiple Archived-At Header Fields

   Each Archived-At header field only contains a single URI.  If it is
   desired to list multiple URIs where an archived copy of the message
   can be found, a separate Archived-At field per URI is required.
   Multiple Archived-At header fields with the same URI SHOULD be
   avoided.  An Archived-At header field SHOULD only be created if the
   message is actually being made available at the URI given in the
   header field.

   If a message is forwarded from a list to a sublist and both lists
   support adding the Archived-At header field, then the sublist SHOULD
   add a new Archived-At header field without removing the already
   existing one(s), unless the header field is exactly the same as an
   already existing one, in which case the new header field SHOULD NOT
   be added.

2.3.  Interaction with Message Fragmentation and Reassembly

   [RFC2046] allows for the fragmentation and reassembly of messages.
   Archived-At header fields are to be treated in the same way as
   Comments header fields, i.e., copied to the first fragment message
   header on fragmentation and back from there to the header of the
   reassembled message.

   This treatment has been chosen for compatibility with existing
   infrastructure.  It means that Archived-At header fields in the first
   fragment message MAY refer to an archived version of the whole,
   unfragmented message.  To avoid confusion, Archived-At headers SHOULD
   NOT be added to fragment messages.

2.4.  Syntax Extension for Internationalized Message Headers

   There are some efforts to allow non-ASCII text directly in message
   header field bodies.  In such contexts, the URI non-terminal in the
   syntax defined in Section 2.1 is to be replaced by an
   Internationalized Resource Identifier (IRI) as defined in [RFC3987].
   The specifics of the actual octet encoding of the IRI will follow the
   rules for general direct encoding of non-ASCII text.  For conversion
   between IRIs and URIs, the procedures defined in [RFC3987] are to be
   applied.






Duerst                      Standards Track                     [Page 3]
^L
RFC 5064          The Archived-At Message Header Field     December 2007


2.5.  The X-Archived-At Header Field

   For backwards compatibility, this document also describes the
   X-Archived-At header field, a precursor of the Archived-At header
   field.  The X-Archived-At header field MAY also be parsed, but SHOULD
   not be generated.

   The following is the syntax of the X-Archived-At header field in ABNF
   according to [RFC4234] (which also defines SP):

      obs-archived-at = "X-Archived-At:"  SP URI CRLF

   The X-Archived-At header field does not allow whitespace inside URI.

3.  Implementation and Usage Considerations

3.1.  Formats of Archived Message

   There is no restriction on the format used to serve the archived
   message from the URI in an Archived-At header field.  It is expected
   that in many cases, the archived message will be served as (X)HTML,
   as plain text, or in its original form as message/rfc822 [RFC2046].
   Some forms of URIs may imply the format in which the archived message
   is served, although this should not be relied upon.

   If the protocol used to retrieve the message allows for content
   negotiation, then it is also possible to serve the archived message
   in several different formats.  As an example, an HTTP URI in an
   Archived-At header may make it possible to serve the archived message
   both as text/html for human consumption in a browser and as
   message/rfc822 for use by a mail user agent (MUA) without loss of
   information.

3.2.  Implementation Considerations

   Mailing list expanders and email archives are often separate pieces
   of software.  It may therefore be difficult to create an Archived-At
   header field in the mailing list expander software.

   One way to address this difficulty is to have the mailing list
   expander software generate an unambiguous URI, e.g., a URI based on
   the message identifier of the incoming email, and to set up the
   archiving system so that it redirects requests for such URIs to the
   actual messages.  If the email does not contain a message identifier,
   a unique identifier can be generated.






Duerst                      Standards Track                     [Page 4]
^L
RFC 5064          The Archived-At Message Header Field     December 2007


   Such a system has been implemented and is in productive use at W3C.
   As an example, the URI
   "http://www.w3.org/mid/0I5U00G08DFGCR@mailsj-v1.corp.adobe.com",
   containing the significant part of the message identifier
   "<0I5U00G08DFGCR@mailsj-v1.corp.adobe.com>", is redirected to the URI
   of this message in the W3C mailing-list archive at
   http://lists.w3.org/Archives/Public/uri/2004Oct/0017.html.

   Source code for this implementation is available at
   http://dev.w3.org/cvsweb/search/, in particular
   http://dev.w3.org/cvsweb/search/cgi/mid.pl and
   http://dev.w3.org/cvsweb/search/bin/msgid-db.pl.  These locations may
   be subject to change.

   When using the message identifier to create an address for the
   archived mail, care has to be taken to escape characters in the
   message identifier that are not allowed in the URI, or to remove
   them, as done above for the "<" and ">" delimiters.

   Implementations such as that described above can introduce a security
   issue.  Somebody might deliberately reuse a message identifier to
   break the link to a message.  This can be addressed by checking
   incoming message identifiers against those of the messages already in
   the archive and discarding incoming duplicates, by checking the
   content of incoming duplicates and discarding them if they are
   significantly different from the first message, by offering multiple
   choices in the response to the URI, or by using some authentication
   mechanism on incoming messages.

3.3.  Usage Considerations

   It may at first seem strange to have a pointer to an archived form of
   a message in a header field of that same message.  After all, if one
   has the message, why would one need a pointer to it?  It turns out
   that such pointers can be extremely useful.  This section describes
   some of the scenarios for their use.

   A user may want to refer to messages in a non-message context, such
   as on a Web page, in an instant message, or in a phone conversation.
   In such a case, the user can extract the URI from the Archived-At
   header field, avoiding the search for the correct message in the
   archive.

   A user may want to refer to other messages in a message context.
   Referring to a single message is often done by replying to that
   message.  However, when referring to more than one message, providing
   pointers to archived messages is a widespread practice.  The
   Archived-At header field makes it easier to provide these pointers.



Duerst                      Standards Track                     [Page 5]
^L
RFC 5064          The Archived-At Message Header Field     December 2007


   A user may want to find messages related to a message at hand.  The
   user may not have received the related messages, and therefore needs
   to use an archive.  The user may also prefer finding related messages
   in the archive rather than in her MUA, because messages in archives
   may be linked in ways not provided by the MUA.  The Archived-At
   header field provides a link to the starting point in the archive
   from which to find related messages.

   Please note that in the above usage scenarios, it is mostly the human
   reader, rather than the email client software, that makes use of the
   URI in the Archived-At header.  However, this does not rule out the
   use of the URI in the Archived-At header by the email client or other
   software if such use is found helpful.

4.  Security Considerations

   There are many potential security issues when activating and
   dereferencing a URI.  For more details, including some
   countermeasures, please see [STD66].  In the context of this
   proposal, the following are particularly relevant: An intruder may
   get access to the message transmission and be able to insert a URI
   pointing to some malicious content.  This can be addressed by using a
   secured way of message transmission.  Also, somebody may be able to
   construct a message that is harmless when received directly, but that
   produces problems when accessed via the URI.  One reason for this may
   be the format used in the archive, where some content was not
   adequately escaped.  This can be addressed by using adequate
   escaping.

   The Archived-At header field points to some archived form of the
   message itself.  This in turn may contain the Archived-At field.
   This creates a potential for a denial-of-service attack on the server
   pointed to by the URI in the Archived-At header field.  The
   conditions are that the archived form of the message is downloaded
   automatically, and that further URIs in that message are followed and
   downloaded recursively without checking for already downloaded
   resources.  However, this kind of scenario can easily be avoided by
   implementations.  First, the URI in the Archived-At header field
   should not be dereferenced automatically.  Second, appropriate
   measures for loop detection should be used.

   In Section 3.2, an attack is described that may break a URI to a
   message by introducing a new message with the same message
   identifier.  Possible countermeasures are also discussed.







Duerst                      Standards Track                     [Page 6]
^L
RFC 5064          The Archived-At Message Header Field     December 2007


5.  IANA Considerations

5.1.  Registration of the Archive-At Header Field

   IANA has registered the Archived-At header field in the Message
   Header Fields Registry ([RFC3864]) as follows:

      Header field name:
         Archived-At

      Applicable protocol:
         mail (RFC 2822) and netnews (RFC 1036)

      Status:
         standard

      Author/Change controller:
         IETF

      Specification document(s):
          RFC 5064

      Related information:
         none

5.2.  Registration of the X-Archived-At Header Field

   This section is non-normative (specifically, an implementation that
   ignores this section remains compliant with this specification).

   IANA has registered the X-Archived-At header field in the Message
   Header Fields Registry ([RFC3864]) as follows:

      Header field name:
         X-Archived-At

      Applicable protocol:
         mail (RFC 2822) and netnews (RFC 1036)

      Status:
         deprecated

      Author/Change controller:
         IETF

      Specification document(s):
          RFC 5064




Duerst                      Standards Track                     [Page 7]
^L
RFC 5064          The Archived-At Message Header Field     December 2007


      Related information:
         none

6.  Acknowledgments

   The members of the W3C system team, in particular Gerald Oskoboiny,
   Olivier Thereaux, Jose Kahan, and Eric Prud'hommeaux, created the
   mid-based email archive lookup system and the experimental form of
   the Archived-At header.  Pete Resnik provided the motivation for
   writing this memo.  Discussion on the ietf-822@imc.org mailing list,
   in particular contributions by Frank Ellermann, Arnt Gulbrandsen,
   Graham Klyne, Bruce Lilly, Charles Lindsey, and Keith Moore, led to
   further improvements of the proposal.  Chris Newman, Chris Lonvick,
   Stephane Borzmeyer, Vijay K. Gurbani, and S.  Moonesamy provided
   additional valuable comments.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2822]  Resnick, P., Ed., "Internet Message Format", RFC 2822,
              April 2001.

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              September 2004.

   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, January 2005.

   [RFC4234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
              Syntax Specifications: ABNF", RFC 4234, October 2005.

   [STD66]    Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

7.2.  Informative References

   [RFC1036]  Horton, M. and R. Adams, "Standard for interchange of
              USENET messages", RFC 1036, December 1987.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              November 1996.



Duerst                      Standards Track                     [Page 8]
^L
RFC 5064          The Archived-At Message Header Field     December 2007


   [RFC2369]  Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
              for Core Mail List Commands and their Transport through
              Message Header Fields", RFC 2369, July 1998.

Author's Address

   Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever
                 possible, for example as "D&#252;rst" in XML and HTML.)
   Aoyama Gakuin University
   5-10-1 Fuchinobe
   Sagamihara, Kanagawa  229-8558
   Japan

   Phone: +81 42 759 6329
   Fax:   +81 42 759 6495
   EMail: duerst@it.aoyama.ac.jp
   URI:   http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/


































Duerst                      Standards Track                     [Page 9]
^L
RFC 5064          The Archived-At Message Header Field     December 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.












Duerst                      Standards Track                    [Page 10]
^L