UNIX System Administration Handbook - Evi Nemeth [321]
The general form of Internet mail address is
user@host.domain
where the @ separates the username from the host specification. Mail is delivered to user’s mailbox on the machine host.domain. By domain we simply mean the host’s normal DNS domain. For example, in the address evi@boulder.colorado.edu, evi is the user, boulder is the host, and colorado.edu is the domain.
See Chapter 16 for more information about DNS.
Other types of address have been used in the past. In particular, there have been several different forms of route-based addressing. We won’t describe them here in detail, since they are largely obsolete, but Table 19.4 shows a few quick examples along with their equivalent present-day forms.
Table 19.4 Examples of obsolete, route-based address types
Much of the complexity of sendmail configuration stems from the early requirement to handle such addresses. Each of these forms of addressing relies on relaying, and thanks to spammers, sites are slowly turning relaying off. The percent hack (last line in Table 19.4) is a favorite tool of spammers who are trying to hide their identity or to relay mail through your machines. If you need to deal with any of these address forms, see the sendmail documentation or the O’Reilly sendmail book for help.
Reading mail headers
Every mail message starts with several lines called headers that contain information about the message. Each header begins with a keyword such as To, From, or Subject, followed by a colon and the contents of the header. The format of the standard headers is defined in RFC822; however, custom headers are allowed, too. Any header beginning with “X-” is be ignored by the mail system but propagated along with the message. Ergo, you can add a header such as X-Joke-of-the-Day to your email messages without interfering with the mail system’s ability to route them.
Some headers are added by the user agent and some by the transport agent. Several headers trace the path of a message through the mail system. Many user agents hide these “uninteresting” headers from you, but there is usually an option to make the agent reveal them all. Reading headers is becoming an important skill as we are bombarded with spam and must sometimes try to trace a message back to its source. Here is the header block from a simple message:
From evi Wed Jan 19 19:01:11 2000
Received: (from evi@localhost) by xor.com (8.9.3/8.9.3) id TAA17820; Wed, 19
Jan 2000 19:01:11 -0700 (MST)
Date: Wed, 19 Jan 2000 19:01:11 -0700 (MST)
From: Evi Nemeth Message-Id: <200001200201.TAA17820@xor.com> To: trent@xor.com Subject: xor.mc Cc: evi@xor.com Status: R ------ body of the message was here --- This message stayed completely on the local machine; the sender was evi and the recipient was trent. The first From line was added by mail.local, which was the local delivery agent in this case. The Status header was added by Evi’s mail reader, and the other headers were added by sendmail, the mail transport agent. Each machine that touches a message adds a Received header. The headers on a mail message tell a lot about where the message has been, how long it stayed there, and when it was finally delivered to its destination. Below is a more complete dissection of a mail message sent across the Internet. It is interspersed with comments that describe the purpose of the various headers and identify the programs that added them. The line numbers at the left are for reference in the following discussion and are not part of the message. Some lines have been folded to allow the example to fit the page. 1: From eric@knecht.sendmail.org Line 1 was added by /bin/mail or mail.local during final delivery to separate this message from others in the recipient user’s mailbox. Some mail readers recognize message boundaries by looking for a blank line followed by the characters “From