🚀 go-pugleaf

In article <1992Aug6.153531.30349@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
>  Just a moment - this is just plain WRONG!

Correct.  And also an excellent argument against mailers such as
sendmail, which make it easy to muck with headers.  Headers are
standardized enough now that you shouldn't be able to modify the
header-generation code without making source-level changes in the MTA.
Tends to discourage people from making their own "improvements" in the
standard headers.  It also will prevent some sites (you know who you
are) from munging a perfectly fine RFC-822 "From:" address into some
strange hybrid bang-path address when the message goes over a UUCP
link.

>But the ENVELOPE addresses are used purely for transmission and similar
>purposes, and the user name has no place in envelope addresses.  The
>"From " line contains an envelope address.  It is, for example, the

Well, not quite.  The From_ line (as it is frequently called, to
distinguish it from the RFC-822 From: line) may sometimes contain the
envelope address, but is not guaranteed to.  The envelope address is
the address passed on the rmail command line by the remote system's
uux, or the address in an SMTP "RCPT TO" command.  The envelope
address, just like in paper mail, does not necessarily appear anywhere
in the actual messgae, although it frequently does.  The From_ line,
in fact, does not even have to exist in an RFC-822 message -- and
frequently does not.

The From_ line is an old UUCP-specific "from" header, back before the
days when RFC-822 addressing on UUCP was common, and before the days
when people had domain-capable mailers processing UUCP mail.  The
format of the line is

From hosta!hostb!hostc!user Mon Apr  1 00:00:00 1989 remote from host

The "remote from host" part is optional.  If it exists, then you can
reconstruct the path that the message took getting to you by
prepending the "remote from" name to the bang-path after the From_
part.  If not, then the return path is simply the path after the
From_.  The date is in the format that Unix ctime(3) puts out, but
without the trailing newline.  (Note in particular that the date
format is not nearly as free-form as that of an RFC-822 Date: header.
On the other hand, I don't believe that anyone has yet written a
completely correct parser for RFC-822 dates.)

Unfortunately, the path in the From_ header is no longer a reliable
indicator of the path that the message took to get to its destination.
In particular, there are certain machines on the Internet with no
concept of UUCP-style addressing, which do not update the From_ header
correctly.  Thus, mail programs should only use the path in the From_
header in the absence of RFC-822 return addresses.

However, the fact that all mail messages used to start with the
characters "From " means that a lot of mail software decided that this
would be a good intermessage delimiter.  This decision was probably
also influenced by the fact that the original AT&T /bin/mail program
used it as such.  The problem with this, of course, is that having the
word "From" appear at the beginning of a line is not a very unusual
situation in a lot of mail messages.  Some software gets around it by
prefixing a "From " in the first column with a greater-than sign
(">"), but this is an ugly hack.  Two better ways are to use the MMDF
method (each message is preceded by and followed by a line with four
^A characters (0x01) on it), or to use the MH method (each message is
in its own file).  Too bad MMDF and MH both have their own set of
problems, making them impractical for a lot of sites.

-- 
Marc Unangst                | Real men don't make backups.  Real men never
mju@mudos.ann-arbor.mi.us   | accidentally delete files that they're going
<backbone>!sharkey!mudos!mju| to need later.