2005-05-30 [paul] 1.9.11cvs19
[claws.git] / doc / src / rfc2368.txt
1
2
3
4
5
6
7 Network Working Group                                       P. Hoffman
8 Request for Comments: 2368                    Internet Mail Consortium
9 Updates: 1738, 1808                                        L. Masinter
10 Category: Standards Track                            Xerox Corporation
11                                                            J. Zawinski
12                                                Netscape Communications
13                                                              July 1998
14
15
16                          The mailto URL scheme
17
18 Status of this Memo
19
20    This document specifies an Internet standards track protocol for the
21    Internet community, and requests discussion and suggestions for
22    improvements.  Please refer to the current edition of the "Internet
23    Official Protocol Standards" (STD 1) for the standardization state
24    and status of this protocol.  Distribution of this memo is unlimited.
25
26 Copyright Notice
27
28    Copyright (C) The Internet Society (1998).  All Rights Reserved.
29
30 Abstract
31
32    This document defines the format of Uniform Resource Locators (URL)
33    for designating electronic mail addresses. It is one of a suite of
34    documents which replace RFC 1738, 'Uniform Resource Locators', and
35    RFC 1808, 'Relative Uniform Resource Locators'. The syntax of
36    'mailto' URLs from RFC 1738 is extended to allow creation of more RFC
37    822 messages by allowing the URL to express additional header and
38    body fields.
39
40 1. Introduction
41
42    The mailto URL scheme is used to designate the Internet mailing
43    address of an individual or service. In its simplest form, a mailto
44    URL contains an Internet mail address.
45
46    For greater functionality, because interaction with some resources
47    may require message headers or message bodies to be specified as well
48    as the mail address, the mailto URL scheme is extended to allow
49    setting mail header fields and the message body.
50
51 2. Syntax of a mailto URL
52
53    Following the syntax conventions of RFC 1738 [RFC1738], a "mailto"
54    URL has the form:
55
56
57
58 Hoffman, et. al.            Standards Track                     [Page 1]
59
60 RFC 2368                 The mailto URL scheme                 July 1998
61
62
63      mailtoURL  =  "mailto:" [ to ] [ headers ]
64      to         =  #mailbox
65      headers    =  "?" header *( "&" header )
66      header     =  hname "=" hvalue
67      hname      =  *urlc
68      hvalue     =  *urlc
69
70    "#mailbox" is as specified in RFC 822 [RFC822]. This means that it
71    consists of zero or more comma-separated mail addresses, possibly
72    including "phrase" and "comment" components. Note that all URL
73    reserved characters in "to" must be encoded: in particular,
74    parentheses, commas, and the percent sign ("%"), which commonly occur
75    in the "mailbox" syntax.
76
77    "hname" and "hvalue" are encodings of an RFC 822 header name and
78    value, respectively. As with "to", all URL reserved characters must
79    be encoded.
80
81    The special hname "body" indicates that the associated hvalue is the
82    body of the message. The "body" hname should contain the content for
83    the first text/plain body part of the message. The mailto URL is
84    primarily intended for generation of short text messages that are
85    actually the content of automatic processing (such as "subscribe"
86    messages for mailing lists), not general MIME bodies.
87
88    Within mailto URLs, the characters "?", "=", "&" are reserved.
89
90    Because the "&" (ampersand) character is reserved in HTML, any mailto
91    URL which contains an ampersand must be spelled differently in HTML
92    than in other contexts.  A mailto URL which appears in an HTML
93    document must use "&" instead of "&".
94
95    Also note that it is legal to specify both "to" and an "hname" whose
96    value is "to". That is,
97
98      mailto:addr1%2C%20addr2
99
100      is equivalent to
101
102      mailto:?to=addr1%2C%20addr2
103
104      is equivalent to
105
106      mailto:addr1?to=addr2
107
108    8-bit characters in mailto URLs are forbidden. MIME encoded words (as
109    defined in [RFC2047]) are permitted in header values, but not for any
110    part of a "body" hname.
111
112
113
114 Hoffman, et. al.            Standards Track                     [Page 2]
115
116 RFC 2368                 The mailto URL scheme                 July 1998
117
118
119 3. Semantics and operations
120
121    A mailto URL designates an "internet resource", which is the mailbox
122    specified in the address. When additional headers are supplied, the
123    resource designated is the same address, but with an additional
124    profile for accessing the resource. While there are Internet
125    resources that can only be accessed via electronic mail, the mailto
126    URL is not intended as a way of retrieving such objects
127    automatically.
128
129    In current practice, resolving URLs such as those in the "http"
130    scheme causes an immediate interaction between client software and a
131    host running an interactive server. The "mailto" URL has unusual
132    semantics because resolving such a URL does not cause an immediate
133    interaction. Instead, the client creates a message to the designated
134    address with the various header fields set as default. The user can
135    edit the message, send this message unedited, or choose not to send
136    the message. The operation of how any URL scheme is resolved is not
137    mandated by the URL specifications.
138
139 4. Unsafe headers
140
141    The user agent interpreting a mailto URL SHOULD choose not to create
142    a message if any of the headers are considered dangerous; it may also
143    choose to create a message with only a subset of the headers given in
144    the URL.  Only the Subject, Keywords, and Body headers are believed
145    to be both safe and useful.
146
147    The creator of a mailto URL cannot expect the resolver of a URL to
148    understand more than the "subject" and "body" headers. Clients that
149    resolve mailto URLs into mail messages should be able to correctly
150    create RFC 822-compliant mail messages using the "subject" and "body"
151    headers.
152
153 5. Encoding
154
155    RFC 1738 requires that many characters in URLs be encoded. This
156    affects the mailto scheme for some common characters that might
157    appear in addresses, headers or message contents. One such character
158    is space (" ", ASCII hex 20). Note the examples above that use "%20"
159    for space in the message body.  Also note that line breaks in the
160    body of a message MUST be encoded with "%0D%0A".
161
162    People creating mailto URLs must be careful to encode any reserved
163    characters that are used in the URLs so that properly-written URL
164    interpreters can read them. Also, client software that reads URLs
165    must be careful to decode strings before creating the mail message so
166
167
168
169
170 Hoffman, et. al.            Standards Track                     [Page 3]
171
172 RFC 2368                 The mailto URL scheme                 July 1998
173
174
175    that the mail messages appear in a form that the recipient will
176    understand. These strings should be decoded before showing the user
177    the message.
178
179    The mailto URL scheme is limited in that it does not provide for
180    substitution of variables. Thus, a message body that must include a
181    user's email address can not be encoded using the mailto URL. This
182    limitation also prevents mailto URLs that are signed with public keys
183    and other such variable information.
184
185 6. Examples
186
187    URLs for an ordinary individual mailing address:
188
189      <mailto:chris@example.com>
190
191    A URL for a mail response system that requires the name of the file
192    in the subject:
193
194      <mailto:infobot@example.com?subject=current-issue>
195
196    A mail response system that requires a "send" request in the body:
197
198      <mailto:infobot@example.com?body=send%20current-issue>
199
200    A similar URL could have two lines with different "send" requests (in
201    this case, "send current-issue" and, on the next line, "send index".)
202
203      <mailto:infobot@example.com?body=send%20current-
204      issue%0D%0Asend%20index>
205
206    An interesting use of your mailto URL is when browsing archives of
207    messages. Each browsed message might contain a mailto URL like:
208
209      <mailto:foobar@example.com?In-Reply-
210      To=%3c3469A91.D10AF4C@example.com>
211
212    A request to subscribe to a mailing list:
213
214      <mailto:majordomo@example.com?body=subscribe%20bamboo-l>
215
216    A URL for a single user which includes a CC of another user:
217
218      <mailto:joe@example.com?cc=bob@example.com&body=hello>
219
220    Another way of expressing the same thing:
221
222      <mailto:?to=joe@example.com&cc=bob@example.com&body=hello>
223
224
225
226 Hoffman, et. al.            Standards Track                     [Page 4]
227
228 RFC 2368                 The mailto URL scheme                 July 1998
229
230
231    Note the use of the "&" reserved character, above. The following
232    example, by using "?" twice, is incorrect:
233
234      <mailto:joe@example.com?cc=bob@example.com?body=hello>   ; WRONG!
235
236    According to RFC 822, the characters "?", "&", and even "%" may occur
237    in addr-specs. The fact that they are reserved characters in this URL
238    scheme is not a problem: those characters may appear in mailto URLs,
239    they just may not appear in unencoded form. The standard URL encoding
240    mechanisms ("%" followed by a two-digit hex number) must be used in
241    certain cases.
242
243    To indicate the address "gorby%kremvax@example.com" one would do:
244
245      <mailto:gorby%25kremvax@example.com>
246
247    To indicate the address "unlikely?address@example.com", and include
248    another header, one would do:
249
250      <mailto:unlikely%3Faddress@example.com?blat=foop>
251
252    As described above, the "&" (ampersand) character is reserved in HTML
253    and must be replacded with "&amp;". Thus, a complex URL that has
254    internal ampersands might look like:
255
256      Click
257      <a href="mailto:?to=joe@xyz.com&amp;cc=bob@xyz.com&amp;body=hello">
258      mailto:?to=joe@xyz.com&amp;cc=bob@xyz.com&amp;body=hello</a> to
259      send a greeting message to <i>Joe and Bob</i>.
260
261 7. Security Considerations
262
263    The mailto scheme can be used to send a message from one user to
264    another, and thus can introduce many security concerns. Mail messages
265    can be logged at the originating site, the recipient site, and
266    intermediary sites along the delivery path. If the messages are not
267    encoded, they can also be read at any of those sites.
268
269    A mailto URL gives a template for a message that can be sent by mail
270    client software. The contents of that template may be opaque or
271    difficult to read by the user at the time of specifying the URL.
272    Thus, a mail client should never send a message based on a mailto URL
273    without first showing the user the full message that will be sent
274    (including all headers that were specified by the mailto URL), fully
275    decoded, and asking the user for approval to send the message as
276    electronic mail. The mail client should also make it clear that the
277    user is about to send an electronic mail message, since the user may
278    not be aware that this is the result of a mailto URL.
279
280
281
282 Hoffman, et. al.            Standards Track                     [Page 5]
283
284 RFC 2368                 The mailto URL scheme                 July 1998
285
286
287    A mail client should never send anything without complete disclosure
288    to the user of what is will be sent; it should disclose not only the
289    message destination, but also any headers. Unrecognized headers, or
290    headers with values inconsistent with those the mail client would
291    normally send should be especially suspect. MIME headers (MIME-
292    Version, Content-*) are most likely inappropriate, as are those
293    relating to routing (From, Bcc, Apparently-To, etc.)
294
295    Note that some headers are inherently unsafe to include in a message
296    generated from a URL. For example, headers such as "From:", "Bcc:",
297    and so on, should never be interpreted from a URL. In general, the
298    fewer headers interpreted from the URL, the less likely it is that a
299    sending agent will create an unsafe message.
300
301    Examples of problems with sending unapproved mail include:
302
303      * mail that breaks laws upon delivery, such as making illegal
304        threats;
305
306      * mail that identifies the sender as someone interested in breaking
307        laws;
308
309      * mail that identifies the sender to an unwanted third party;
310
311      * mail that causes a financial charge to be incurred on the sender;
312
313      * mail that causes an action on the recipient machine that causes
314        damage that might be attributed to the sender.
315
316    Programs that interpret mailto URLs should ensure that the SMTP
317    "From" address is set and correct.
318
319 8. IANA Considerations
320
321    This document changes the definition of the mailto: URI scheme; any
322    registry of URI schemes should refer to this document rather than its
323    predecessor, RFC 1738.
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338 Hoffman, et. al.            Standards Track                     [Page 6]
339
340 RFC 2368                 The mailto URL scheme                 July 1998
341
342
343 9. References
344
345    [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
346             Messages", STD 11, RFC 822, August 1982.
347
348    [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, Editors,
349              "Uniform Resource Locators (URL)", RFC 1738, December 1994.
350
351    [RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC
352              1808, June 1995.
353
354    [RFC2047] Moore, K., "MIME Part Three: Message Header Extensions for
355              Non-ASCII Text", RFC 2047, November 1996.
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 Hoffman, et. al.            Standards Track                     [Page 7]
395
396 RFC 2368                 The mailto URL scheme                 July 1998
397
398
399 A. Change from RFC 1738
400
401    RFC 1738 defined only a simple 'mailto' with no headers, just an
402    addr-spec (not a full mailbox.)  However, required usage and
403    implementation has led to the development of an extended syntax that
404    included more header fields.
405
406 B. Acknowledgments
407
408    This document was derived from RFC 1738 and RFC 1808 [RFC1808]; the
409    acknowledgments from those specifications still applies.
410
411    The following people contributed to this memo or had and discussed
412    similar ideas for mailto.
413
414    Harald Alvestrand
415    Bryan Costales
416    Steve Dorner
417    Al Gilman
418    Mark Joseph
419    Laurence Lundblade
420    Keith Moore
421    Jacob Palme
422    Michael Patton
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 Hoffman, et. al.            Standards Track                     [Page 8]
451
452 RFC 2368                 The mailto URL scheme                 July 1998
453
454
455 C. Author Contact Information
456
457    Paul E. Hoffman
458    Internet Mail Consortium
459    127 Segre Place
460    Santa Cruz, CA  95060 USA
461
462    EMail: phoffman@imc.org
463
464
465    Larry Masinter
466    Xerox Corporation
467    3333 Coyote Hill Road
468    Palo Alto, CA 94304 USA
469
470    EMail: masinter@parc.xerox.com
471
472
473    Jamie Zawinski
474    Netscape Communications Corp.
475    501 East Middlefield Road
476    Mountain View, CA 94043 USA
477
478    EMail: jwz@netscape.com
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 Hoffman, et. al.            Standards Track                     [Page 9]
507
508 RFC 2368                 The mailto URL scheme                 July 1998
509
510
511 D.  Full Copyright Statement
512
513    Copyright (C) The Internet Society (1998).  All Rights Reserved.
514
515    This document and translations of it may be copied and furnished to
516    others, and derivative works that comment on or otherwise explain it
517    or assist in its implementation may be prepared, copied, published
518    and distributed, in whole or in part, without restriction of any
519    kind, provided that the above copyright notice and this paragraph are
520    included on all such copies and derivative works.  However, this
521    document itself may not be modified in any way, such as by removing
522    the copyright notice or references to the Internet Society or other
523    Internet organizations, except as needed for the purpose of
524    developing Internet standards in which case the procedures for
525    copyrights defined in the Internet Standards process must be
526    followed, or as required to translate it into languages other than
527    English.
528
529    The limited permissions granted above are perpetual and will not be
530    revoked by the Internet Society or its successors or assigns.
531
532    This document and the information contained herein is provided on an
533    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
534    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
535    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
536    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
537    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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 Hoffman, et. al.            Standards Track                    [Page 10]
563