Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!blake!ogccse!schaefer
From: schaefer@ogccse.ogc.edu (Barton E. Schaefer)
Newsgroups: comp.mail.misc
Subject: Re: Replying to mail... is there a general theory?
Message-ID: <3724@ogccse.ogc.edu>
Date: 12 Jul 89 18:10:06 GMT
References: <3483@portia.Stanford.EDU> <207@unmvax.unm.edu>
Reply-To: schaefer@ogccse.UUCP (Barton E. Schaefer)
Organization: Oregon Graduate Center, Beaverton, OR
Lines: 81

In article <207@unmvax.unm.edu> mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes:
} In article <3483@portia.Stanford.EDU> joe@hanauma.stanford.edu (Joe Dellinger) writes:
} >
} >	My question is: what's the best way to get a return address
} >out of a message? It seems that I should use either the address on
} >the "From" or "From:" lines, but which is correct? Neither works all
} >the time. Here are some samples:
} 
} Actually, you should use, in order of preference, the following:
}   Reply-To:
}   From:
}   Sender:

Actually, this is incorrect.  In section 4.4 of RFC822, "Automatic use
of From / Sender / Reply-To", the statement is explicitly made that
"The `Sender' field mailbox should NEVER be used automatically, in a
recipient's reply messge."  (emphasis theirs)

In the same section, it is stated that the Sender: field should be used
for sending any notices of transport or delivery problems.

Joe is correct that Reply-To: should be preferred to From: if both are
present.

} Once you've selected the correct field, do the following:
}   Drop everything in parentheses (they nest)
}   If there are <> in what's left, take what's inside the <>

Wrong, sort of.  You should take the <> and everything inside (that is,
don't discard the <>).  Some MTAs may require that the <> be dropped, but
those MTAs are broken.  The <> are required for parsing of some legal
addressing forms, and if you remove them, somebody along the way probably
won't like it.

}   Else, take whatever's left.
} 
} That will work.  Honest.  You NEVER need the From_ line.  My MUA just
} dumps them on the floor.

This ought to be correct, but unfortunately it varies depending on how
the mail got to you.  MTAs that may have handled the message during
its trip are sometimes misconfigured and will scramble the From: field.
I've never seen a Reply-To: get scrambled, so you're probably safe if
you find that one--provided that your MTA knows how to reconstruct any
missing path (this is a problem only for UUCP connections, it shouldn't
be necessary if all parties are on the Internet).

However, it usually isn't possible for an automated system to tell
whether the From: line has been scrambled.  You have to look at it
in context--for example, the sequence of Received: headers may show
that intermediate MTAs handled the message in a different order than
the one that normal parsing of the From: address would produce.  So
you're best off using Reply-To: / From:, and be prepared to handle
bounced messages.

In article <1581@marvin.Solbourne.COM> dce@Solbourne.com (David Elliott) writes:
} In article <207@unmvax.unm.edu> mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes:
} 
} What about Return-Path:?  I modified my MH configuration files
} to prefer that because it seems to be right more of the time
} than any of the others.
} 
} For example, when stuff gets sent through sites like pyramid
} and nbires, the From: line gets left alone, but Return-Path:
} is modified.

This is correct behavior.  Return-Path: is the only field that an MTA has
license to modify.  (It can add Recieved: lines, and the From_ line at
the top is a binmail / sendmailism, so those programs can munge it as
they like.)  In fact, the MTA is supposed to add Return-Path: at the time
of final delivery.  However, the Reply-To: field is still to be preferred
for directing replies, because it is specified by the message originator.
He may want the reply directed to a different mailbox than the one in
either the From: or Return-Path: lines.

Return-Path: should be at least as reliable as From_, probably more so.
-- 
Bart Schaefer           "And if you believe that, you'll believe anything."
                                                            -- DangerMouse
CSNET / Internet                schaefer@cse.ogc.edu
UUCP                            ...{sequent,tektronix,verdix}!ogccse!schaefer