idnits 2.17.1 draft-hoffman-mailto-url-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 330 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 65 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 121: '...ing a mailto URL SHOULD choose not to ...' RFC 2119 keyword, line 138: '...body of a message MUST be encoded with...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1808 (Obsoleted by RFC 3986) Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Paul Hoffman 2 draft-hoffman-mailto-url-05 Internet Mail Consortium 3 June 8, 1997 Larry Masinter 4 Expires in six months Xerox Corporation 5 Jamie Zawinski 6 Netscape Communications 8 The mailto URL scheme 10 Status of This Memo 12 This document is an Internet-Draft. Internet-Drafts are working documents 13 of the Internet Engineering Task Force (IETF), its areas, and its working 14 groups. Note that other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months and 18 may be updated, replaced, or obsoleted by other documents at any time. It 19 is inappropriate to use Internet- Drafts as reference material or to cite 20 them other than as ``work in progress.'' 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Abstract 31 This document defines the format of Uniform Resource Locators (URL) for 32 designating electronic mail addresses. It is one of a suite of documents 33 which replace RFC 1738, "Uniform Resource Locators", and RFC 1808, 34 "Relative Uniform Resource Locators". The syntax of "mailto" URLs from RFC 35 1738 is extended to allow creation of more RFC 822 messages by allowing the 36 URL to express additional header and body fields. 38 1. Introduction 40 The mailto URL scheme is used to designate the Internet mailing address of 41 an individual or service. In its simplest form, a mailto URL contains an 42 Internet mail address. 44 For greater functionality, because interaction with some resources may 45 require message headers or message bodies to be specified as well as the 46 mail address, the mailto URL scheme is extended to allow setting mail 47 header fields and the message body. 49 2. Syntax of a mailto URL 51 Following the syntax conventions of RFC 1738 [RFC1738], a "mailto" URL has 52 the form: 54 mailtoURL = "mailto:" [ to ] [ headers ] 55 to = #mailbox 56 headers = "?" header *( "&" header ) 57 header = hname "=" hvalue 58 hname = *urlc 59 hvalue = *urlc 61 "#mailbox" is as specified in RFC 822 [RFC822]. This means that it consists 62 of zero or more comma-separated mail addresses, possibly including "phrase" 63 and "comment" components. Note that all URL reserved characters in "to" 64 must be encoded: in particular, parentheses, commas, and the percent sign 65 ("%"), which commonly occur in the "mailbox" syntax. 67 "hname" and "hvalue" are encodings of an RFC 822 header name and value, 68 respectively. As with "to", all URL reserved characters must be encoded. 70 The special hname "body" indicates that the associated hvalue is the body 71 of the message. The "body" hname should contain the content for the first 72 text/plain body part of the message. The mailto URL is primarily intended 73 for generation of short text messages that are actually the content of 74 automatic processing (such as "subscribe" messages for mailing lists), not 75 general MIME bodies. 77 Within mailto URLs, the characters "?", "=", "&" are reserved. 79 Because the "&" (ampersand) character is reserved in HTML, any mailto URL 80 which contains an ampersand must be spelled differently in HTML than in 81 other contexts. A mailto URL which appears in an HTML document must use 82 "&" instead of "&". 84 Also note that it is legal to specify both "to" and an "hname" whose value 85 is "to". That is, 87 mailto:addr1%2C%20addr2 89 is equivalent to 91 mailto:?to=addr1%2C%20addr2 93 is equivalent to 95 mailto:addr1?to=addr2 97 8-bit characters in mailto URLs are forbidden. MIME encoded words (as 98 defined in [RFC2047]) are permitted in header values, but not for any part 99 of a "body" hname. 101 3. Semantics and operations 103 A mailto URL designates an "internet resource", which is the mailbox 104 specified in the address. When additional headers are supplied, the 105 resource designated is the same address, but with an additional profile for 106 accessing the resource. While there are Internet resources that can only be 107 accessed via electronic mail, the mailto URL is not intended as a way of 108 retrieving such objects automatically. 110 In current practice, resolving URLs such as those in the "http" scheme 111 causes an immediate interaction between client software and a host running 112 an interactive server. The "mailto" URL has unusual semantics because 113 resolving such a URL does not cause an immediate interaction. Instead, the 114 client creates a message to the designated address with the various header 115 fields set as default. The user can edit the message, send this message 116 unedited, or choose not to send the message. The operation of how any URL 117 scheme is resolved is not mandated by the URL specifications. 119 4. Unsafe headers 121 The user agent interpreting a mailto URL SHOULD choose not to create a 122 message if any of the headers are considered dangerous; it may also choose 123 to create a message with only a subset of the headers given in the URL. 124 Only the Subject, Keywords, and Body headers are believed to be both safe 125 and useful. 127 The creator of a mailto URL cannot expect the resolver of a URL to 128 understand more than the "subject" and "body" headers. Clients that resolve 129 mailto URLs into mail messages should be able to correctly create RFC 130 822-compliant mail messages using the "subject" and "body" headers. 132 5. Encoding 134 RFC 1738 requires that many characters in URLs be encoded. This affects the 135 mailto scheme for some common characters that might appear in addresses, 136 headers or message contents. One such character is space (" ", ASCII hex 137 20). Note the examples above that use "%20" for space in the message body. 138 Also note that line breaks in the body of a message MUST be encoded with 139 "%0D%0A". 141 People creating mailto URLs must be careful to encode any reserved 142 characters that are used in the URLs so that properly-written URL 143 interpreters can read them. Also, client software that reads URLs must be 144 careful to decode strings before creating the mail message so that the mail 145 messages appear in a form that the recipient will understand. These strings 146 should be decoded before showing the user the message. 148 The mailto URL scheme is limited in that it does not provide for 149 substitution of variables. Thus, a message body that must include a user's 150 email address can not be encoded using the mailto URL. This limitation also 151 prevents mailto URLs that are signed with public keys and other such 152 variable information. 154 6. Examples 156 URLs for an ordinary individual mailing address: 158 160 A URL for a mail response system that requires the name of the file in the 161 subject: 163 165 A mail response system that requires a "send" request in the body: 167 169 A similar URL could have two lines with different "send" requests (in this 170 case, "send current-issue" and, on the next line, "send index".) 172 174 An interesting use of your mailto URL is when browsing archives of 175 messages. Each browsed message might contain a mailto URL like: 177 179 A request to subscribe to a mailing list: 181 183 A URL for a single user which includes a CC of another user: 185 187 Another way of expressing the same thing: 189 191 Note the use of the "&" reserved character, above. The following example, 192 by using "?" twice, is incorrect: 194 ; WRONG! 196 According to RFC 822, the characters "?", "&", and even "%" may occur in 197 addr-specs. The fact that they are reserved characters in this URL scheme 198 is not a problem: those characters may appear in mailto URLs, they just may 199 not appear in unencoded form. The standard URL encoding mechanisms ("%" 200 followed by a two-digit hex number) must be used in certain cases. 202 To indicate the address "gorby%kremvax@example.com" one would do: 204 206 To indicate the address "unlikely?address@example.com", and include another 207 header, one would do: 209 211 As described above, the "&" (ampersand) character is reserved in HTML and 212 must be replacded with "&". Thus, a complex URL that has internal 213 ampersands might look like: 215 Click 216 217 mailto:?to=joe@xyz.com&cc=bob@xyz.com&body=hello 218 to send a greeting message to Joe and Bob. 220 7. Security 222 The mailto scheme can be used to send a message from one user to another, 223 and thus can introduce many security concerns. Mail messages can be logged 224 at the originating site, the recipient site, and intermediary sites along 225 the delivery path. If the messages are not encoded, they can also be read 226 at any of those sites. 228 A mailto URL gives a template for a message that can be sent by mail client 229 software. The contents of that template may be opaque or difficult to read 230 by the user at the time of specifying the URL. Thus, a mail client should 231 never send a message based on a mailto URL without first showing the user 232 the full message that will be sent (including all headers that were 233 specified by the mailto URL), fully decoded, and asking the user for 234 approval to send the message as electronic mail. The mail client should 235 also make it clear that the user is about to send an electronic mail 236 message, since the user may not be aware that this is the result of a 237 mailto URL. 239 A mail client should never send anything without complete disclosure to the 240 user of what is will be sent; it should disclose not only the message 241 destination, but also any headers. Unrecognized headers, or headers with 242 values inconsistent with those the mail client would normally send should 243 be especially suspect. MIME headers (MIME-Version, Content-*) are most 244 likely inappropriate, as are those relating to routing (From, Bcc, 245 Apparently-To, etc.) 247 Note that some headers are inherently unsafe to include in a message 248 generated from a URL. For example, headers such as "From:", "Bcc:", and so 249 on, should never be interpreted from a URL. In general, the fewer headers 250 interpreted from the URL, the less likely it is that a sending agent will 251 create an unsafe message. 253 Examples of problems with sending unapproved mail include: 255 * mail that breaks laws upon delivery, such as making illegal threats; 257 * mail that identifies the sender as someone interested in breaking laws; 259 * mail that identifies the sender to an unwanted third party; 261 * mail that causes a financial charge to be incurred on the sender; 263 * mail that causes an action on the recipient machine that causes damage 264 that might be attributed to the sender. 266 Programs that interpret mailto URLs should ensure that the SMTP "From" 267 address is set and correct. 269 8. Acknowledgments 271 This document was derived from RFC 1738 and RFC 1808 [RFC1808]; the 272 acknowledgments from those specifications still applies. 274 The following people contributed to this draft or had and discussed similar 275 ideas for mailto. 277 Harald Alvestrand 278 Bryan Costales 279 Steve Dorner 280 Al Gilman 281 Mark Joseph 282 Laurence Lundblade 283 Keith Moore 284 Jacob Palme 285 Michael Patton 287 9. References 289 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text 290 Messages", RFC 822, University of Delaware, August 1982. 292 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, Editors, "Uniform 293 Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of 294 Minnesota, December 1994. 296 [RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, UC 297 Irvine, June 1995. 299 [RFC2047] Moore, K., "MIME Part Three: Message Header Extensions for 300 Non-ASCII Text", RFC 2047, University of Tennessee, November 1996. 302 Appendixes 304 A. Change from RFC 1738 306 RFC 1738 defined only a simple 'mailto' with no headers, just an addr-spec 307 (not a full mailbox.) However, required usage and implementation has led 308 to the development of an extended syntax that included more header fields. 310 B. Author contact information 312 Paul E. Hoffman 313 Internet Mail Consortium 314 127 Segre Place 315 Santa Cruz, CA 95060 USA 316 phoffman@imc.org 318 Larry Masinter 319 Xerox Corporation 320 3333 Coyote Hill Road 321 Palo Alto, CA 94304 USA 322 masinter@parc.xerox.com 324 Jamie Zawinski 325 Netscape Communications Corp. 326 501 East Middlefield Road 327 Mountain View, CA 94043 USA 328 jwz@netscape.com