RFC 6068

The 'mailto' URI Scheme

📅 published October 2010, from ietf

📮 RFC 6068: The 'mailto' URI Scheme 💌

Authors: M. Duerst (Aoyama Gakuin University), L. Masinter (Adobe Systems Incorporated), J. Zawinski (DNA Lounge) 🎀 Category: Standards Track ✨ ISSN: 2070-1721 Date: October 2010 📅 Obsoletes: RFC 2368 💅 Updates: nothing listed in the header 🌸

Okay so this is the RFC that gives mailto: links their official spec. Yes, the ones that open your email app 📧 It obsoletes RFC 2368, which means this document replaces the old one, and the header doesn't list anything it updates. Bestie, let's get into it 🫶

Abstract 🦋

Okay so the big idea is this: this doc defines the format of URIs that point to resources you reach through Internet mail 📬 It also adds better internationalization and makes things work with IRIs (RFC 3987) on top of the older mailto syntax from RFC 2368. Lowkey the glow-up we all needed 💖

Status of This Memo 📜

This is an Internet Standards Track document. 🔥

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 5741 📚

For the current status of this document, any errata, and how to give feedback on it, head to http://www.rfc-editor.org/info/rfc6068 🌈

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the date this document was published. Please read these carefully, because they explain your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. ⚖️

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍

Table of Contents 🗂️

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Syntax of a 'mailto' URI . . . . . . . . . . . . . . . . . . .  3
   3.  Semantics and Operations . . . . . . . . . . . . . . . . . . .  7
   4.  Unsafe Header Fields . . . . . . . . . . . . . . . . . . . . .  7
   5.  Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Basic Examples . . . . . . . . . . . . . . . . . . . . . .  9
     6.2.  Examples of Complicated Email Addresses  . . . . . . . . . 10
     6.3.  Examples Using UTF-8-Based Percent-Encoding  . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     8.1.  Update of the Registration of the 'mailto' URI Scheme  . . 14
     8.2.  Registration of the Body Header Field  . . . . . . . . . . 15
   9.  Main Changes from RFC 2368 . . . . . . . . . . . . . . . . . . 15
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     11.2. Informative References . . . . . . . . . . . . . . . . . . 17

1. Introduction ✨

Okay so the mailto URI scheme is how you identify resources that get reached through Internet mail 💌 In its simplest form, a mailto URI just holds an Internet mail address, like the cutest little envelope 💖 But when you need to specify message headers or message bodies, the scheme also lets you include mail header fields and the message body 📝

This spec extends the old scheme definition so character data can be percent-encoded based on UTF-8 [STD63]. That's a much better and more consistent way to handle non-ASCII characters for internationalization, and honestly it's giving main character energy 🌍🦋

Heads up: this spec does NOT cover the needs of the ongoing Email Address Internationalization effort (see [RFC4952]) 🙈 In particular, it doesn't include any syntax for fallback addresses.

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

Last thing, bestie: in this document, URIs get wrapped in < and >, as described in Appendix C of [STD66]. Any extra whitespace and line breaks are just there to make long URIs easier to read. They are not part of the actual URI 🫶

2. Syntax of a 'mailto' URI ✨

okay so the whole syntax is written in the ABNF from [STD68], and it borrows some non-terminals from [RFC5322] (dot-atom-text, quoted-string) and [STD66] (unreserved, pct-encoded). this grammar is the heart of it, so read it slowly 💅🎀

mailtoURI    = "mailto:" [ to ] [ hfields ]
to           = addr-spec *("," addr-spec )
hfields      = "?" hfield *( "&" hfield )
hfield       = hfname "=" hfvalue
hfname       = *qchar
hfvalue      = *qchar
addr-spec    = local-part "@" domain
local-part   = dot-atom-text / quoted-string
domain       = dot-atom-text / "[" *dtext-no-obs "]"
dtext-no-obs = %d33-90 / ; Printable US-ASCII
               %d94-126  ; characters not including
                         ; "[", "]", or "\"
qchar        = unreserved / pct-encoded / some-delims
some-delims  = "!" / "$" / "'" / "(" / ")" / "*"
             / "+" / "," / ";" / ":" / "@"

so <addr-spec> is a mail address from [RFC5322], except it leaves out the <comment> bit from [RFC5322]. BUT there are some extra changes you need to know about, bestie 🙈

  1. A bunch of characters that can show up in <addr-spec> MUST be percent-encoded. these are the characters that can't appear in a URI according to [STD66], plus "%" (because it's what we use for percent-encoding), plus all the gen-delims except "@" and ":" (i.e., "/", "?", "#", "[", and "]"). from the sub-delims, at least these ones also have to be percent-encoded: "&", ";", and "=". and lowkey the careful part is that encoding AND decoding both need to be done only once, so nobody double-encodes anything 😭
  2. <obs-local-part> and <NO-WS-CTL> as defined in [RFC5322] MUST NOT be used. no obsolete vibes allowed 🚫
  3. whitespace and comments inside <local-part> and <domain> MUST NOT be used. they wouldn't have any operational meaning anyway, so why even 💀
  4. percent-encoding can be used in the <domain> part of an <addr-spec> to show an internationalized domain name. the rules for <reg-name> in [STD66] apply here. the main thing: non-ASCII characters MUST first be encoded with UTF-8 [STD63], and then each octet of that UTF-8 sequence MUST be percent-encoded so it becomes URI characters. URI-producing apps MUST NOT use percent-encoding in domain names unless it's representing a UTF-8 character sequence. when the internationalized domain name is used to compose a message, the name MUST be transformed to the Internationalizing Domain Names in Applications (IDNA) encoding [RFC5891] where appropriate. and if you want the best interoperability with legacy 'mailto' URI interpreters, URI producers SHOULD give these domain names in IDNA encoding instead of percent-encoded 🌈
  5. percent-encoding of non-ASCII octets in the <local-part> of an <addr-spec> is reserved for internationalizing the <local-part>. non-ASCII characters MUST first be encoded with UTF-8 [STD63], and then each octet of that UTF-8 sequence MUST be percent-encoded to become URI characters. any other percent-encoding of non-ASCII characters is prohibited. and when a <local-part> with non-ASCII characters is going to be used to compose a message, the <local-part> MUST be transformed to conform to whatever encoding a future specification defines for internationalizing email addresses ✨

<hfname> and <hfvalue> are encodings of an [RFC5322] header field name and value, respectively. percent-encoding is needed for the same characters listed above for <addr-spec>. <hfname> is case-insensitive, but <hfvalue> is generally case-sensitive. also [RFC5322] allows all US-ASCII printable characters except ":" in optional header field names (Section 3.6.8), and that's the reason <pct-encoded> is part of the header field name production 🦋

the special <hfname> "body" means the associated <hfvalue> is the body of the message. the "body" field value is meant to hold the content for the first text/plain body part of the message. the "body" pseudo header field is mainly for making short text messages for automatic processing (like "subscribe" messages for mailing lists), NOT for general MIME bodies. apart from the UTF-8 character encoding and percent-encoding, NO additional encoding (like base64 or quoted-printable; see [RFC2045]) is used for the "body" field value. so header fields about message encoding (e.g., Content-Transfer-Encoding) in a 'mailto' URI are irrelevant and MUST be ignored. the "body" pseudo header field name has been registered with IANA for this special purpose (see Section 8.2) 🍓

inside 'mailto' URIs, the characters "?", "=", and "&" are reserved and act as delimiters. when they're NOT doing delimiter duty, they have to be escaped as "%3F", "%3D", and "%26", respectively 😭

extra restrictions on which characters are allowed might apply depending on where the URI is used. those can be handled with context-specific escaping mechanisms. for example, "&" is reserved in HTML and XML, so any 'mailto' URI with an ampersand has to be written as an HTML/XML entity (&amp;) or a numeric character reference (&#x26; or &#38;) 💖

non-ASCII characters can be put in <hfvalue> like this:

  1. MIME encoded words (as defined in [RFC2047]) are allowed in header field values, but NOT in an <hfvalue> of a "body" <hfname>. sequences of characters that look like MIME encoded words can show up in an <hfvalue> of a "body" <hfname>, but in that case they have no special meaning. heads up that the "=" and "?" characters used as delimiters in MIME encoded words have to be percent-encoded. also, using MIME encoded words is a tiny bit different for so-called structured and unstructured header fields 🎀
  2. non-ASCII characters can be encoded according to UTF-8 [STD63], and then each octet of that UTF-8 sequence is percent-encoded to become URI characters. when header field values encoded this way are used to compose a message, the <hfvalue> has to be suitably encoded (turned into MIME encoded words [RFC2047]), EXCEPT for an <hfvalue> of a "body" <hfname>, which has to be encoded according to [RFC2045]. and for MIME encoded words and bodies in composed email messages, encodings other than UTF-8 MAY be used as long as the characters are properly transcoded 🌸

also, it's totally valid syntax to specify both <to> AND an <hfname> whose value is "to". like these three are the same:

<mailto:addr1@an.example,addr2@an.example>
<mailto:?to=addr1@an.example,addr2@an.example>
<mailto:addr1@an.example?to=addr2@an.example>

HOWEVER, that last form is NOT RECOMMENDED, because different user agents handle it differently. some existing clients just ignore "to" <hfvalue>s, so 😬

implementations MUST NOT produce two "To:" header fields in a message. the "To:" header field may occur at most once in a message ([RFC5322], Section 3.6). and creators of 'mailto' URIs MUST NOT include other message header fields multiple times if those header fields can only be used once in a message. that's the rule, periodt 👑

to avoid interoperability problems, creators of 'mailto' URIs SHOULD NOT use the same <hfname> multiple times in the same URI. if the same <hfname> shows up more than once, behavior varies wildly across user agents, and for each <hfname>. examples include using only the first or last <hfname>/<hfvalue> pair, creating multiple header fields, and combining each <hfvalue> by simple concatenation or in a way that fits the corresponding header field. it's chaos, bestie 🌀

this spec, like any URI scheme spec, does NOT define the syntax or meaning of a fragment identifier (see [STD66]), because those depend on the type of retrieved representation. in the currently known usage scenarios, a 'mailto' URI can't be used to retrieve such representations. so fragment identifiers are meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be ignored when resolving. the character "#" in <hfvalue>s MUST be escaped as %23 🧚

3. Semantics and Operations 🦋

a 'mailto' URI designates an "Internet resource", which is the mailbox specified in the address. when extra header fields are supplied, the resource designated is the same address but with an additional profile for accessing it. there are Internet resources that can ONLY be reached through email, but the 'mailto' URI isn't meant to be a way to pull those objects automatically 💜

how any URI scheme gets resolved isn't mandated by the URI specs. in current practice, resolving URIs like the ones in the 'http' URI scheme causes an immediate back-and-forth between client software and a host running an interactive server. the 'mailto' URI is kind of unusual, though, because resolving it does NOT cause an immediate interaction with a server. instead, the client creates a message to the designated address with the various header fields set as defaults. then the user gets to edit the message, send it unedited, or choose not to send it at all ✨

the <hfname>/<hfvalue> pairs in a 'mailto' URI are syntactically equivalent to header fields in a mail message, but they don't directly match up with the header fields in a mail message. in particular, the To, Cc, and Bcc <hfvalue>s don't necessarily end up as a header field containing the specified value. mail client software MAY eliminate duplicate addresses. and creators of 'mailto' URIs SHOULD avoid using the same address twice in a 'mailto' URI 🌈

originator fields like From and Date, fields related to routing (Apparently-To, Resent-, etc.), trace fields, and MIME header fields (MIME-Version, Content-), when they're present in the URI, MUST be ignored. the mail client MUST create new fields when necessary, the same way it would for any new message. unrecognized header fields, and header fields with values that don't match what the mail client would normally send, SHOULD be treated as especially suspect. for example, there may be header fields that are totally safe but unknown to the MUA, so the MUA MAY choose to show them to the user 👀

4. Unsafe Header Fields 🔥

the user agent interpreting a 'mailto' URI SHOULD NOT create a message if any of the header fields are considered dangerous. it MAY also choose to create a message with only a subset of the header fields given in the URI. only a limited set of header fields, like Subject and Keywords, plus Body, are believed to be both safe and useful in the general case. when the source of a URI is well known, and/or specific header fields are limited to specific well-known values, other header fields MAY be considered safe too 🛡️

the creator of a 'mailto' URI can't expect the resolver of the URI to understand more than the "subject" header field and "body". clients that resolve 'mailto' URIs into mail messages MUST be able to correctly create [RFC5322]-compliant mail messages using the "subject" header field and "body" 💖

5. Encoding 💅

Okay bestie, so [STD66] is super strict about encoding characters in URIs 🫶. That hits 'mailto' URIs hard, because so many normal characters in addresses, header fields, and message bodies need special treatment. Space (" ", ASCII hex 20) is the big one. The examples below use %20 for spaces in the message body, so keep an eye out for that. ✨ Line breaks in the body MUST be encoded as %0D%0A. Implementations MAY tack a final line break onto the body even when there's no trailing %0D%0A in the body <hfield> of the 'mailto' URI. Line breaks in other <hfield>s SHOULD NOT be used 🙅‍♀️.

When you're making 'mailto' URIs, any reserved characters you use MUST be encoded so that properly written URI readers can understand them 🔐. Client software that reads URIs MUST decode the strings before it builds the mail message, so the message looks right to the recipient's software 💌. Those strings SHOULD also be decoded before the message is shown to the sending user.

Software that makes 'mailto' URIs has to be careful about encoding reserved characters too. HTML forms are one example of that kind of software 📝. Lots of current implementations turn a space into '+', and honestly that's a mess 😭. A '+' standing in for a space looks exactly like a real '+' in a 'mailto' URI, so you can't tell them apart. So when you produce a 'mailto' URI, all spaces SHOULD be encoded as %20, and '+' characters MAY be encoded as %2B. Also, '+' is often part of a real email address for a subaddress, like bill+ietf@example.org 💜, so don't just assume it's a space.

The 'mailto' URI scheme can't do variable substitution 🙃. That means it's impossible to make a 'mailto' URI that drops the user's own email address into the message body. It also rules out 'mailto' URIs that carry public-key signatures or other variable info.

6. Examples 🧚

Now for the fun part, the examples! ✨

6.1. Basic Examples

Here's a URI for a regular person's mailing address 💖:

<mailto:chris@example.com>

Here's a mail response system that needs the file name to send back in the subject 📂:

<mailto:infobot@example.com?subject=current-issue>

And a mail response system that wants a "send" request in the body 📬:

<mailto:infobot@example.com?body=send%20current-issue>

This one has two lines with different "send" requests, "send current-issue" and, on the next line, "send index" 🌈:

<mailto:infobot@
example.com?body=send%20current-issue%0D%0Asend%20index>

'Mailto' URIs are honestly iconic for browsing message archives 🦋. You can add a link that lets someone reply to a message and keep the threading info. You do this by adding an In-Reply-To header field that holds the Message-ID of the message where the link lives, like this:

<mailto:list@example.org?In-Reply-To=%3C3469A91.D10AF4C@
example.com%3E>

Here's a request to subscribe to a mailing list 🎀:

<mailto:majordomo@example.com?body=subscribe%20bamboo-l>

And a URI for a single user that also CCs another user 👯‍♀️:

<mailto:joe@example.com?cc=bob@example.com&body=hello>

Notice the "&" reserved character up there? The next example uses "?" twice, and that is WRONG 💀:

<mailto:joe@example.com?cc=bob@example.com?body=hello> ; WRONG!

According to [RFC5322], the characters "?", "&", and even "%" may occur in addr-specs. Being reserved isn't the problem. Those characters are allowed in 'mailto' URIs, they just can't show up unencoded. The standard URI encoding mechanisms ("%" followed by a two-digit hex number) MUST be used in these cases 🔑.

Say you want the address "gorby%kremvax@example.com". You'd write:

<mailto:gorby%25kremvax@example.com>

To indicate the address "unlikely?address@example.com" and include another header field, you'd write:

<mailto:unlikely%3Faddress@example.com?blat=foop>

Now, "&" (ampersand) is reserved in HTML, so it has to be swapped out, for example with "&amp;" 🫣. A URI with an internal ampersand might look like this:

Click
<a href="mailto:joe@an.example?cc=bob@an.example&amp;body=hello"
>mailto:joe@an.example?cc=bob@an.example&amp;body=hello</a> to send a
greeting message to Joe and Bob.

If an email address has an "&" (ampersand) character in it, that character has to be percent-encoded. So the 'mailto' URI for mail to "Mike&family@example.org" is:

<mailto:Mike%26family@example.org>

6.2. Examples of Complicated Email Addresses

Here are a few examples of how to handle email addresses with complicated escaping syntax 🧩.

For the email address "not@me"@example.org, the corresponding 'mailto' URI is:

<mailto:%22not%40me%22@example.org>

For the email address "oh\no"@example.org, the corresponding 'mailto' URI is:

<mailto:%22oh%5C%5Cno%22@example.org>

For the email address "\"it's\ ugly\""@example.org, the corresponding 'mailto' URI is:

<mailto:%22%5C%5C%5C%22it's%5C%20ugly%5C%5C%5C%22%22@example.org>

6.3. Examples Using UTF-8-Based Percent-Encoding

Let's send a mail with the subject "coffee" in French, which is "cafe" with an e-acute on the end ☕. This uses UTF-8 and percent-encoding:

<mailto:user@example.org?subject=caf%C3%A9>

Same subject, but this time with an encoded-word. The "=" and "?" characters used in the encoded-word syntax are escaped, because they're reserved 🎀:

<mailto:user@
example.org?subject=%3D%3Futf-8%3FQ%3Fcaf%3DC3%3DA9%3F%3D>

Same subject again, this time encoded as iso-8859-1 🌸:

<mailto:user@
example.org?subject=%3D%3Fiso-8859-1%3FQ%3Fcaf%3DE9%3F%3D>

Back to plain UTF-8, adding a body with the same value 💅:

<mailto:user@example.org?subject=caf%C3%A9&body=caf%C3%A9>

This 'mailto' URI may result in a message that looks like this:

   From: sender@example.net
   To: user@example.org
   Subject: =?utf-8?Q?caf=C3=A9?=
   Content-Type: text/plain;charset=utf-8
   Content-Transfer-Encoding: quoted-printable

   caf=C3=A9

The software sending the email isn't stuck with UTF-8 either. It can use other encodings 🌍. Here's the same email using iso-8859-1 twice:

   From: sender@example.net
   To: user@example.org
   Subject: =?iso-8859-1?Q?caf=E9?=
   Content-Type: text/plain;charset=iso-8859-1
   Content-Transfer-Encoding: quoted-printable

   caf=E9

You can also use different content transfer encodings, like "8bit" or "base64" instead of "quoted-printable", and different encodings in encoded words, like "B" instead of "Q" 🦋.

For more examples of encoding the word coffee in different languages, see [RFC2324].

Next up is the Japanese word "natto" (Unicode characters U+7D0D U+8C46) as a domain name label. This sends a mail to a user at "natto".example.org 🍓:

<mailto:user@%E7%B4%8D%E8%B1%86.example.org?subject=Test&body=NATTO>

When the email gets built, the domain name label is converted to punycode. The resulting message may look like this:

   From: sender@example.net
   To: user@xn--99zt52a.example.org
   Subject: Test
   Content-Type: text/plain
   Content-Transfer-Encoding: 7bit

   NATTO

7. Security Considerations 🔐

Okay, this part is serious, so listen up 🚨. The 'mailto' URI scheme can be used to send a message from one user to another, which means it can introduce a lot of security concerns. Mail messages can be logged at the originating site, the recipient site, and intermediary sites along the delivery path 👀. If the messages aren't encrypted, they can also be read at any of those sites.

A 'mailto' URI is basically a template for a message that mail client software can send 📨. The contents of that template may be opaque or hard for the user to read when they're specifying the URI. They can also be hidden in the user interface. For example, a link on an HTML Web page might display something other than the content of the 'mailto' URI that actually gets used when it's clicked 😱. So a mail client SHOULD NOT send a message based on a 'mailto' URI without first disclosing and showing the user the full message that will be sent. That includes all header fields that were specified by the 'mailto' URI, fully decoded, and it needs the user's approval before it goes out as electronic mail ✋. The mail client SHOULD also make it clear that the user is about to send an electronic mail message, since the user may not realize that a 'mailto' URI caused it. Users are strongly encouraged to make sure the 'mailto' URI shown to them matches the address in the "To:" line of the email message 👑.

Some header fields are inherently unsafe to include in a message generated from a URI. For details, please see Section 3. In general, the fewer header fields interpreted from the URI, the less likely it is that a sending agent will create an unsafe message 💜.

Examples of problems with sending unapproved mail include:

  • mail that breaks laws upon delivery, such as making illegal threats;
  • mail that identifies the sender as someone interested in breaking laws;
  • mail that identifies the sender to an unwanted third party;
  • mail that causes a financial charge to be incurred by the sender;
  • mail that causes an action on the recipient machine that causes damage that might be attributed to the sender 💀.

Programs that interpret 'mailto' URIs SHOULD ensure that the SMTP envelope return path address, which is given as an argument to the SMTP MAIL FROM command, is set and correct. They should also make sure the resulting email is a complete, workable message 🫶.

'mailto' URIs on public Web pages expose mail addresses for harvesting 🙈. This applies to all mail addresses that are part of the 'mailto' URI, including the addresses in a "bcc" <hfvalue>. Those addresses won't be sent to the recipients in the 'to' field and in the "to" and "cc" <hfvalue>s, but they'll still be publicly visible in the URI. Addresses in a "bcc" <hfvalue> may also leak to other addresses in the same <hfvalue> or become known some other way, depending on the mail user agent used 😬.

Programs manipulating 'mailto' URIs have to take great care not to accidentally double-escape or double-unescape them. They also need to make sure that the escaping and unescaping conventions for URIs and for mail addresses are applied in the right order 🧠.

Implementations parsing 'mailto' URIs must take care to sanity check them, so they can avoid buffer overflows and the problems that come from them, like an attacker running code they specified 🚫💻.

The security considerations of [STD66], [RFC5890], [RFC5891], and [RFC3987] also apply. Implementers and users are advised to check them carefully 🦋.

8. IANA Considerations 🎀

8.1. Update of the Registration of the 'mailto' URI Scheme 💖

okay so this document changes the definition of the mailto URI scheme 🎀 the registry of URI schemes now points at this doc instead of its predecessor, [RFC2368]. here's the registration template, bestie 💅

URI scheme name:
   'mailto'

Status:
   permanent

URI scheme syntax:
   See the syntax section of RFC 6068.

URI scheme semantics:
   See the semantics section of RFC 6068.

Encoding considerations:
   See the syntax and encoding sections of RFC 6068.

Applications/protocols that use this URI scheme name:
   The 'mailto' URI scheme is widely used since the start of the Web.

Interoperability considerations:
   Interoperability for 'mailto' URIs with UTF-8-based percent-
   encoding might be somewhat lower than interoperability for
   'mailto' URIs with US-ASCII only.

Security considerations:
   See the security considerations section of RFC 6068.

Contact:
   IETF

Author/Change controller:
   IETF

References:
   RFC 6068

ngl the interop note is giving honest realness 🫶 UTF-8-based percent-encoding might be a little less interoperable than plain US-ASCII-only mailto URIs. so be careful, periodt 👀

8.2. Registration of the Body Header Field 🦋

IANA has registered the Body header field in the Message Header Fields Registry ([RFC3864]) like this:

Header field name:
   Body

Applicable protocol:
   None.  This registration is made to assure that this header field
   name is not used at all, in order to not create any problems for
   'mailto' URIs.

Status:
   reserved

Author/Change controller:
   IETF

Specification document(s):
   RFC 6068

Related information:
   none

so Body is basically reserved 🙈 nobody is supposed to use it as a real header field at all, so it can never mess with mailto URIs. iconic protection energy 👑

9. Main Changes from RFC 2368 🌸

okay the main glow-up from RFC 2368 looks like this ✨

  • the syntax switched from the RFC 2822 <mailbox> to the [RFC5322] <addr-spec> 💅
  • UTF-8-based percent-encoding is now allowed for domain names and in <hfvalue> 🌈
  • percent-encoding in <local-part> is now nailed down to be UTF-8-based, and it's reserved for whenever there's a spec for internationalized email addresses 🧚
  • the ban on "Bcc:" header fields is gone, BUT there's now a warning about how visible they are and how spammers harvest them 😭 (the vibe is "you can, just know the risk")
  • escaping got some clarifications 💜

10. Acknowledgments 🫶

this document was derived from [RFC2368], and the acknowledgments from that spec still apply 🍓 we also thank Paul Hoffman for his work on [RFC2368] 💖

valuable input came from (in no particular order) 👑: Alexey Melnikov, Paul Hoffman, Charles Lindsey, Tim Kindberg, Frank Ellermann, Etan Wexler, Michael Haardt, Michael Anthony Puls II, Eliot Lear, Dave Crocker, Dan Harkins, Nevil Brownlee, John Klensin, Alfred Hoenes, Ned Freed, Sean Turner, Peter Saint-Andre, Adrian Farrel, Avshalom Houri, Robert Sparks, and many others 🥰

11. References 📚

11.1. Normative References 🔥

[RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
           Extensions (MIME) Part One: Format of Internet Message
           Bodies", RFC 2045, November 1996.

[RFC2047]  Moore, K., "MIME Part Three: Message Header Extensions for
           Non-ASCII Text", RFC 2047, November 1996.

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

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

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

[RFC5322]  Resnik, P., "Internet Message Format", RFC 5322,
           October 2008.

[RFC5890]  Klensin, J., "Internationalized Domain Names for
           Applications (IDNA): Definitions and Document Framework",
           RFC 5890, August 2010.

[RFC5891]  Klensin, J., "Internationalized Domain Names in
           Applications (IDNA): Protocol", RFC 5891, August 2010.

[STD63]    Yergeau, F., "UTF-8, a transformation format of ISO
           10646", STD 63, RFC 3629, November 2003.

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

[STD68]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", STD 68, RFC 5234, January 2008.

11.2. Informative References 🧚

[RFC2324]  Masinter, L., "Hyper Text Coffee Pot Control Protocol
           (HTCPCP/1.0)", RFC 2324, April 1998.

[RFC2368]  Hoffman, P., Masinter, L., and J. Zawinski, "The mailto
           URL scheme", RFC 2368, July 1998.

[RFC4952]  Klensin, J. and Y. Ko, "Overview and Framework for
           Internationalized Email", RFC 4952, July 2007.

Authors' Addresses 💌

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

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


Larry Masinter
Adobe Systems Incorporated
345 Park Ave
San Jose, CA  95110
USA

Phone: +1-408-536-3024
EMail: LMM@acm.org
URI:   http://larry.masinter.net/


Jamie Zawinski
DNA Lounge
375 Eleventh Street
San Francisco, CA  94103
USA

EMail: jwz@jwz.org
📦 where this page comes from