The 'mailto' URI Scheme
obsoletes
- rfc-2368 — The mailto URL scheme
Extracted elements (27)
The "body" pseudo header field is primarily intended for short text messages for automatic processing (e.g., mailing list subscribe commands), not general MIME bodies. This limitation avoids the complexity of full MIME encoding in URIs.
URI producers SHOULD provide internationalized domain names in IDNA encoding rather than percent-encoded form to maximize interoperability with legacy 'mailto' URI interpreters that do not understand UTF-8-based percent-encoding for domain names.
Combining a 'to' address in both the <to> component and a 'to' hfvalue (e.g., mailto:addr1@example.com?to=addr2@example.com) is syntactically valid but NOT RECOMMENDED because different user agents handle this case differently; some existing clients ignore 'to' hfvalues.
HTML forms historically encode spaces as '+', but this is problematic in 'mailto' URIs because a '+' cannot be distinguished from a literal '+' (used in subaddressing). All spaces SHOULD be encoded as %20 when producing 'mailto' URIs.
Interoperability for 'mailto' URIs with UTF-8-based percent-encoding may be lower than for US-ASCII-only 'mailto' URIs, due to legacy implementations that do not support the internationalization extensions added by RFC 6068.
Characters that cannot appear in a URI per STD66, as well as "%", and gen-delims except "@" and ":" (i.e., "/", "?", "#", "[", "]") MUST be percent-encoded in addr-spec. Among sub-delims, "&", ";", and "=" also MUST be percent-encoded.
Clients that resolve 'mailto' URIs into mail messages MUST be able to correctly create RFC 5322-compliant mail messages using at minimum the "subject" header field and "body".
For internationalized domain names in addr-spec, non-ASCII characters MUST first be encoded as UTF-8 and then each octet MUST be percent-encoded. URI-producing applications MUST NOT use percent-encoding in domain names unless it represents a UTF-8 character sequence.
Fragment identifiers SHOULD NOT be used on 'mailto' URIs and SHOULD be ignored upon resolution. The "#" character in hfvalues MUST be escaped as %23.
Header fields related to message encoding (e.g., Content-Transfer-Encoding) in a 'mailto' URI are irrelevant and MUST be ignored.
Implementations MUST NOT produce two "To:" header fields in a message; the "To:" header field may occur at most once. Creators of 'mailto' URIs MUST NOT include other message header fields multiple times if those fields can only appear once.
Line breaks in the body of a message MUST be encoded with "%0D%0A". All spaces SHOULD be encoded as %20; '+' characters MAY be encoded as %2B.
Non-ASCII characters in the local-part of an addr-spec MUST first be encoded as UTF-8 and then percent-encoded. Any other percent-encoding of non-ASCII characters in local-part is prohibited.
<obs-local-part> and <NO-WS-CTL> as defined in RFC 5322 MUST NOT be used in a 'mailto' URI addr-spec.
Originator fields (From, Date), routing fields (Resent-*, etc.), trace fields, and MIME header fields (MIME-Version, Content-*) present in a 'mailto' URI MUST be ignored by the mail client.
The user agent interpreting a 'mailto' URI SHOULD NOT create a message if any header fields are considered dangerous; it MAY create a message with only a subset of the header fields given in the URI.
When an internationalized domain name is used to compose a message, it MUST be transformed to IDNA encoding (RFC 5891). URI producers SHOULD provide domain names in IDNA encoding rather than percent-encoded to maximize interoperability with legacy 'mailto' URI interpreters.
When creating 'mailto' URIs, any reserved characters MUST be encoded so that URI interpreters can read them. Client software reading URIs MUST decode strings before creating the mail message.
Whitespace and comments within <local-part> and <domain> of an addr-spec in a 'mailto' URI MUST NOT be used, as they would have no operational semantics.
The special hfname "body" indicates the associated hfvalue is the message body, intended for the first text/plain body part. No additional encoding (e.g., base64 or quoted-printable) is used for the body field value beyond UTF-8-based percent-encoding.
IANA has registered the "Body" header field in the Message Header Fields Registry (RFC 3864) with status "reserved" and applicable protocol "None", to prevent its use as an actual message header field and avoid conflicts with 'mailto' URI semantics.
The IANA registry of URI schemes is updated so that the 'mailto' URI scheme registration (previously pointing to RFC 2368) now references RFC 6068. The scheme is permanent status.
A mail client SHOULD NOT send a message based on a 'mailto' URI without first disclosing and showing to the user the full message (including all header fields), fully decoded, and asking for user approval. The client SHOULD also make clear that an email will be sent.
'mailto' URIs on public web pages expose all included mail addresses (including bcc hfvalues) to harvesting. Addresses in a "bcc" hfvalue are still publicly visible in the URI even though not sent to 'to' recipients.
Programs interpreting 'mailto' URIs SHOULD ensure that the SMTP envelope return path address (MAIL FROM argument) is set and correct, and that the resulting email is a complete, workable message.
Programs manipulating 'mailto' URIs must take care not to double-escape or double-unescape, and must apply URI and mail address escaping/unescaping conventions in the correct order. Implementations must sanity-check URIs to avoid buffer overflows and code execution.
The 'mailto' URI syntax is defined as: mailtoURI = "mailto:" [ to ] [ hfields ], where to is one or more comma-separated addr-spec values, and hfields are key=value pairs separated by '&' and introduced by '?'. The addr-spec is local-part "@" domain, with local-part being dot-atom-text or quoted-string.