Return-Path: <> Return-Path: <God@heaven.af.mil>
Messages transmitted through SMTP generally do not have Return-Path fields; the return path is transmitted out-of-band in the SMTP MAIL request. When a message is stored in a mailbox, the return path is stored in a Return-Path field. If the message is then retrieved (e.g., through POP) and sent through another SMTP hop, the Return-Path is removed and the return path is again sent out-of-band.
Some mailers, in violation of RFC 1123, fail to record the return path of a message. Subsequent bounces are sent to an invented return path, typically the header From address. This behavior is a disaster for mailing-list messages, where the correct return path is the mailing list manager, and the From address is an innocent subscriber who has no way to remove bad addresses from the mailing list. Every mailer is responsible for using the correct return path.
Received: from mail-relay.af.mil (127.193.178.241) by silverton.berkeley.edu with SMTP; 4 May 1998 14:57:55 -0000 Received: (qmail 2227 invoked from network); 4 May 1998 14:57:37 -0000 Received: from heaven.af.mil (127.193.178.247) by mail-relay.af.mil with SMTP; 4 May 1998 14:57:37 -0000In practice, SMTP servers put all sorts of badly formatted information into Received lines. It is probably best for readers to treat everything before the final semicolon as unstructured text, purely for human consumption.
A few SMTP servers don't even format the date correctly. For example:
Received: by MicroMailer 3.50a on Wednesday, 24 January 1996, 17:15:16 EST (WRONG)Invalid Received fields are also produced by the cucipop POP server.
Hop counting is a last-resort method of preventing loops: a message will bounce if it passes through too many SMTP servers.