The mailto URL scheme
Extracted elements (18)
Only the Subject, Keywords, and Body headers are believed to be both safe and useful for mailto URLs. Clients cannot expect resolvers to handle more than "subject" and "body" headers and should correctly create RFC 822-compliant messages using at least those two.
RFC 1738 defined only a simple mailto with no headers, just an addr-spec. Required usage and implementation led to an extended syntax including header fields, which this document formalizes.
The mailto URL has unusual semantics compared to schemes like http: resolving it does not cause immediate interaction with a server. Instead, the client creates a draft message with header fields set as defaults, which the user may edit, send, or discard.
The mailto URL scheme is limited in that it does not provide for substitution of variables. This prevents encoding message bodies that must include the user's email address, or URLs signed with public keys or other variable information.
Because "&" is reserved in HTML, any mailto URL containing an ampersand must use "&" instead of "&" when appearing in an HTML document. This affects URLs with multiple headers.
It is legal to specify recipients both in the "to" component and via an "hname" of "to". For example, `mailto:addr1%2C%20addr2`, `mailto:?to=addr1%2C%20addr2`, and `mailto:addr1?to=addr2` are equivalent forms.
8-bit characters in mailto URLs are forbidden. MIME encoded words (RFC 2047) are permitted in header values but not in any part of a "body" hname.
A user agent interpreting a mailto URL SHOULD choose not to create a message if any of the headers are considered dangerous; it may also choose to create a message with only a subset of the headers given in the URL.
All URL reserved characters in the "to" component and in hname/hvalue fields MUST be encoded. In particular, parentheses, commas, and the percent sign must be encoded in the mailbox syntax.
Line breaks in the body of a message MUST be encoded with "%0D%0A" (CR LF). Space characters must be encoded as "%20".
The special hname "body" designates the message body content. It should contain the first text/plain body part; MIME encoded words are not permitted in the body hname value. The mailto URL is intended for short text messages, not general MIME bodies.
This document updates the definition of the mailto: URI scheme. Any registry of URI schemes should refer to this document rather than its predecessor, RFC 1738.
A mail client MUST NOT send a message based on a mailto URL without first showing the user the full message (including all headers), fully decoded, and obtaining user approval. The client should also make it clear the user is about to send an electronic mail message.
A mail client should never send anything without complete disclosure of all headers and the message destination. Headers such as "From:", "Bcc:", and routing headers should never be interpreted from a URL; MIME headers (MIME-Version, Content-*) are most likely inappropriate.
Mail messages can be logged at originating, recipient, and intermediary sites along the delivery path; if not encrypted, they can be read at any of those sites. The mailto URL template may be opaque or difficult for users to read before specifying the URL.
Programs that interpret mailto URLs should ensure that the SMTP "From" address is set and correct. Unrecognized headers or headers with unexpected values should be treated as especially suspect.
Risks from unapproved mail include: breaking laws upon delivery, identifying the sender to unwanted third parties, causing financial charges, or causing damaging actions on the recipient machine attributable to the sender.
The mailto URL syntax is: `mailtoURL = "mailto:" [ to ] [ headers ]`, where `to = #mailbox`, `headers = "?" header *( "&" header )`, and `header = hname "=" hvalue`. The characters "?", "=", and "&" are reserved within mailto URLs.