Contact

There are three ways to let site visitors send you e-mail:

Truth

For mailto: links to work, your browser must be connected to an e-mail client (such as Outlook) on the user's system.  Some systems (e.g. libraries) do not have such a client installed.

Users are usually familiar with the e-mail client interface on their own systems, since it is the same one they use for sending e-mail (unless they use a web-based e-mail system).

E-mail clients typically insert the user's e-mail address automatically from a configuration file.

E-mail clients often include capabilities such as spellcheck, priority setting, signature insertion, attachment of other files, printing, and retention of a copy of sent messages.

Mailto: links expose your e-mail address to anyone who looks at the source code for the page. 

Forms depend on a program running on your server.  You must either write this program or get it from someone else and your ISP must permit you to install and run it.  Some such programs require that the target e-mail address be included in the HTML for the page using the form; this exposes your e-mail address to anyone who looks at the source code for the page and to automated processes which are collecting e-mail addresses for spammers.

Contact forms present the user with an interface which is different in appearance from their normal e-mail client.  This interface can include prompting for specific information and can make it mandatory that the user provide a response to specific items.

Contact forms require that the user type their own e-mail address into a field, so that you can reply to them. 

Contact forms generally do not provide spellcheck, priority setting, signature insertion, attachment of other files, printing, or retention of a copy of sent messages.

Nothing prevents the use of both mailto: and a form on the same page.

Consequences

Mailto: will not work at all if there is no mail client configured on the system.

If you expose your e-mail address, it will be found by programs called 'harvesters' and will be added to a list of target addresses used to send you 'spam' e-mails.  There are several techniques for obscuring your address to fool the harvesters.  None of them work.

Faced with a form that requires them to enter their e-mail address, some users will make mistakes and you won't be able to reply to them. 

Faced with a form that mandates the entry of several pieces of information, or which offers no method for retaining a copy of what they are about to send, some users will just go away.

Poorly-designed forms-processing code can be used by spammers to send messages which will appear to have come from you.

Recommendations

The author prefers contact forms, provided the code that supports them takes the user's needs into consideration.  See the requirements list below.

Tips

  1. Before exposing your e-mail address, make sure you have good spam filtering, either (preferred) from your ISP or installed on your own system, or both.
  2. If you use someone else's forms-processing code, check around the web to make sure it isn't vulnerable to preemption by spammers.
  3. If you use a form, ensure that the code that supports it meets the following requirements:
    1. 1.0 The page displaying the form itself:
      1. 1.1 Should provide the user with a clear indication of any syntactic restrictions on the data to be entered into a field (min-max length, numeric-only, etc.) ['Required' is another way of saying 'minimum length > 0'.]  Such restrictions should be minimized.
      2. 1.2 Should inform the user that the option to receive a copy of the completed form is available.
    2. 2.0 The code (both client and server-based) which processes the form:
      1. 2.1 Should retain and redisplay all data entered by the user until either:
        • the form has been successfully processed.
        • the user has abandoned submission of the form.
      2. 2.2 Should clearly identify what is wrong with data that was entered incorrectly.
      3. 2.3 Should provide the user with the option of retaining a record of the communication, in a way that integrates gracefully with the user's mail client.
        1. 2.3.1 The implementation should discourage misuse by spammers.
      4. 3.0 Both the form and the underlying code:
        1. 3.1 Should minimize their dependence on a specific user environment (presence of JavaScript, window size, etc.).
  4. If you elect to use mailto:, also display your e-mail address on the screen.  This will allow the user of a system which does not have a mail client set up to copy your e-mail address onto a scrap of paper for later use.

Index

Last revised 10 Mar 2006