7Internet Engineering Task Force (IETF) M. Duerst
8Request for Comments: 6068 Aoyama Gakuin University
9Obsoletes: 2368 L. Masinter
10Category: Standards Track Adobe Systems Incorporated
11ISSN: 2070-1721 J. Zawinski
16 The 'mailto' URI Scheme
20 This document defines the format of Uniform Resource Identifiers
21 (URIs) to identify resources that are reached using Internet mail.
22 It adds better internationalization and compatibility with
23 Internationalized Resource Identifiers (IRIs; RFC 3987) to the
24 previous syntax of 'mailto' URIs (RFC 2368).
28 This is an Internet Standards Track document.
30 This document is a product of the Internet Engineering Task Force
31 (IETF). It represents the consensus of the IETF community. It has
32 received public review and has been approved for publication by the
33 Internet Engineering Steering Group (IESG). Further information on
34 Internet Standards is available in Section 2 of RFC 5741.
36 Information about the current status of this document, any errata,
37 and how to provide feedback on it may be obtained at
38 http://www.rfc-editor.org/info/rfc6068.
58Duerst, et al. Standards Track [Page 1]
60RFC 6068 The 'mailto' URI Scheme October 2010
65 Copyright (c) 2010 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
78 This document may contain material from IETF Documents or IETF
79 Contributions published or made publicly available before November
80 10, 2008. The person(s) controlling the copyright in some of this
81 material may not have granted the IETF Trust the right to allow
82 modifications of such material outside the IETF Standards Process.
83 Without obtaining an adequate license from the person(s) controlling
84 the copyright in such materials, this document may not be modified
85 outside the IETF Standards Process, and derivative works of it may
86 not be created outside the IETF Standards Process, except to format
87 it for publication as an RFC or to translate it into languages other
92 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
93 2. Syntax of a 'mailto' URI . . . . . . . . . . . . . . . . . . . 3
94 3. Semantics and Operations . . . . . . . . . . . . . . . . . . . 7
95 4. Unsafe Header Fields . . . . . . . . . . . . . . . . . . . . . 7
96 5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
97 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
98 6.1. Basic Examples . . . . . . . . . . . . . . . . . . . . . . 9
99 6.2. Examples of Complicated Email Addresses . . . . . . . . . 10
100 6.3. Examples Using UTF-8-Based Percent-Encoding . . . . . . . 11
101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
103 8.1. Update of the Registration of the 'mailto' URI Scheme . . 14
104 8.2. Registration of the Body Header Field . . . . . . . . . . 15
105 9. Main Changes from RFC 2368 . . . . . . . . . . . . . . . . . . 15
106 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
108 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
109 11.2. Informative References . . . . . . . . . . . . . . . . . . 17
114Duerst, et al. Standards Track [Page 2]
116RFC 6068 The 'mailto' URI Scheme October 2010
121 The 'mailto' URI scheme is used to identify resources that are
122 reached using Internet mail. In its simplest form, a 'mailto' URI
123 contains an Internet mail address. For interactions that require
124 message headers or message bodies to be specified, the 'mailto' URI
125 scheme also allows providing mail header fields and the message body.
127 This specification extends the previous scheme definition to also
128 allow character data to be percent-encoded based on UTF-8 [STD63],
129 which offers a better and more consistent way of dealing with non-
130 ASCII characters for internationalization.
132 This specification does not address the needs of the ongoing Email
133 Address Internationalization effort (see [RFC4952]). In particular,
134 this specification does not include syntax for fallback addresses.
136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
138 document are to be interpreted as described in [RFC2119].
140 In this document, URIs are enclosed in '<' and '>' as described in
141 Appendix C of [STD66]. Extra whitespace and line breaks are added to
142 present long URIs -- they are not part of the actual URI.
1442. Syntax of a 'mailto' URI
146 The syntax of a 'mailto' URI is described using the ABNF of [STD68],
147 non-terminal definitions from [RFC5322] (dot-atom-text, quoted-
148 string), and non-terminal definitions from [STD66] (unreserved, pct-
151 mailtoURI = "mailto:" [ to ] [ hfields ]
152 to = addr-spec *("," addr-spec )
153 hfields = "?" hfield *( "&" hfield )
154 hfield = hfname "=" hfvalue
157 addr-spec = local-part "@" domain
158 local-part = dot-atom-text / quoted-string
159 domain = dot-atom-text / "[" *dtext-no-obs "]"
160 dtext-no-obs = %d33-90 / ; Printable US-ASCII
161 %d94-126 ; characters not including
163 qchar = unreserved / pct-encoded / some-delims
164 some-delims = "!" / "$" / "'" / "(" / ")" / "*"
165 / "+" / "," / ";" / ":" / "@"
170Duerst, et al. Standards Track [Page 3]
172RFC 6068 The 'mailto' URI Scheme October 2010
175 <addr-spec> is a mail address as specified in [RFC5322], but
176 excluding <comment> from [RFC5322]. However, the following changes
179 1. A number of characters that can appear in <addr-spec> MUST be
180 percent-encoded. These are the characters that cannot appear in
181 a URI according to [STD66] as well as "%" (because it is used for
182 percent-encoding) and all the characters in gen-delims except "@"
183 and ":" (i.e., "/", "?", "#", "[", and "]"). Of the characters
184 in sub-delims, at least the following also have to be percent-
185 encoded: "&", ";", and "=". Care has to be taken both when
186 encoding as well as when decoding to make sure these operations
187 are applied only once.
189 2. <obs-local-part> and <NO-WS-CTL> as defined in [RFC5322] MUST NOT
192 3. Whitespace and comments within <local-part> and <domain> MUST NOT
193 be used. They would not have any operational semantics.
195 4. Percent-encoding can be used in the <domain> part of an
196 <addr-spec> in order to denote an internationalized domain name.
197 The considerations for <reg-name> in [STD66] apply. In
198 particular, non-ASCII characters MUST first be encoded according
199 to UTF-8 [STD63], and then each octet of the corresponding UTF-8
200 sequence MUST be percent-encoded to be represented as URI
201 characters. URI-producing applications MUST NOT use
202 percent-encoding in domain names unless it is used to represent a
203 UTF-8 character sequence. When the internationalized domain name
204 is used to compose a message, the name MUST be transformed to the
205 Internationalizing Domain Names in Applications (IDNA) encoding
206 [RFC5891] where appropriate. URI producers SHOULD provide these
207 domain names in the IDNA encoding, rather than percent-encoded,
208 if they wish to maximize interoperability with legacy 'mailto'
211 5. Percent-encoding of non-ASCII octets in the <local-part> of an
212 <addr-spec> is reserved for the internationalization of the
213 <local-part>. Non-ASCII characters MUST first be encoded
214 according to UTF-8 [STD63], and then each octet of the
215 corresponding UTF-8 sequence MUST be percent-encoded to be
216 represented as URI characters. Any other percent-encoding of
217 non-ASCII characters is prohibited. When a <local-part>
218 containing non-ASCII characters will be used to compose a
219 message, the <local-part> MUST be transformed to conform to
220 whatever encoding may be defined in a future specification for
221 the internationalization of email addresses.
226Duerst, et al. Standards Track [Page 4]
228RFC 6068 The 'mailto' URI Scheme October 2010
231 <hfname> and <hfvalue> are encodings of an [RFC5322] header field
232 name and value, respectively. Percent-encoding is needed for the
233 same characters as listed above for <addr-spec>. <hfname> is case-
234 insensitive, but <hfvalue> in general is case-sensitive. Note that
235 [RFC5322] allows all US-ASCII printable characters except ":" in
236 optional header field names (Section 3.6.8), which is the reason why
237 <pct-encoded> is part of the header field name production.
239 The special <hfname> "body" indicates that the associated <hfvalue>
240 is the body of the message. The "body" field value is intended to
241 contain the content for the first text/plain body part of the
242 message. The "body" pseudo header field is primarily intended for
243 the generation of short text messages for automatic processing (such
244 as "subscribe" messages for mailing lists), not for general MIME
245 bodies. Except for the encoding of characters based on UTF-8 and
246 percent-encoding, no additional encoding (such as e.g., base64 or
247 quoted-printable; see [RFC2045]) is used for the "body" field value.
248 As a consequence, header fields related to message encoding (e.g.,
249 Content-Transfer-Encoding) in a 'mailto' URI are irrelevant and MUST
250 be ignored. The "body" pseudo header field name has been registered
251 with IANA for this special purpose (see Section 8.2).
253 Within 'mailto' URIs, the characters "?", "=", and "&" are reserved,
254 serving as delimiters. They have to be escaped (as "%3F", "%3D", and
255 "%26", respectively) when not serving as delimiters.
257 Additional restrictions on what characters are allowed might apply
258 depending on the context where the URI is used. Such restrictions
259 can be addressed by context-specific escaping mechanisms. For
260 example, because the "&" (ampersand) character is reserved in HTML
261 and XML, any 'mailto' URI that contains an ampersand has to be
262 written with an HTML/XML entity ("&") or numeric character
263 reference ("&" or "&").
265 Non-ASCII characters can be encoded in <hfvalue> as follows:
267 1. MIME encoded words (as defined in [RFC2047]) are permitted in
268 header field values, but not in an <hfvalue> of a "body"
269 <hfname>. Sequences of characters that look like MIME encoded
270 words can appear in an <hfvalue> of a "body" <hfname>, but in
271 that case have no special meaning. Please note that the '=' and
272 '?' characters used as delimiters in MIME encoded words have to
273 be percent-encoded. Also note that the use of MIME encoded words
274 differs slightly for so-called structured and unstructured header
282Duerst, et al. Standards Track [Page 5]
284RFC 6068 The 'mailto' URI Scheme October 2010
287 2. Non-ASCII characters can be encoded according to UTF-8 [STD63],
288 and then each octet of the corresponding UTF-8 sequence is
289 percent-encoded to be represented as URI characters. When header
290 field values encoded in this way are used to compose a message,
291 the <hfvalue> has to be suitably encoded (transformed into MIME
292 encoded words [RFC2047]), except for an <hfvalue> of a "body"
293 <hfname>, which has to be encoded according to [RFC2045]. Please
294 note that for MIME encoded words and for bodies in composed email
295 messages, encodings other than UTF-8 MAY be used as long as the
296 characters are properly transcoded.
298 Also note that it is syntactically valid to specify both <to> and an
299 <hfname> whose value is "to". That is,
301 <mailto:addr1@an.example,addr2@an.example>
305 <mailto:?to=addr1@an.example,addr2@an.example>
309 <mailto:addr1@an.example?to=addr2@an.example>
311 However, the latter form is NOT RECOMMENDED because different user
312 agents handle this case differently. In particular, some existing
313 clients ignore "to" <hfvalue>s.
315 Implementations MUST NOT produce two "To:" header fields in a
316 message; the "To:" header field may occur at most once in a message
317 ([RFC5322], Section 3.6). Also, creators of 'mailto' URIs MUST NOT
318 include other message header fields multiple times if these header
319 fields can only be used once in a message.
321 To avoid interoperability problems, creators of 'mailto' URIs SHOULD
322 NOT use the same <hfname> multiple times in the same URI. If the
323 same <hfname> appears multiple times in a URI, behavior varies widely
324 for different user agents, and for each <hfname>. Examples include
325 using only the first or last <hfname>/<hfvalue> pair, creating
326 multiple header fields, and combining each <hfvalue> by simple
327 concatenation or in a way appropriate for the corresponding header
330 Note that this specification, like any URI scheme specification, does
331 not define syntax or meaning of a fragment identifier (see [STD66]),
332 because these depend on the type of a retrieved representation. In
333 the currently known usage scenarios, a 'mailto' URI cannot be used to
334 retrieve such representations. Therefore, fragment identifiers are
338Duerst, et al. Standards Track [Page 6]
340RFC 6068 The 'mailto' URI Scheme October 2010
343 meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be
344 ignored upon resolution. The character "#" in <hfvalue>s MUST be
3473. Semantics and Operations
349 A 'mailto' URI designates an "Internet resource", which is the
350 mailbox specified in the address. When additional header fields are
351 supplied, the resource designated is the same address but with an
352 additional profile for accessing the resource. While there are
353 Internet resources that can only be accessed via electronic mail, the
354 'mailto' URI is not intended as a way of retrieving such objects
357 The operation of how any URI scheme is resolved is not mandated by
358 the URI specifications. In current practice, resolving URIs such as
359 those in the 'http' URI scheme causes an immediate interaction
360 between client software and a host running an interactive server.
361 The 'mailto' URI has unusual semantics because resolving such a URI
362 does not cause an immediate interaction with a server. Instead, the
363 client creates a message to the designated address with the various
364 header fields set as default. The user can edit the message, send
365 the message unedited, or choose not to send the message.
367 The <hfname>/<hfvalue> pairs in a 'mailto' URI, although
368 syntactically equivalent to header fields in a mail message, do not
369 directly correspond to the header fields in a mail message. In
370 particular, the To, Cc, and Bcc <hfvalue>s don't necessarily result
371 in a header field containing the specified value. Mail client
372 software MAY eliminate duplicate addresses. Creators of 'mailto'
373 URIs SHOULD avoid using the same address twice in a 'mailto' URI.
375 Originator fields like From and Date, fields related to routing
376 (Apparently-To, Resent-*, etc.), trace fields, and MIME header fields
377 (MIME-Version, Content-*), when present in the URI, MUST be ignored.
378 The mail client MUST create new fields when necessary, as it would
379 for any new message. Unrecognized header fields and header fields
380 with values inconsistent with those the mail client would normally
381 send SHOULD be treated as especially suspect. For example, there may
382 be header fields that are totally safe but not known to the MUA, so
383 the MUA MAY choose to show them to the user.
3854. Unsafe Header Fields
387 The user agent interpreting a 'mailto' URI SHOULD NOT create a
388 message if any of the header fields are considered dangerous; it MAY
389 also choose to create a message with only a subset of the header
390 fields given in the URI. Only a limited set of header fields such as
394Duerst, et al. Standards Track [Page 7]
396RFC 6068 The 'mailto' URI Scheme October 2010
399 Subject and Keywords, as well as Body, are believed to be both safe
400 and useful in the general case. In cases where the source of a URI
401 is well known, and/or specific header fields are limited to specific
402 well-known values, other header fields MAY be considered safe, too.
404 The creator of a 'mailto' URI cannot expect the resolver of a URI to
405 understand more than the "subject" header field and "body". Clients
406 that resolve 'mailto' URIs into mail messages MUST be able to
407 correctly create [RFC5322]-compliant mail messages using the
408 "subject" header field and "body".
412 [STD66] requires that many characters in URIs be encoded. This
413 affects the 'mailto' URI scheme for some common characters that might
414 appear in addresses, header fields, or message contents. One such
415 character is space (" ", ASCII hex 20). Note the examples below that
416 use "%20" for space in the message body. Also note that line breaks
417 in the body of a message MUST be encoded with "%0D%0A".
418 Implementations MAY add a final line break to the body of a message
419 even if there is no trailing "%0D%0A" in the body <hfield> of the
420 'mailto' URI. Line breaks in other <hfield>s SHOULD NOT be used.
422 When creating 'mailto' URIs, any reserved characters that are used in
423 the URIs MUST be encoded so that properly written URI interpreters
424 can read them. Also, client software that reads URIs MUST decode
425 strings before creating the mail message so that the mail message
426 appears in a form that the recipient software will understand. These
427 strings SHOULD be decoded before showing the message to the sending
430 Software creating 'mailto' URIs likewise has to be careful to encode
431 any reserved characters that are used. HTML forms are one kind of
432 software that creates 'mailto' URIs. Current implementations encode
433 a space as '+', but this creates problems because such a '+' standing
434 for a space cannot be distinguished from a real '+' in a 'mailto'
435 URI. When producing 'mailto' URIs, all spaces SHOULD be encoded as
436 %20, and '+' characters MAY be encoded as %2B. Please note that '+'
437 characters are frequently used as part of an email address to
438 indicate a subaddress, as for example in <bill+ietf@example.org>.
440 The 'mailto' URI scheme is limited in that it does not provide for
441 substitution of variables. Thus, it is impossible to create a
442 'mailto' URI that includes a user's email address in the message
443 body. This limitation also prevents 'mailto' URIs that are signed
444 with public keys and other such variable information.
450Duerst, et al. Standards Track [Page 8]
452RFC 6068 The 'mailto' URI Scheme October 2010
459 A URI for an ordinary individual mailing address:
461 <mailto:chris@example.com>
463 A URI for a mail response system that requires the name of the file
464 to be sent back in the subject:
466 <mailto:infobot@example.com?subject=current-issue>
468 A mail response system that requires a "send" request in the body:
470 <mailto:infobot@example.com?body=send%20current-issue>
472 A similar URI, with two lines with different "send" requests (in this
473 case, "send current-issue" and, on the next line, "send index"):
476 example.com?body=send%20current-issue%0D%0Asend%20index>
478 An interesting use of 'mailto' URIs occurs when browsing archives of
479 messages. A link can be provided that allows replying to a message
480 and conserving threading information. This is done by adding an
481 In-Reply-To header field containing the Message-ID of the message
482 where the link is added, for example:
484 <mailto:list@example.org?In-Reply-To=%3C3469A91.D10AF4C@
487 A request to subscribe to a mailing list:
489 <mailto:majordomo@example.com?body=subscribe%20bamboo-l>
491 A URI that is for a single user and that includes a CC of another
494 <mailto:joe@example.com?cc=bob@example.com&body=hello>
496 Note the use of the "&" reserved character above. The following
497 example, using "?" twice, is incorrect:
499 <mailto:joe@example.com?cc=bob@example.com?body=hello> ; WRONG!
506Duerst, et al. Standards Track [Page 9]
508RFC 6068 The 'mailto' URI Scheme October 2010
511 According to [RFC5322], the characters "?", "&", and even "%" may
512 occur in addr-specs. The fact that they are reserved characters is
513 not a problem: those characters may appear in 'mailto' URIs -- they
514 just may not appear in unencoded form. The standard URI encoding
515 mechanisms ("%" followed by a two-digit hex number) MUST be used in
518 To indicate the address "gorby%kremvax@example.com" one would use:
520 <mailto:gorby%25kremvax@example.com>
522 To indicate the address "unlikely?address@example.com", and include
523 another header field, one would use:
525 <mailto:unlikely%3Faddress@example.com?blat=foop>
527 As described above, the "&" (ampersand) character is reserved in HTML
528 and has to be replaced, e.g., with "&". Thus, a URI with an
529 internal ampersand might look like:
532 <a href="mailto:joe@an.example?cc=bob@an.example&body=hello"
533 >mailto:joe@an.example?cc=bob@an.example&body=hello</a> to send a
534 greeting message to Joe and Bob.
536 When an email address itself includes an "&" (ampersand) character,
537 that character has to be percent-encoded. For example, the 'mailto'
538 URI to send mail to "Mike&family@example.org" is
539 <mailto:Mike%26family@example.org>.
5416.2. Examples of Complicated Email Addresses
543 Following are a few examples of how to treat email addresses that
544 contain complicated escaping syntax.
546 Email address: "not@me"@example.org; corresponding 'mailto' URI:
548 <mailto:%22not%40me%22@example.org>.
550 Email address: "oh\\no"@example.org; corresponding 'mailto' URI:
552 <mailto:%22oh%5C%5Cno%22@example.org>.
554 Email address: "\\\"it's\ ugly\\\""@example.org; corresponding
557 <mailto:%22%5C%5C%5C%22it's%5C%20ugly%5C%5C%5C%22%22@example.org>.
562Duerst, et al. Standards Track [Page 10]
564RFC 6068 The 'mailto' URI Scheme October 2010
5676.3. Examples Using UTF-8-Based Percent-Encoding
569 Sending a mail with the subject "coffee" in French, i.e., "cafe"
570 where the final e is an e-acute, using UTF-8 and percent-encoding:
572 <mailto:user@example.org?subject=caf%C3%A9>
574 The same subject, this time using an encoded-word (escaping the "="
575 and "?" characters used in the encoded-word syntax, because they are
579 example.org?subject=%3D%3Futf-8%3FQ%3Fcaf%3DC3%3DA9%3F%3D>
581 The same subject, this time encoded as iso-8859-1:
584 example.org?subject=%3D%3Fiso-8859-1%3FQ%3Fcaf%3DE9%3F%3D>
586 Going back to straight UTF-8 and adding a body with the same value:
588 <mailto:user@example.org?subject=caf%C3%A9&body=caf%C3%A9>
590 This 'mailto' URI may result in a message looking like this:
592 From: sender@example.net
594 Subject: =?utf-8?Q?caf=C3=A9?=
595 Content-Type: text/plain;charset=utf-8
596 Content-Transfer-Encoding: quoted-printable
600 The software sending the email is not restricted to UTF-8, but can
601 use other encodings. The following shows the same email using
602 iso-8859-1 two times:
604 From: sender@example.net
606 Subject: =?iso-8859-1?Q?caf=E9?=
607 Content-Type: text/plain;charset=iso-8859-1
608 Content-Transfer-Encoding: quoted-printable
612 Different content transfer encodings (i.e., "8bit" or "base64"
613 instead of "quoted-printable") and different encodings in encoded
614 words (i.e., "B" instead of "Q") can also be used.
618Duerst, et al. Standards Track [Page 11]
620RFC 6068 The 'mailto' URI Scheme October 2010
623 For more examples of encoding the word coffee in different languages,
626 The following example uses the Japanese word "natto" (Unicode
627 characters U+7D0D U+8C46) as a domain name label, sending a mail to a
628 user at "natto".example.org:
630 <mailto:user@%E7%B4%8D%E8%B1%86.example.org?subject=Test&body=NATTO>
632 When constructing the email, the domain name label is converted to
633 punycode. The resulting message may look as follows:
635 From: sender@example.net
636 To: user@xn--99zt52a.example.org
638 Content-Type: text/plain
639 Content-Transfer-Encoding: 7bit
6437. Security Considerations
645 The 'mailto' URI scheme can be used to send a message from one user
646 to another, and thus can introduce many security concerns. Mail
647 messages can be logged at the originating site, the recipient site,
648 and intermediary sites along the delivery path. If the messages are
649 not encrypted, they can also be read at any of those sites.
651 A 'mailto' URI gives a template for a message that can be sent by
652 mail client software. The contents of that template may be opaque or
653 difficult to read by the user at the time of specifying the URI, as
654 well as being hidden in the user interface (for example, a link on an
655 HTML Web page might display something other than the content of the
656 corresponding 'mailto' URI that would be used when clicked). Thus, a
657 mail client SHOULD NOT send a message based on a 'mailto' URI without
658 first disclosing and showing to the user the full message that will
659 be sent (including all header fields that were specified by the
660 'mailto' URI), fully decoded, and asking the user for approval to
661 send the message as electronic mail. The mail client SHOULD also
662 make it clear that the user is about to send an electronic mail
663 message, since the user may not be aware that this is the result of a
664 'mailto' URI. Users are strongly encouraged to ensure that the
665 'mailto' URI presented to them matches the address included in the
666 "To:" line of the email message.
674Duerst, et al. Standards Track [Page 12]
676RFC 6068 The 'mailto' URI Scheme October 2010
679 Some header fields are inherently unsafe to include in a message
680 generated from a URI. For details, please see Section 3. In
681 general, the fewer header fields interpreted from the URI, the less
682 likely it is that a sending agent will create an unsafe message.
684 Examples of problems with sending unapproved mail include:
686 mail that breaks laws upon delivery, such as making illegal
689 mail that identifies the sender as someone interested in breaking
692 mail that identifies the sender to an unwanted third party;
694 mail that causes a financial charge to be incurred by the sender;
696 mail that causes an action on the recipient machine that causes
697 damage that might be attributed to the sender.
699 Programs that interpret 'mailto' URIs SHOULD ensure that the SMTP
700 envelope return path address, which is given as an argument to the
701 SMTP MAIL FROM command, is set and correct, and that the resulting
702 email is a complete, workable message.
704 'mailto' URIs on public Web pages expose mail addresses for
705 harvesting. This applies to all mail addresses that are part of the
706 'mailto' URI, including the addresses in a "bcc" <hfvalue>. Those
707 addresses will not be sent to the recipients in the 'to' field and in
708 the "to" and "cc" <hfvalue>s, but will still be publicly visible in
709 the URI. Addresses in a "bcc" <hfvalue> may also leak to other
710 addresses in the same <hfvalue> or become known otherwise, depending
711 on the mail user agent used.
713 Programs manipulating 'mailto' URIs have to take great care to not
714 inadvertently double-escape or double-unescape 'mailto' URIs, and to
715 make sure that escaping and unescaping conventions relating to URIs
716 and relating to mail addresses are applied in the right order.
718 Implementations parsing 'mailto' URIs must take care to sanity check
719 'mailto' URIs in order to avoid buffer overflows and problems
720 resulting from them (e.g., execution of code specified by the
723 The security considerations of [STD66], [RFC5890], [RFC5891], and
724 [RFC3987] also apply. Implementers and users are advised to check
730Duerst, et al. Standards Track [Page 13]
732RFC 6068 The 'mailto' URI Scheme October 2010
7358. IANA Considerations
7378.1. Update of the Registration of the 'mailto' URI Scheme
739 This document changes the definition of the 'mailto' URI scheme; the
740 registry of URI schemes has been updated to refer to this document
741 rather than its predecessor, [RFC2368]. The registration template is
751 See the syntax section of RFC 6068.
753 URI scheme semantics:
754 See the semantics section of RFC 6068.
756 Encoding considerations:
757 See the syntax and encoding sections of RFC 6068.
759 Applications/protocols that use this URI scheme name:
760 The 'mailto' URI scheme is widely used since the start of the Web.
762 Interoperability considerations:
763 Interoperability for 'mailto' URIs with UTF-8-based percent-
764 encoding might be somewhat lower than interoperability for
765 'mailto' URIs with US-ASCII only.
767 Security considerations:
768 See the security considerations section of RFC 6068.
773 Author/Change controller:
786Duerst, et al. Standards Track [Page 14]
788RFC 6068 The 'mailto' URI Scheme October 2010
7918.2. Registration of the Body Header Field
793 IANA has registered the Body header field in the Message Header
794 Fields Registry ([RFC3864]) as follows:
800 None. This registration is made to assure that this header field
801 name is not used at all, in order to not create any problems for
807 Author/Change controller:
810 Specification document(s):
8169. Main Changes from RFC 2368
818 The main changes from RFC 2368 are as follows:
820 o Changed syntax from RFC 2822 <mailbox> to [RFC5322] <addr-spec>.
822 o Allowed UTF-8-based percent-encoding for domain names and in
825 o Nailed down percent-encoding in <local-part> to be based on UTF-8,
826 reserved for if and when there is a specification for the
827 internationalization of email addresses.
829 o Removed prohibition against "Bcc:" header fields, but added a
830 warning about their visibility and harvesting for spam.
832 o Added clarifications for escaping.
836 This document was derived from [RFC2368]; the acknowledgments from
837 that specification still apply. In addition, we thank Paul Hoffman
838 for his work on [RFC2368].
842Duerst, et al. Standards Track [Page 15]
844RFC 6068 The 'mailto' URI Scheme October 2010
847 Valuable input on this document was received from (in no particular
848 order): Alexey Melnikov, Paul Hoffman, Charles Lindsey, Tim Kindberg,
849 Frank Ellermann, Etan Wexler, Michael Haardt, Michael Anthony
850 Puls II, Eliot Lear, Dave Crocker, Dan Harkins, Nevil Brownlee, John
851 Klensin, Alfred Hoenes, Ned Freed, Sean Turner, Peter Saint-Andre,
852 Adrian Farrel, Avshalom Houri, Robert Sparks, and many others.
85611.1. Normative References
858 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
859 Extensions (MIME) Part One: Format of Internet Message
860 Bodies", RFC 2045, November 1996.
862 [RFC2047] Moore, K., "MIME Part Three: Message Header Extensions for
863 Non-ASCII Text", RFC 2047, November 1996.
865 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
866 Requirement Levels", BCP 14, RFC 2119, March 1997.
868 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
869 Procedures for Message Header Fields", BCP 90, RFC 3864,
872 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
873 Identifiers (IRIs)", RFC 3987, January 2005.
875 [RFC5322] Resnik, P., "Internet Message Format", RFC 5322,
878 [RFC5890] Klensin, J., "Internationalized Domain Names for
879 Applications (IDNA): Definitions and Document Framework",
880 RFC 5890, August 2010.
882 [RFC5891] Klensin, J., "Internationalized Domain Names in
883 Applications (IDNA): Protocol", RFC 5891, August 2010.
885 [STD63] Yergeau, F., "UTF-8, a transformation format of ISO
886 10646", STD 63, RFC 3629, November 2003.
888 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
889 Resource Identifier (URI): Generic Syntax", STD 66,
890 RFC 3986, January 2005.
892 [STD68] Crocker, D. and P. Overell, "Augmented BNF for Syntax
893 Specifications: ABNF", STD 68, RFC 5234, January 2008.
898Duerst, et al. Standards Track [Page 16]
900RFC 6068 The 'mailto' URI Scheme October 2010
90311.2. Informative References
905 [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol
906 (HTCPCP/1.0)", RFC 2324, April 1998.
908 [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto
909 URL scheme", RFC 2368, July 1998.
911 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for
912 Internationalized Email", RFC 4952, July 2007.
916 Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever
917 possible, for example as "Dürst" in XML and HTML.)
918 Aoyama Gakuin University
920 Sagamihara, Kanagawa 229-8558
923 Phone: +81 42 759 6329
925 EMail: duerst@it.aoyama.ac.jp
926 URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
930 Adobe Systems Incorporated
935 Phone: +1-408-536-3024
937 URI: http://larry.masinter.net/
943 San Francisco, CA 94103
954Duerst, et al. Standards Track [Page 17]