mailto is aUniform Resource Identifier (URI) scheme foremail addresses. It is used to producehyperlinks onwebsites that allow users to send anemail to a specific address directly from anHTML document, without having to copy and enter it into anemail client.
It was originally defined byRequest for Comments (RFC) 1738 in December 1994,[1] expanded by RFC 2368 in July 1998,[2] and refined by RFC 6068 in October 2010.[3]
Mailto URIs are composed of the schememailto: and one or more recipient addresses separated with a comma. Additionally, email headers such ascc orsubject can be added asattribute-value pairs in the query component of the email.
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 usingIDNA-Encoding is recommended for interoperability with legacy software.[3]
"mailto" can be used within anHTML document to generate a link for sending email:
<ahref="mailto:someone@example.com">Send email</a>
Clicking on the hyperlink automatically opens the default email client, 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 bepercent-encoded:[4]
<ahref="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:[3]
<ahref="mailto:someone@example.com,someoneelse@example.com">Send email</a>
The address can be omitted:
<ahref="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 aquestion mark. All subsequent headers require anampersand. If this convention is not followed, the scheme will not properly copy over the headers to the email client.[5]
A number of security issues are mentioned inRFC 6068, one of them being roboticaddress harvesting. Mailto constructs are locatable within HTML pages by automated means which typically include the use ofDOM constructs orregular expressions. Addresses harvested by such means are liable to be added tospammers' mass-mailing lists and thus to receive large amounts of unwanted mail.
While methods exist to "harden" mailto links against harvesting—address munging andJavaScript-based addressobfuscation among them—these protections can be circumvented by sufficiently sophisticated harvesting robots. Other techniques, like walling the address behind aCAPTCHA or similar "humanity check", provide security on par with that available for other contact methods, most notablyweb forms, which experience similar challenges with preventing spam.