UNIX System Administration Handbook - Evi Nemeth [322]
2: Return-Path: eric@knecht.sendmail.org
3: Received: from anchor.cs.Colorado.EDU (root@anchor.cs.colorado.edu
[128.138.242.1]) by columbine.cs.colorado.edu (8.9.3/8.9.2) with ESMTP id
HAA21741 for 0700 (MST) 4: Received: from mroe.cs.colorado.edu (mroe.cs.colorado.edu [128.138.243.151]) by anchor.cs.colorado.edu (8.9.3/8.9.2) with ESMTP id HAA26176 for 5: Received: from knecht.sendmail.org (knecht.sendmail.org [209.31.233.160]) by mroe.cs.colorado.edu (8.9.3/8.9.2) with ESMTP id HAA09899 for 6: Received: from knecht.sendmail.org (localhost [127.0.0.1]) by knecht.sendmail.org (8.9.3/8.9.3) with ESMTP id GAA18984; Fri 1 Oct 1999 06:04:02 -800 (PST) Line 2 specifies a return path, which may be a different address from that shown on the From line later in the mail header. Error messages should be sent to the address in the Return-Path header line; it contains the envelope sender address. Lines 3–6 document the passage of the message through various systems en route to the user’s mailbox. Each machine that handles a mail message adds a Received line to the message’s header. New lines are added at the top, so in reading them you are tracing the message from the recipient back to the sender. If the message you are looking at is a piece of spam, the only Received line you can really believe is the one generated by your local machine. Each Received line includes the name of the sending machine, the name of the receiving machine, the version of sendmail (or whatever transport agent was used) on the receiving machine, the message’s unique identifier while on the receiving machine, the recipient (if there is only one), the date and time, and finally, the offset from Universal Coordinated Time (UTC, previously called GMT for Greenwich Mean Time) for the local time zone. This data is collected from sendmail’s internal macro variables. In the next few paragraphs, we trace the message from the sender to the recipient (backwards, from the point of view of header lines). Line 6 shows that the message went from knecht’s localhost interface (which Eric’s particular mail user agent, exmh, chose for its initial connection) to knecht’s external interface via the kernel loopback pseudo-device. Line 5 documents the fact that knecht then sent the message to mroe.cs.colorado.edu, even though the message was addressed to evi@anchor.cs.colorado.edu (see header line 9). A quick check with nslookup or dig shows that the host anchor has an MX record that points to mroe, causing the delivery to be diverted. Line 5 illustrates the difference between the envelope address (evi@mroe.cs.colorado.edu) and the recipient address in the headers (evi@anchor.cs.colorado.edu). See page 443 for more information about MX records. The machine mroe was running sendmail version 8.9.3, and it identified the message with queue ID HAA09899 while it was there. The message was then forwarded to anchor.cs.colorado.edu as addressed (line 4), and immediately forwarded again to evi@rupertsberg.cs.colorado.edu (line 3) because of aliasing, a mail handling feature that is described in detail starting on page 550. Aliases play an important role in the flow of mail. An alias maps a username to something else, for example, to the same user at a different machine, to a group of users, or even to an alternate spelling of the user’s name. You cannot determine why the message was diverted by examining only the example headers. As with MX records, you must seek external sources of information. Received lines 5 and 4 include the “for