[ On Friday, August 6, 1999 at 12:20:17 (+0200), Paul Slootman wrote: ]
> Subject: Re: [Exim] Content-Length header?
>
> While dredging around on the net for more info, I read somewhere that
> there are *very* little requirements attached to that "From " line
> besides the fact that it must begin with "From ". However, I've looked
> at the sources of a couple of things that read the mailbox (mutt, qpopper
> and netbsd's mail).
Strictly speaking the most widely accepted interpretation of the message
separatator for Unix-format mailboxes is actually "\nFrom ". The extra
newline is critical with Modern BSD mail(1) and mail.local(8), as well
as some other MTAs which are much more restrictive in requiring the
newline and will *not* prefix a "From " at the beginning of a line in
the body with a '>'.
The closest definition, standards wise, of Unix mailbox format is in
RFC-976 (UUCP Mail Interchange Format Standard). This is where you'll
find info about the *interchange* format (i.e. what's exchanged between
two UUCP systems). However except for a few limitations these are also
effectively the formats of Unix mailbox files too. Note that the
" remote from system" trailers were always removed by all UUCP mailers I
ever encountered and they should never appear in a mailbox. (I once
considered keeping this info when I was hacking on smail-2.7, but was
warned by several people that it would be a "Bad Idea(tm)." Most Unix
mailers also always collapsed multiple "From " lines, though I'm sure
I've seen some somewhere that didn't. Someday I should write a little
awk script to go through my ancient mail archives and search for
evidence of this...
Kyle Jones, author of ViewMail (an emacs-based mail reader) has
discovered that indeed some systems still only look for any line
beginning with "From ". He has this to say:
Messages in From_ folders are separated by the two newlines followed
by the string \"From\" and a space. Messages in BellFrom_ folders
are only required to have a single newline before the \"From\"
string.
Since BellFrom_ and From_ folders cannot be reliably distinguished
from each other, you must tell VM which one your system uses by
setting the variable `vm-default-From_-folder-type' to either From_
or BellFrom_.
He also says it's generally only old SysV machines that suffer from
BellFrom_ disease.
Now if you look at Kyle's code you'll find that he actually looks for a
pattern of "^From .*[0-9]$" for both variants, meaning that he also
expects the line to end in a digit.
Note also that even though any un-prefixed "From " line will separate
messages, the default for "BellFrom_" mailboxes is still to have a blank
line there also -- it's just that the mail reader *implementation*
doesn't check for the blank line, partly because in that old
implementation they also always prefixed *every* "From " in the body,
not just those without a leading blank line. I'm reasonably certain
the "Bell" moniker is misleading and should be "ATT-USG" or something
similar because I don't think V7 ever had this problem.
> It looks like bsd's mail is the most restrictive (and probably the one
> to consider as a guide, as bsd originated this format). I.e. no timezone,
> and return-path mandatory.
BSD's mail program may be one of the most "restrictive" (i.e. the most
strictly defined but also most forgiving) but it's certainly not the
originator of the format. You can lay that blame firmly on the founding
fathers of Unix -- V7, and maybe even V6 had a "mail" program that was
used to send and receive e-mail via a spool file that was stored with
the "\nFrom " separator.
In the final form Research Unix V10 (i.e. UPAS) calls the separator
lines "postmarks" and simply says that when mail is being read from
stdin all postmasrds are prefixed with '>'. These postmark lines are in
fact "From " lines (I've never seen any other header in any mail I've
ever received from anyone using only V10 native tools).
(BTW, I think this discussion has happened several times in this venue
now! ;-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@???> <robohack!woods>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
