idnits 2.17.1 draft-duerst-mailto-bis-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2368, but the abstract doesn't seem to directly say this. It does mention RFC2368 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o Changed some more wording from "have to" to MUST, and from SHOULD not ... to SHOULD NOT .... -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 16, 2010) is 5066 days in the past. Is this intentional? 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 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3491 (Obsoleted by RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 2368 (Obsoleted by RFC 6068) -- Obsolete informational reference (is this intentional?): RFC 4952 (Obsoleted by RFC 6530) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Duerst 3 Internet-Draft Aoyama Gakuin University 4 Obsoletes: 2368 (if approved) L. Masinter 5 Intended status: Standards Track Adobe Systems Incorporated 6 Expires: November 17, 2010 J. Zawinski 7 DNA Lounge 8 May 16, 2010 10 The 'mailto' URI Scheme 11 draft-duerst-mailto-bis-10 13 Abstract 15 This document defines the format of Uniform Resource Identifiers 16 (URI) to identify resources that are reached using Internet mail. It 17 adds better internationalization and compatibility with IRIs (RFC 18 3987) to the previous syntax of 'mailto' URIs (RFC 2368). 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on November 17, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Syntax of a 'mailto' URI . . . . . . . . . . . . . . . . . . . 4 74 3. Semantics and Operations . . . . . . . . . . . . . . . . . . . 8 75 4. Unsafe Header Fields . . . . . . . . . . . . . . . . . . . . . 8 76 5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 6.1. Basic Examples . . . . . . . . . . . . . . . . . . . . . 10 79 6.2. Examples of Complicated Email Addresses . . . . . . . . . 11 80 6.3. Examples Using UTF-8-Based Percent-Encoding . . . . . . . 11 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 8.1. Update of the Registration of the 'mailto' URI Scheme . . 14 84 8.2. Registration of the Body Header Field . . . . . . . . . . 17 85 9. Main Changes from RFC 2368 . . . . . . . . . . . . . . . . . . 17 86 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 10.1. Changes between draft 09 and draft 10 . . . . . . . . . . 18 88 10.2. Changes between draft 08 and draft 09 . . . . . . . . . . 18 89 10.3. Changes between draft 07 and draft 08 . . . . . . . . . . 19 90 10.4. Changes between draft 06 and draft 07 . . . . . . . . . . 19 91 10.5. Changes between draft 05 and draft 06 . . . . . . . . . . 20 92 10.6. Changes between draft 04 and draft 05 . . . . . . . . . . 20 93 10.7. Changes between draft 03 and draft 04 . . . . . . . . . . 20 94 10.8. Changes between draft 02 and draft 03 . . . . . . . . . . 21 95 10.9. Changes between draft 01 and draft 02 . . . . . . . . . . 21 96 10.10. Changes between draft 00 and draft 01 . . . . . . . . . . 22 97 10.11. Changes from RFC 2368 . . . . . . . . . . . . . . . . . . 22 98 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 100 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 101 12.2. Informative References . . . . . . . . . . . . . . . . . 23 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 104 1. Introduction 106 The 'mailto' URI scheme is used to identify resources that are 107 reached using Internet mail. In its simplest form, a 'mailto' URI 108 contains an Internet mail address. For interactions that require 109 message headers or message bodies to be specified, the 'mailto' URI 110 scheme also allows providing mail header fields and the message body. 112 This specification extends the previous scheme definition to also 113 allow character data to be percent-encoded based on UTF-8 [STD63], 114 which offers a better and more consistent way of dealing with non- 115 ASCII characters for internationalization. 117 This specification does not address the needs of the ongoing Email 118 Address Internationalization effort (see [RFC4952]). In particular, 119 this specification does not include syntax for fallback addresses. 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 In this document, URIs are enclosed in '<' and '>' as described in 126 Appendix C of [STD66]. Extra whitespace and line breaks are added to 127 present long URIs - they are not part of the actual URI. 129 2. Syntax of a 'mailto' URI 131 The syntax of a 'mailto' URI is described using the ABNF of [STD68], 132 non-terminal definitions from [RFC5322] (dot-atom-text, quoted- 133 string), and non-terminal definitions from [STD66] (unreserved, pct- 134 encoded): 136 mailtoURI = "mailto:" [ to ] [ hfields ] 137 to = addr-spec *("," addr-spec ) 138 hfields = "?" hfield *( "&" hfield ) 139 hfield = hfname "=" hfvalue 140 hfname = *qchar 141 hfvalue = *qchar 142 addr-spec = local-part "@" domain 143 local-part = dot-atom-text / quoted-string 144 domain = dot-atom-text / "[" *dtext-no-obs "]" 145 dtext-no-obs = %d33-90 / ; Printable US-ASCII 146 %d94-126 ; characters not including 147 ; "[", "]", or "\" 148 qchar = unreserved / pct-encoded / some-delims 149 some-delims = "!" / "$" / "'" / "(" / ")" / "*" 150 / "+" / "," / ";" / ":" / "@" 152 is a mail address as specified in [RFC5322], but 153 excluding from [RFC5322]. However, the following changes 154 apply: 156 1. A number of characters that can appear in MUST be 157 percent-encoded. These are the characters that cannot appear in 158 a URI according to [STD66] as well as "%" (because it is used for 159 percent-encoding) and all the characters in gen-delims except "@" 160 and ":" (i.e. "/", "?", "#", "[" and "]"). Of the characters in 161 sub-delims, at least the following also have to be percent- 162 encoded: "&", ";", and "=". Care has to be taken both when 163 encoding as well as when decoding to make sure these operations 164 are applied only once. 166 2. and as defined in [RFC5322] MUST NOT 167 be used. 169 3. Whitespace and comments within and MUST NOT 170 be used. They would not have any operational semantics. 172 4. Percent-encoding can be used in the part of an , in order to denote an internationalized domain name. The 174 considerations for in [STD66] apply. In particular, 175 non-ASCII characters MUST first be encoded according to UTF-8 176 [STD63], and then each octet of the corresponding UTF-8 sequence 177 MUST be percent-encoded to be represented as URI characters. URI 178 producing applications MUST NOT use percent-encoding in domain 179 names unless it is used to represent a UTF-8 character sequence. 180 When the internationalized domain name is used to compose a 181 message, the name MUST be transformed to the IDNA encoding where 182 appropriate [RFC3490]. URI producers SHOULD provide these domain 183 names in the IDNA encoding, rather than percent-encoded, if they 184 wish to maximize interoperability with legacy 'mailto' URI 185 interpreters. 187 5. Percent-encoding of non-ASCII octets in the of an 188 is reserved for the internationalization of the 189 . Non-ASCII characters MUST first be encoded 190 according to UTF-8 [STD63], and then each octet of the 191 corresponding UTF-8 sequence MUST be percent-encoded to be 192 represented as URI characters. Any other percent-encoding of 193 non-ASCII characters is prohibited. When a 194 containing non-ASCII characters will be used to compose a 195 message, the MUST be transformed to conform to 196 whatever encoding may be defined in a future specification for 197 the internationalization of email addresses. 199 and are encodings of an [RFC5322] header field 200 name and value, respectively. Percent-encoding is needed for the 201 same characters as listed above for . is case- 202 insensitive, but in general is case-sensitive. Note that 203 [RFC5322] allows all US-ASCII printable characters except ":" in 204 optional header field names (Section 3.6.8), which is the reason why 205 pct-encoded is part of the header field name production. 207 The special "body" indicates that the associated 208 is the body of the message. The "body" field value is intended to 209 contain the content for the first text/plain body part of the 210 message. The "body" pseudo header field is primarily intended for 211 the generation of short text messages for automatic processing (such 212 as "subscribe" messages for mailing lists), not for general MIME 213 bodies. Except for the encoding of characters based on UTF-8 and 214 %-encoding, no additional encoding (such as e.g. base64 or quoted- 215 printable, see [RFC2045]) is used for the "body" field value. As a 216 consequence, header fields related to message encoding (e.g. 217 Content-Transfer-Encoding) in a 'mailto' URI are irrelevant and MUST 218 be ignored. The "body" pseudo header field name has been registered 219 with IANA for this special purpose (see Section 8.2). 221 Within 'mailto' URIs, the characters "?", "=", and "&" are reserved, 222 serving as delimiters. They have to be escaped (as "%3F", "%3D", and 223 "%26", respectively) when not serving as delimiters. 225 Additional restrictions on what characters are allowed might apply 226 depending on the context where the URI is used. Such restrictions 227 can be addressed by context-specific escaping mechanisms. For 228 example, because the "&" (ampersand) character is reserved in HTML 229 and XML, any 'mailto' URI which contains an ampersand has to be 230 written with an HTML/XML entity ("&") or numeric character 231 reference ("&" or "&"). 233 Non-ASCII characters can be encoded in hfvalue as follows: 235 1. MIME encoded words (as defined in [RFC2047]) are permitted in 236 header field values, but not in an of a "body" 237 . Sequences of characters that look like MIME encoded 238 words can appear in an of a "body" , but in 239 that case have no special meaning. Please note that the '=' and 240 '?' characters used as delimiters in MIME encoded words have to 241 be percent-escaped. Also note that the use of MIME encoded words 242 differs slightly for so-called structured and unstructured header 243 fields. 245 2. Non-ASCII characters can be encoded according to UTF-8 [STD63], 246 and then each octet of the corresponding UTF-8 sequence is 247 percent-encoded to be represented as URI characters. When header 248 field values encoded in this way are used to compose a message, 249 the has to be suitably encoded (transformed into MIME 250 encoded words [RFC2047]), except for an of a "body" 251 , which has to be encoded according to [RFC2045]. Please 252 note that for MIME encoded words and for bodies in composed email 253 messages, encodings other than UTF-8 MAY be used as long as the 254 characters are properly transcoded. 256 Also note that it is syntactically valid to specify both and an 257 whose value is "to". That is, 259 261 is equivalent to 263 265 is equivalent to 267 269 However, the latter form is NOT RECOMMENDED because different user 270 agents handle this case differenty. 272 Implementations MUST NOT produce two "To:" header fields in a 273 message; the "To:" header field may occur at most once in a message 274 ([RFC5322], Section 3.6). Also, creators of 'mailto' URIs MUST NOT 275 include other message header fields multiple times if these header 276 fields can only be used once in a message. 278 Creators of 'mailto' URIs SHOULD NOT use the same multiple 279 times in the same URI to avoid interoperability problems. If the 280 same appears multiple times in a URI, behavior varies widely 281 for different user agents, and for each . Examples include 282 only using the first or last / pair, creating 283 multiple header fields, and combining each by simple 284 concatenation or in a way appropriate for the corresponding header 285 field. 287 Note that this specification, like any URI scheme specification, does 288 not define syntax or meaning of a fragment identifier (see [STD66]), 289 because these depend on the type of a retrieved representation. In 290 the currently known usage scenarios, a 'mailto' URI cannot be used to 291 retreive such representations. Therefore, fragment identifiers are 292 meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be 293 ignored upon resolution. The character "#" in hfvalues MUST be 294 escaped as %23. 296 3. Semantics and Operations 298 A 'mailto' URI designates an "internet resource", which is the 299 mailbox specified in the address. When additional header fields are 300 supplied, the resource designated is the same address, but with an 301 additional profile for accessing the resource. While there are 302 Internet resources that can only be accessed via electronic mail, the 303 'mailto' URI is not intended as a way of retrieving such objects 304 automatically. 306 The operation of how any URI scheme is resolved is not mandated by 307 the URI specifications. In current practice, resolving URIs such as 308 those in the 'http' URI scheme causes an immediate interaction 309 between client software and a host running an interactive server. 310 The 'mailto' URI has unusual semantics because resolving such a URI 311 does not cause an immediate interaction with a server. Instead, the 312 client creates a message to the designated address with the various 313 header fields set as default. The user can edit the message, send 314 the message unedited, or choose not to send the message. 316 The / pairs in a 'mailto' URI, although 317 syntactically equivalent to header fields in a mail message, do not 318 directly correspond to the header fields in a mail message. In 319 particular, the To, Cc, and Bcc s don't necessarily result 320 in a header field containing the specified value. Mail client 321 software MAY eliminate duplicate addresses. Creators of 'mailto' 322 URIs SHOULD avoid using the same address twice in a 'mailto' URI. 324 Originator fields like From and Date, fields related to routing 325 (Apparently-To, Resent-..., etc.), trace fields, and MIME header 326 fields (MIME- Version, Content-*), when present in the URI, MUST be 327 ignored. The mail client MUST create new fields when necessary as it 328 would for any new message. Unrecognized header fields, and header 329 fields with values inconsistent with those the mail client would 330 normally send SHOULD be treated as especially suspect. 332 4. Unsafe Header Fields 334 The user agent interpreting a 'mailto' URI SHOULD NOT create a 335 message if any of the header fields are considered dangerous; it MAY 336 also choose to create a message with only a subset of the header 337 fields given in the URI. Only a limited set of header fields such as 338 Subject and Keywords, as well as Body, are believed to be both safe 339 and useful in the general case. In cases where the source of a URI 340 is well known, and/or specific header fields are limited to specific 341 well-known values, other header fields MAY be considered safe, too. 343 The creator of a 'mailto' URI cannot expect the resolver of a URI to 344 understand more than the "subject" header field and "body". Clients 345 that resolve 'mailto' URIs into mail messages MUST be able to 346 correctly create [RFC5322]-compliant mail messages using the 347 "subject" header field and "body". 349 5. Encoding 351 [STD66] requires that many characters in URIs be encoded. This 352 affects the 'mailto' URI scheme for some common characters that might 353 appear in addresses, header fields, or message contents. One such 354 character is space (" ", ASCII hex 20). Note the examples below that 355 use "%20" for space in the message body. Also note that line breaks 356 in the body of a message MUST be encoded with "%0D%0A". 357 Implementations MAY add a final line break to the body of a message 358 even if there is no trailing "%0D%0A" in the body hfield of the 359 'mailto' URI. Line breaks in other hfields SHOULD NOT be used. 361 When creating 'mailto' URIs, any reserved characters that are used in 362 the URIs MUST be encoded so that properly-written URI interpreters 363 can read them. Also, client software that reads URIs MUST decode 364 strings before creating the mail message so that the mail message 365 appears in a form that the recipient software will understand. These 366 strings SHOULD be decoded before showing the message to the sending 367 user. 369 Software creating 'mailto' URIs likewise has to be careful to encode 370 any reserved characters that are used. One kind of software creating 371 'mailto' URIs are HTML forms. Current implementations encode a space 372 as '+', but this creates problems because such a '+' standing for a 373 space cannot be distinguished from a real '+' in a 'mailto' URI. 374 When producing 'mailto' URIs, all spaces SHOULD be encoded as %20, 375 and '+' characters MAY be encoded as %2B. Please note that '+' 376 characters are frequently used as part of an email address to 377 indicate a subaddress, as for example in . 379 The 'mailto' URI scheme is limited in that it does not provide for 380 substitution of variables. Thus, it is impossible to create a 381 'mailto' URI that includes a user's email address in the message 382 body. This limitation also prevents 'mailto' URIs that are signed 383 with public keys and other such variable information. 385 6. Examples 386 6.1. Basic Examples 388 A URI for an ordinary individual mailing address: 390 392 A URI for a mail response system that requires the name of the file 393 to be sent back in the subject: 395 397 A mail response system that requires a "send" request in the body: 399 401 A similar URI, with two lines with different "send" requests (in this 402 case, "send current-issue" and, on the next line, "send index"): 404 407 An interesting use of 'mailto' URIs occurs when browsing archives of 408 messages. A link can be provided that allows to reply to a message 409 and conserve threading information. This is done by adding a In- 410 Reply-To header field containing the Message-ID of the message where 411 the link is added, for example: 413 416 A request to subscribe to a mailing list: 418 420 A URI for a single user which includes a CC of another user: 422 424 Note the use of the "&" reserved character above. The following 425 example, using "?" twice, is incorrect: 427 ; WRONG! 429 According to [RFC5322], the characters "?", "&", and even "%" may 430 occur in addr-specs. The fact that they are reserved characters is 431 not a problem: those characters may appear in 'mailto' URIs, they 432 just may not appear in unencoded form. The standard URI encoding 433 mechanisms ("%" followed by a two-digit hex number) MUST be used in 434 these cases. 436 To indicate the address "gorby%kremvax@example.com" one would use: 438 440 To indicate the address "unlikely?address@example.com", and include 441 another header field, one would use: 443 445 As described above, the "&" (ampersand) character is reserved in HTML 446 and has to be replaced e.g. with "&". Thus, a URI with an 447 internal ampersand might look like: 449 Click mailto:joe@an.example?cc=bob@an.example&body=hello to send a 452 greeting message to Joe and Bob. 454 When an email address itself includes an "&" (ampersand) character, 455 that character has to be percent-escaped. For example, the 'mailto' 456 URI to send mail to "Mike&family@example.org" is 457 . 459 6.2. Examples of Complicated Email Addresses 461 Following are a few examples of how to treat email addresses that 462 contain complicated escaping syntax. 464 Email address: "not@me"@example.org; corresponding 'mailto' URI: 466 . 468 Email address: "oh\\no"@example.org; corresponding 'mailto' URI: 470 . 472 Email address: "\\\"it's\ ugly\\\""@example.org; corresponding 473 'mailto' URI: 475 . 477 6.3. Examples Using UTF-8-Based Percent-Encoding 479 Sending a mail with the subject "coffee" in French, i.e. "cafe" where 480 the final e is an e-acute, using UTF-8 and percent-encoding: 482 484 The same subject, this time using an encoded-word (escaping the "=" 485 and "?" characters used in the encoded-word syntax, because they are 486 reserved): 488 491 The same subject, this time encoded as iso-8859-1: 493 496 Going back to straight UTF-8 and adding a body with the same value: 498 500 This 'mailto' URI may result in a message looking like this: 502 From: sender@example.net 503 To: user@example.org 504 Subject: =?utf-8?Q?caf=C3=A9?= 505 Content-Type: text/plain;charset=utf-8 506 Content-Transfer-Encoding: quoted-printable 508 caf=C3=A9 510 The software sending the email is not restricted to UTF-8, but can 511 use other encodings. The following shows the same email using iso- 512 8859-1 two times: 514 From: sender@example.net 515 To: user@example.org 516 Subject: =?iso-8859-1?Q?caf=E9?= 517 Content-Type: text/plain;charset=iso-8859-1 518 Content-Transfer-Encoding: quoted-printable 520 caf=E9 522 Different content transfer encodings (i.e. "8bit" or "base64" instead 523 of "quoted-printable") and different encodings in encoded words (i.e. 524 "B" instead of "Q") can also be used. 526 For more examples of encoding the word coffee in different languages, 527 see [RFC2324]. 529 The following example uses the Japanese word "natto" (Unicode 530 characters U+7D0D U+8C46) as a domain name label, sending a mail to a 531 user at "natto".example.org: 533 535 When constructing the email, the domain name label is converted to 536 punycode. The resulting message may look as follows: 538 From: sender@example.net 539 To: user@xn--99zt52a.example.org 540 Subject: Test 541 Content-Type: text/plain 542 Content-Transfer-Encoding: 7bit 544 NATTO 546 7. Security Considerations 548 The 'mailto' URI scheme can be used to send a message from one user 549 to another, and thus can introduce many security concerns. Mail 550 messages can be logged at the originating site, the recipient site, 551 and intermediary sites along the delivery path. If the messages are 552 not encrypted, they can also be read at any of those sites. 554 A 'mailto' URI gives a template for a message that can be sent by 555 mail client software. The contents of that template may be opaque or 556 difficult to read by the user at the time of specifying the URI, as 557 well as being hidden in UI (for example a link on an HTML web page 558 might display something other than the content of the corresponding 559 'mailto' URI that would be used when clicked). Thus, a mail client 560 SHOULD NOT send a message based on a 'mailto' URI without first 561 disclosing and showing to the user the full message that will be sent 562 (including all header fields that were specified by the 'mailto' 563 URI), fully decoded, and asking the user for approval to send the 564 message as electronic mail. The mail client SHOULD also make it 565 clear that the user is about to send an electronic mail message, 566 since the user may not be aware that this is the result of a 'mailto' 567 URI. 569 Some header fields are inherently unsafe to include in a message 570 generated from a URI. For details, please see Section 3. In 571 general, the fewer header fields interpreted from the URI, the less 572 likely it is that a sending agent will create an unsafe message. 574 Examples of problems with sending unapproved mail include: 576 mail that breaks laws upon delivery, such as making illegal 577 threats; 579 mail that identifies the sender as someone interested in breaking 580 laws; 582 mail that identifies the sender to an unwanted third party; 584 mail that causes a financial charge to be incurred by the sender; 586 mail that causes an action on the recipient machine that causes 587 damage that might be attributed to the sender. 589 Programs that interpret 'mailto' URIs SHOULD ensure that the SMTP 590 envelope return path address, which is given as an argument to the 591 SMTP MAIL FROM command, is set and correct, and that the resulting 592 email is a complete, workable message. 594 'mailto' URIs on public Web pages expose mail addresses for 595 harvesting. This applies to all mail addresses that are part of the 596 'mailto' URI, including the addresses in a "bcc" hfvalue. Those 597 addresses will not be sent to the recipients in the 'to' field and in 598 the "to" and "cc" hfvalues, but will still be publicly visible in the 599 URI. Addresses in a "bcc" hfvalue may also leak to other addresses 600 in the same hfvalue or become known otherwise depending on the mail 601 user agent used. 603 Programs manipulating 'mailto' URIs SHOULD take great care to not 604 inadvertedly double-escape or double-unescape 'mailto' URIs, and to 605 make sure that escaping and unescaping conventions relating to URIs 606 and relating to mail addresses are applied in the right order. 608 Implementations parsing 'mailto' URIs must take care to sanity check 609 'mailto' URIs in order to avoid buffer overflows and problems 610 resulting from them (e.g. execution of code specified by the 611 attacker). 613 The security considerations of [STD66], [RFC3490], [RFC3491], and 614 [RFC3987] also apply. Implementers and users are advised to check 615 them carefully. 617 8. IANA Considerations 619 8.1. Update of the Registration of the 'mailto' URI Scheme 620 This document changes the definition of the 'mailto' URI scheme; the 621 registry of URI schemes needs to be updated to refer to this document 622 rather than its predecessor, [RFC2368]. The registration template is 623 as follows: 625 URI scheme name: 626 'mailto' 628 Status: 629 permanent 631 URI scheme syntax: 632 See the syntax section of draft-duerst-mailto-bis-10.txt. 633 (Note to RFC Editor and IANA: Replace this with 634 RFC YYYY (RFC number of this specification)). 636 URI scheme semantics: 637 See the semantics section of draft-duerst-mailto-bis-10.txt. 638 (Note to RFC Editor and IANA: Replace this with 639 RFC YYYY (RFC number of this specification)). 641 Encoding considerations: 642 See the syntax and encoding sections of 643 draft-duerst-mailto-bis-10.txt. 644 (Note to RFC Editor and IANA: Replace this with 645 RFC YYYY (RFC number of this specification)). 647 Applications/protocols that use this URI scheme name: 648 The 'mailto' URI scheme is widely used since the start of the Web. 650 Interoperability considerations: 651 Interoperability for 'mailto' URIs with UTF-8-based percent-encoding 652 might be somewhat lower than interoperability for 'mailto' URIs with 653 US-ASCII only. 655 Security considerations: 656 See the security section of draft-duerst-mailto-bis-10.txt. 657 (Note to RFC Editor and IANA: Replace this with 658 RFC YYYY (RFC number of this specification)). 660 Contact: 661 IETF 663 Author/Change controller: 664 IETF 666 References: 667 Internet-Draft draft-duerst-mailto-bis-10.txt 668 (Note to RFC Editor and IANA: Replace this with 669 RFC YYYY (RFC number of this specification)) 671 8.2. Registration of the Body Header Field 673 IANA is herewith requested to register the Body header field in the 674 Message Header Fields Registry ([RFC3864]) as follows: 676 Header field name: 677 Body 679 Applicable protocol: 680 None. This registration is made to assure that this header field 681 name is not used at all, in order to not create any problems 682 for 'mailto' URIs. 684 Status: 685 reserved 687 Author/Change controller: 688 IETF 690 Specification document(s): 691 Internet-Draft draft-duerst-mailto-bis-10.txt 692 (Note to RFC Editor and IANA: Replace this with 693 RFC YYYY (RFC number of this specification)) 695 Related information: 696 none 698 9. Main Changes from RFC 2368 700 The main changes from RFC 2368 are as follows: 702 o Changed syntax from RFC 2822 to [RFC5322] . 704 o Allowed UTF-8-based percent-encoding for domain names and in 705 . 707 o Nailed down percent-encoding in to be based on UTF-8, 708 reserved for future use. 710 o Removed prohibition against "Bcc:" header fields, but added a 711 warning about their visibility and harvesting for spam. 713 o Added clarifications for escaping. 715 10. Change Log 717 Note to RFC Editor: Please completely remove this section before 718 publication. 720 10.1. Changes between draft 09 and draft 10 722 o Changed 'encoded' to 'encrypted' in security section. 724 o Added a warning about buffer overflows to security section. 726 o Added a warning about potential differences between display and 727 underlying URI, e.g. in HTML links, to security section. 729 o Changed subsection title from "Examples Conforming to RFC 2368" to 730 "Basic Examples". 732 o Various minor textual fixes. 734 o Added several more commenters to the Acknowledgments section. 736 10.2. Changes between draft 08 and draft 09 738 o Removed a superfluous level of optionality in ABNF. 740 o In , allowed domain literals back in (excluding spaces). 742 o Clarified that content of body pseudo-header is (apart from URI/ 743 IRI encoding) is raw text, independent of potential other header 744 fields such as Content-Transfer-Encoding, and that such other 745 header fields should be ignored. 747 o Allowed a final line break to be added to body when interpreting 748 'mailto' URI. Said that line breaks should not be used in other 749 header fields. 751 o Slightly reworded explanation of escaping '&' in XML/HTML. 753 o Cleaned up and strengthened wording about dangerous/inappropriate/ 754 unknown headers in Security section. 756 o Moved text about what to do with which kind of headers from 757 Security section to Semantics section, with a pointer. Clarified 758 that there may be no direct correspondence between hfields in the 759 URI and headers in the mail message. 761 o Clarified that there are some MUA implementation variations for 762 Bcc. 764 o Pointed out the issue about structured vs. unstructured headers 765 for MIME encoded words. 767 10.3. Changes between draft 07 and draft 08 769 o Changed mail production used from dot-atom to dot-atom-text (i.e. 770 eliminated whitespace). 772 o Changed some more wording from "have to" to MUST, and from SHOULD 773 not ... to SHOULD NOT .... 775 o Changed "%2C" to "," in syntax of field and simplified two 776 examples. 778 o Mentioned frequent use of '+' in subadresses. 780 o Added some text about care with escaping and unescaping to 781 security section. 783 o Various textual clarifications and fixes. 785 o Tweaked RFC 2119 boilerplate to match exactly (removes a complaint 786 from idnits tool). 788 10.4. Changes between draft 06 and draft 07 790 o Changed production for 'domain' from externally defined (dot-atom 791 / domain-literal / obs-domain in [RFC5322]) to dot-atom only. 792 This clarifies that obsolete [RFC5322] syntax and comments are 793 disallowed. 795 o Capitalized various "must" and "should", and/or changed wording to 796 more clearly distinguish spec requirements and other text. 798 o Added explanation about "the characters "?", "=", and "&" are 799 reserved". 801 o Removed text about not mixing MIME encoded words and percent- 802 encoding. 804 o Added text to say that '=' and '?' in MIME encoded words have to 805 be percent-encoded. 807 o Added registration template for 'mailto' scheme itself. 809 o Made requirement for [RFC2047]RFC 2047 in email headers less 810 strong (not necessary for EAI). 812 o Removed (extremly short) section on deployment with a notice in 813 registration template. 815 o Changed 'legal' to 'syntactically valid' when not referring to the 816 law. 818 o Added ":" to the exceptions from escaping in gen-delims. 820 10.5. Changes between draft 05 and draft 06 822 o Fixed references ([RFC5322]). 824 o Changed IPR text to pre5378Trust200902. 826 10.6. Changes between draft 04 and draft 05 828 o Added "Main Changes from RFC 2368" to help implementation updates 829 from RFC 2368. 831 o Added a warning about spam harvesting and visibility of bcc 832 addresses. 834 o Clarified that does not include comments. 836 o Changed names of syntax productions to be better in line with 837 standard terminology: headers -> hfields, header -> hfield, hname 838 -> hfname, hvalue -> hfvalue. 840 o Streamlined terminology: mailto, mailto: -> 'mailto'; LHS -> 841 ; consistently used '<' and '>' for ABNF production 842 names. 844 o Changed section heading from "Unsafe Headers" to "Unsafe Header 845 Fields". 847 o Got rid of references and the word 'update' in the Abstract. 849 o Updated ABNF reference to [STD68] 851 o Some minor wording cleanup. 853 10.7. Changes between draft 03 and draft 04 855 o Added mention of internationalization (not just IRI) to abstract. 857 o Updated reference from draft-ietf-eai-framework to RFC 4952, 858 simplified referring text. 860 o Used MUST for resolvers to understand Subject and Body for clear 861 interoperability. 863 o Noted that multiple identical hnames can cause interoperability 864 problems and SHOULD be avoided. 866 o Note the problem of '+' produced by HTML forms, made clear that 867 %20 SHOULD be used for encoding spaces. 869 o Removed warning against using bcc; doesn't seem to be of any harm 870 if user checks explicitly. 872 o Some minor wording cleanup. 874 10.8. Changes between draft 02 and draft 03 876 o Adjusted description of mailto URI in abstract to match intro. 878 o Added registration template for body header field. 880 o Clarified requirements for produced email message. 882 o Clarified case (in)sensitivity of header field names and values. 884 o Introduced reference to EAI-framework, explained to what extent it 885 has been taken into account. 887 o Changed reference label from RFC3986 to STD66. 889 10.9. Changes between draft 01 and draft 02 891 o Fixed phone/fax for Martin. 893 o Changed examples to reduce cases with both a 'to' field and a 'to' 894 hname. 896 o Fixed syntax to not rely on non-terminals from RFC 2396. Changed 897 description of set of characters that needs to be escaped. 899 o Mollified warning about header fields other than Subject, 900 Keywords, and Body. 902 o Clarified prohibition of mixing different encodings (%-escaping 903 and Mime encoded words) for header fields. 905 o Improved some examples. Fixed some terminology. 907 10.10. Changes between draft 00 and draft 01 909 o Added clarification about permitted syntax and escaping on email 910 address LHS, and more complicated examples. 912 o Added text about more safe headers in case origin or mailto URIs 913 is known. 915 o Fixed date of [STD66] 917 o Added a sentence referencing [RFC2119] 919 o Added Jamie back in as a co-author. Changed address/affiliation 920 for Martin. 922 10.11. Changes from RFC 2368 924 o For interoperability with IRIs ([RFC3987]), allowed percent- 925 encoding, fixed to UTF-8, in the domain name part of an email 926 address, in LHS part of an address (currently reserved because not 927 operationally usable), and in hvalue parts. 929 o Changed from 'URL' to 'URI' 931 o Updated references: ABNF to [STD68]; message syntax to [RFC5322], 932 URI Generic Syntax to [STD66] 934 o Expanded "#mailbox", because the "#" shortcut is no longer 935 available; needs checking 937 11. Acknowledgments 939 This document was derived from [RFC2368]; the acknowledgments from 940 that specification still apply. In addition, we thank Paul Hoffman 941 for his work on [RFC2368]. 943 Valuable input on this document was received from (in no particular 944 order): Alexey Melnikov, Paul Hoffman, Charles Lindsey, Tim Kindberg, 945 Frank Ellermann, Etan Wexler, Michael Haardt, Michael Anthony Puls 946 II, Eliot Lear, Dave Crocker, Dan Harkins, Nevil Brownlee, John 947 Klensin, Alfred Hoenes, Ned Freed, Sean Turner, Peter Saint-Andre, 948 Adrian Farrel, Avshalom Houri, Robert Sparks, and many others. 950 12. References 951 12.1. Normative References 953 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 954 Extensions (MIME) Part One: Format of Internet Message 955 Bodies", November 1996. 957 [RFC2047] Moore, K., "MIME Part Three: Message Header Extensions for 958 Non-ASCII Text", RFC 2047, November 1996. 960 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 961 Requirement Levels", BCP 14, RFC 2119, March 1997. 963 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 964 "Internationalizing Domain Names in Applications (IDNA)", 965 RFC 3490, March 2003. 967 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 968 Profile for Internationalized Domain Names (IDN)", 969 RFC 3491, March 2003. 971 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 972 Procedures for Message Header Fields", RFC 3864, BCP 90, 973 September 2004. 975 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 976 Identifiers (IRIs)", RFC 3987, January 2005. 978 [RFC5322] Resnik, P., "Internet Message Format", RFC 5322, 979 October 2008. 981 [STD63] Yergeau, F., "UTF-8, a transformation format of ISO 982 10646", STD 63, RFC 3629, November 2003. 984 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 985 Resource Identifier (URI): Generic Syntax", STD 66, 986 RFC 3986, January 2005. 988 [STD68] Crocker, D. and P. Overell, "Augmented BNF for Syntax 989 Specifications: ABNF", STD 68, RFC 5234, January 2008. 991 12.2. Informative References 993 [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol 994 (HTCPCP/1.0)", RFC 2324, April 1998. 996 [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto 997 URL scheme", RFC 2368, July 1998. 999 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 1000 Internationalized Email", RFC 4952, July 2007. 1002 Authors' Addresses 1004 Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever 1005 possible, for example as "Dürst" in XML and HTML.) 1006 Aoyama Gakuin University 1007 5-10-1 Fuchinobe 1008 Sagamihara, Kanagawa 229-8558 1009 Japan 1011 Phone: +81 42 759 6329 1012 Fax: +81 42 759 6495 1013 Email: duerst@it.aoyama.ac.jp 1014 URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/ 1016 Larry Masinter 1017 Adobe Systems Incorporated 1018 345 Park Ave 1019 San Jose, CA 95110 1020 USA 1022 Phone: +1-408-536-3024 1023 Email: LMM@acm.org 1024 URI: http://larry.masinter.net/ 1026 Jamie Zawinski 1027 DNA Lounge 1028 375 Eleventh Street 1029 San Francisco, CA 94103 1030 USA 1032 Email: jwz@jwz.org