Custom email applications that control both ends of an email communication (the sending MUA and the receiving process) can benefit from the use of custom or userdefined headers.

When creating your own headers, keep in mind that the header name (the left side of the colon) can only consist of printable ASCII characters except colon. (Printable ASCII characters have values between 33 and 126 decimal.) Additionally, a userdefined header should start with an “X-” to differentiate it as a custom construct.

Consider an electronic commerce system that takes orders for products via the World Wide Web. An HTML form is used to collect the buyer’s information, including a credit card number. For security reasons, it is decided to remove the incoming orders from the Web server as soon as possible, so that a cracker would have nothing to find.

One solution to this problem is to encrypt the order information and mail it to an internal email address for processing. This can be done from the Common Gateway Interface (CGI) form handler on the Web server. The order (including the credit card information) is immediately removed from the Web server. If the email message was located in transit or on the mail server, it is protected by being encrypted. Once the mail is safely inside the corporate firewall, it can be automatically decrypted and routed to a program that handles order fulfillment, such as a help desk or more automated system.

In this example, user-defined headers may be used to pass information to the handling programs. Since the message body is encrypted, it cannot be read by any intervening process. Headers, however, are not encrypted and may be parsed by processes along the way.

A user-defined header (let’s call it X-Product-Type) might be created by the CGI form handler and inserted into the message. The message is then sent to a mail server (MTA). The first delivery can be to a routing process that parses the X-Product-Type header to determine whether the goods ordered are software (to be shipped electronically), physical products (to be shipped by snail mail), or both. The distribution of the message may be changed based on that information, while the message body remains encrypted. Perhaps the messages that include physical product orders go to one email address, and the software ones go to another. Orders that include both might be copied to both addresses.

Some user-defined headers are introduced by a single vendor and picked up for use by others. In this way, a header may come into common use without ever being standardized. A common but nonstandard header is X-Mailer, used to identify the MUA used to send a message. The MUA writes the header into a message before sending it. A typical example is:

X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586)

This MUA is Netscape Communicator Version 4.04, using English languages extensions and running under the X11 windowing system and the Linux operating system on an Intel Pentium chip.

Suppose that your company accepts help desk requests by email. Parsing the X-Mailer header will often allow you to guess what type of operating system the sender is using, even if she did not report that information explicitly.

User-defined headers are only useful if you control the process creating a mail message (to insert the header) and also the process parsing the mail message either en route or upon delivery (to use the information provided).

To summarize, email headers are slightly more tricky than they appear. When creating custom mail programs, please check carefully to ensure that your program is a good Internet citizen—that is, that it adheres to the standard. A complete understanding of email headers can provide much needed flexibility while ensuring that the messages that you generate will pass through a TCP/IP-based mail system without error.