How do I set a subject in a "mailto:" link?

Short Answer

There is only one safe method of assigning a subject to a mailto: link via HTML and that is by using the <A> tag's TITLE attribute. Note that this method does not work on all browsers (including all versions of Netscape Navigator as of this writing) but at least, it does not "break" any browsers as do some other "methods" of assigning a subject. Note, also, there are safe, non-HTML, ways of insuring a subject, but not via a mailto: link.

Long Answer

Abstract

Oftentimes, the question arises as to how a web author can assign a subject to an EMail message via a mailto: link. Often, this is useful so as to allow the EMail recipient to filter incoming EMail based on the subject of the EMail. This FAQ will discuss several methods of attaining this goal.

The Mailto URL According to the Specs

Before we delve into the different "solutions" and why they are or are not valid, let's take a brief look at the specification for a mailto URL. RFC 1738, the Request For Comments that defines the proper structure of the various URLs (Uniform Resource Locators) found on the Internet, defines, in section 3.5, the MAILTO URL as follows:

A mailto URL takes the form:

mailto:<rfc822-addr-spec>

where <rfc822-addr-spec> is (the encoding of an) addr-spec, as specified in RFC 822 [6]. Within mailto URLs, there are no reserved characters.

RFC 822 defines the encoding of an addr-spec as follows:

addr-spec = local-part "@" domain

Without going into an in-depth discussion of how to translate this, note that domain is defined as being made up of one or more sub-domains, each separated by a period. This means that a valid addr-spec is of the form user@sub.dom.

Assigning a Value to the Subject: Field (Safely)

In HTML, there is only one completely safe method of assigning a specified value to a mailto: link's EMail message. This solution, however, is not supported by some browsers (including all versions of Netscape as of this writing). However, while it may not work on all browsers, it will not cause any browsers to fail and is, therefore, regarded as the best solution to this problem. This solution makes use of the <A>nchor tag's TITLE attribute as follows (note the bold text):

<A HREF="mailto:user@domain.dom" TITLE="Subject">Link Text</A>

This solution is safe because it does not try to add any extra information within the mailto URL. Rather, it relies on an attribute of the <A>nchor tag, TITLE, to inform the browser of the author's desire that a specific subject be included in the EMail message.

Assigning a Value to the Subject: Field (Unsafely)

There is another common means of assigning a value to an EMail message's subject field. This is done via a kludge developed by Netscape that causes most other browsers to fail. It is accomplished by constructing the link as follows (note the bold text):

<A HREF="mailto:user@domain.dom?Subject">Link Text</A>

The idea behind this form of including the subject is that, when resolved, the question mark in the above URL should be read as a space (as when passing parameters to a CGI program). However, as the resolution of a question mark to a space occurs server-side and not client-side, most web browsers assume that the question mark, and everything that follows it, is part of the EMail address. For that reason, the EMail often never makes it to it's intended recipient.

Assigning a Value to the To: Field (Safely)

Because the main goal of assigning a value to the subject is to give the recipient the ability to filter incoming messages it is also useful to discuss other ways of allowing the recipient to filter incoming EMail. One such method is to add a specified value to the To: field. One means of accomplishing this is by constructing the link as follows (note the bold text):

<A HREF="mailto:user+subject@domain.dom">Link Text</A>

This method is valid according to the appropriate RFCs and can be used for recipients with suitably-configured local delivery. Note that not all mail delivery systems can handle this format, but you should easily be able to test whether your local system can handle it (by sending yourself an EMail message with the above addition). If it does work on your local system, it is guarenteed to work from all senders as it is only the local system that looks at the "local-part" of the EMail address.

A Second Method of Assigning a Value to the To: Field (Unsafely)

Again, because the main goal of assigning a value to the subject is often to give the recipient the ability to filter incoming messages it is also useful to discuss other ways of allowing the recipient to filter incoming EMail. Should the above solution not work on your local system, there is another means of adding a subject to the To: field. It is accomplished by constructing the link as follows (note the bold text):

<A HREF="mailto:user@domain.dom (Subject)">Link Text</A>

This is a valid means of including a value as RFC 822 allows for the inclusion of a parenthesized comment within an EMail address. However, this solution is considered unsafe because it causes at least one browser (IBM WebExplorer) to fail. Also, this method does not actually assign a value to the EMail's To: field, but does allow EMail programs to filter messages based on text contained within the To: field.

Assigning a Value to the To: Field (Safely)

A variation of the above method is to place the parenthesized subject before the "@" symbol. The advantage to this variation over the first is that a naive algorithm to determine the recipient's domain is more likely to succeed because the subject is included as part of the username instead of being included as part of the domain. An example of this form follows (note the bold text):

<A HREF="mailto:user(Subject)@domain.dom">Link Text</A>

Forms

The only safe and guaranteed method of specifying a subject within an EMail message is to pass it back, via an HTML FORM, to a CGI program on the server that then generates the EMail message adding the appropriate value as the subject. This method is completely safe and is completely guaranteed but is more of a hassle to implement due to the requirement of a back-end CGI program to process the FORM data as desired.


[Section Index] [Home Page]