mailto

Not to be confused with Malito.

mailto is a Uniform Resource Identifier (URI) scheme for email resources. More specifically, mailto URIs identify resources reachable via network mail, thus a mailto URI designates one or more mailboxs via use of email addresses. Clicking on a mailto link opens an email client in compose mode, typically with one or more pre-filled form fields.

A common use is to produce hyperlinks on websites that allow users to send an email to a specific address directly from an HTML document, without having to copy and enter it into an email client.

History

This scheme is formally described in RFCs published by the IETF. It was first introduced in RFC 1630, published in June 1994, which sought to establish the concept of URIs. It was then detailed in RFC 1730, published in December 1994, which derived the concept of URLs from RFC 1630. This detail amounted to the scheme simply referencing nothing more than an email address. As discussed later in RFC 2368, published in July 1998, mailto URLs were unusual since resolution did not result in an immediate retrieval of a resource, but rather initiated the creation of an email, which the user could further edit, before optional transmission. This new RFC sought to enhance functionality, allowing for multiple email addresses to be specified using commas, and allowing email header and body content to be specified using the URI query string component (utilising a key=value form with an ampersand (&) delimiter), which would thus expand the set of data pre-populated in the new email. The mailto scheme remains recognised by the current internet standard for URIs, RFC 3986, published in January 2005. RFC 6068, published in October 2010, supplanted RFC 2368 with refinements.

Syntax

Mailto URIs are composed of the scheme mailto: and zero, one, or more recipient addresses separated with a comma. Additionally, email headers such as cc or subject can be added as attribute-value pairs in the query component of the URI.

Percent-encoding must be used for the local-part of the Email addresses and for the header values. The Domain parts of the addresses can also be encoded using percent-encoding but using IDNA-Encoding is recommended for interoperability with legacy software.

Examples

"mailto" can be used within an HTML document to generate a link for sending email:

<a href="mailto:someone@example.com">Send email</a>

Clicking on the hyperlink automatically opens the default email client, ready to compose a new email, with the destination email address pre-filled.

It is possible to specify initial values for headers (e.g. subject, cc, etc.) and message body in the URL. Blanks, carriage returns, and line feeds cannot be directly embedded but must be percent-encoded:

<a href="mailto:someone@example.com?subject=This%20is%20the%20subject&cc=someone_else@example.com&body=This%20is%20the%20body">Send email</a>

Multiple addresses can be specified:

<a href="mailto:someone@example.com,someoneelse@example.com">Send email</a>

The to-address can also be omitted:

<a href="mailto:?subject=mailto%20with%20examples&body=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMailto">Share this knowledge...</a>

Only the initial header should be prepended with a question mark. All subsequent headers require an ampersand. If this convention is not followed, mail clients will not properly copy over the headers to the new email.

Security and privacy

A number of security issues are mentioned in RFC 6068, one of them being robotic address harvesting. Mailto constructs are locatable within HTML pages by automated means which typically include the use of DOM constructs or regular expressions. Addresses harvested by such means are liable to be added to spammers' mass-mailing lists and thus to receive large amounts of unwanted mail.

While methods exist to "harden" mailto links against harvesting—address munging and JavaScript-based address obfuscation among them—these protections can be circumvented by sufficiently sophisticated harvesting robots. Other techniques, like walling the address behind a CAPTCHA or similar "humanity check", provide security on par with that available for other contact methods, most notably web forms, which experience similar challenges with preventing spam.