Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!usc!snorkelwacker!apple!olivea!orc!inews!iwarp.intel.com!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.mail.headers
Subject: Re: Wanted: Messed-Up Mail Headers
Message-ID: <1990Sep08.204611.5645@chinet.chi.il.us>
Date: 8 Sep 90 20:46:11 GMT
References: <63881@bu.edu.bu.edu> <3301@decuac.DEC.COM> <63938@bu.edu.bu.edu>
Organization: Chinet - Chicago Public Access UNIX
Lines: 21

In article <63938@bu.edu.bu.edu> beh@bass.bu.edu (Bruce E. Howells) writes:

>Basically, my concern is that this thing not read in a piece of mail, try
>to parse it, choke, die, and lose the user's mail...  The
>mail-transport-agent level stuff I'm leaving to mailer - let it worry!

There is a relatively simple way to provide this kind of robustness.  Just
read the mail into a spool file before trying to parse anything.  Then the
worst that can happen is that the spool file will be left in place so that
a periodic scan can find it.  Smail 3 works this way, and takes advantage
of the queuing operation to offer a choice of foreground, background or
daemon delivery.  It turns out to be moderately complicated to keep track
of deliveries to multiple recipients to allow restarting correctly, but it
looks like Smail 3 should get it right.  It does, however, choke on certain
combinations of things that really shouldn't be in addresses (I think
multiple ::'s or something like "Thanks! path!to!user" can do it - and
yes, I've seen the latter).  When this happens, the administrator can still
attempt to fix things by hand.

Les Mikesell
  les@chinet.chi.il.us