Subjects in Mailto: URLs
= Index DOT Html by Brian Wilson =

Main Index | Element Index | Element Tree | HTML Support History
The Problem | The Original Syntax | Redefining 'Mailto:' URLs
Syntax Support Details | Advantages and Disadvantages



The Problem
The E-mail addressing protocol (RFC 822, Aug. '82) allows for the specification of many fields which give the sender control over a variety of sending options and meta-informational content.

Some message headers mentioned in RFC 822:
  'To', 'cc', 'bcc', 'Subject', 'Keywords',   'Sender', 'From', 'Date', 'Received', etc.
[See RFC 822 for more information on these and other message header fields.]

You may sometimes see a mailto URL of the form:
<a href="mailto:foo@bar.com?subject=test%20subject">e-mail me</a>
or something similar. Netscape was the first browser to extend the mailto: URL to allow control over message headers in this manner (in Netscape 2.0 and above.)

Using this syntax will initiate the default email program in Netscape populating the 'To:' field as well as the 'Subject:' field. But, aside from significant historic support by Netscape, only some browser versions support this syntax. In many older browsers this form of mailto: URL will not work - it will only populate the 'To:' field with everything after the 'mailto:' string (in the above case it would put 'foo@bar.com?subject=test subject' in the 'To:' field, which would bounce when sent.)

The Original 'Mailto:' Syntax
Until recently, specifying anything other than the "To:" mail header field in 'Mailto:' URLs was illegal syntax (although it appears that support for multiple addresses is possible by separating them with commas) according to the original specification for URL addressing (RFC 1738, (Dec. '94.) Sect. 3.5 precisely defines the Mailto: URL scheme:
"The mailto URL scheme is used to designate the Internet mailing address of an individual or service. No additional information other than an Internet mailing address is present or implied."
It goes on to formally define the 'Mailto:' syntax:      
'mailto:' [RFC 822 Address spec]'     
where '[RFC 822 Address spec]' = [local-part] "@" [domain] ("," [local-part] "@" [domain])*
Example:
<a href="mailto:address@test.com">mail me</a>
      

A New RFC Proposal: Redefining the 'Mailto:' URL Scheme
RFC 2368 was released in July, 1998 (interesting to note that one of the co-authors is from Netscape.) It allows any and all message header fields to be specified in a 'Mailto:' URL. As with other URL forms, special reserved URL characters must be encoded - in particular, parentheses, commas, and the percent sign. The RFC states:
"For greater functionality, because interaction with some resources may require message headers or message bodies to be specified as well as the mail address, the mailto URL scheme is extended to allow setting mail header fields and the message body."
RFC 2368 Proposed New Syntax
   "mailto:" [to] ( "?" [header] ( "&" [header] )* ) ?
    where to = [RFC 822 Address spec] (see above)
    where header = [RFC 822 header] "=" [RFC 822 header value]
Example:
(Automatically fills in the title and body of the e-mail)
<a href="mailto:address@test.com?subject=test&body=I%20agree%20with%20what%20you%20said!">mail link</a>


Syntax Support Details
Old Syntax: [IE1|M|N1|O2.1|S1]
New Syntax: [IE4|M|N2|O3*|S1]

Only the latest versions of other browsers, such as IE 4, Opera 3.x and the latest Lynx support this new 'Mailto:' syntax. (I've been told this crashes some versions of Netscapes, but older versions just concatenated the mail header field info to the mail address.)

[*] Opera 3 only partially supports the new syntax - it thinks that all extra header info is meant to be a 'Subject:' header. It also doesn't support escaped characters.

Weighing the Advantages and Disadvantages
Pros: Allows addressing of all message fields
Cons: Non-supporting browsers will only populate the 'To:' field with all the information in the mailto: line. Sending mail to such addresses will fail.
Advice: Unless you can guarantee what browsers/email clients your readers are using, say on an intranet environment, or you can warn them of the potential problems if they are using non-supporting browsers, recommend against using the newer syntax until it becomes more widespread.


Boring Copyright Stuff...