🚀 go-pugleaf

I believe coding for weird mail headers is wrong.  I suggest you follow the
rules in the RFCs and leave it at that.  Why?  Because most screwed up
mail headers -- for example, something like this:

	From:  host!host2!host3::other!thing@something!else

are too screwy to be usable anyway.  One of the things wrong with the
Berkeley Mail program (in 4.2) was that it tried to be smart about
the headers (it had built-in smarts about BerkNet, etc... kind of like
the finger program expecting people to be in one of 3 Halls at UCB).

I don't think you want to handle any screwy headers.  You software will
probably guess wrong anyway.  Mail handlers along the way have the
responsibility for maintaining usable reply addresses, etc.

Fred

I'm not intending to parse From:, Sender:, Reply-to:, or
Maybe-If-I'm-Lucky-It'll-Get-To: - if the address is broken enough that our
professionally maintained mailer can't cope with it, I doubt that some code
I'll leave here when I graduate can...

Rather, I'm worried about things coming in that will break trying to read
the header - stuff like a full name and no address in From: - which I've
seen coming from PSUVM occasionally.  Things like 100-address To: lines,
and extremely long Subject: lines that people have sent.

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!

Bruce Howells,   beh@bu-pub.bu.edu  |   engnbsc@buacca (BITNet)
  - Not an official document of Boston University Information Technology

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

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...

Ordinary good coding practices should take care of these types of
problems.  If you assume that lines may be infinitely long, and may
contain characters of *any* of the 256 possible values (including
ASCII NUL), then you should be protected from memory faults and
surprise truncations.  After that, insist that all errors detected
during parsing be handled in some sane manner.

Unfortunately, this is a lot easier to say than to do.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: Logicon doesn't even know we're running news.
    Internet: Makey@Logicon.COM    UUCP: {nosc,ucsd}!logicon.com!Makey

Frederick M. Avolio writes:
> I believe coding for weird mail headers is wrong.

I sure hate to contradict you but you're wrong. The golden rule of smtp
is, "Be liberal in what you accept and conservative in what you send."

		Craig

In article <7154@dog.ee.lbl.gov> leres@helios.ee.lbl.gov (ucbvax!leres for uucp weenies) writes:
>I sure hate to contradict you but you're wrong. The golden rule of smtp
>is, "Be liberal in what you accept and conservative in what you send."

Actually thats the golden rule of all TCP applications, as stated in
RFC 1123. It applies generally to most things like that tho.

Dylan.
-- 
Matthew J Farwell                 | Email: dylan@ibmpcug.co.uk
The IBM PC User Group, PO Box 360,|        ...!uunet!ukc!ibmpcug!dylan
Harrow HA1 4LQ England            | CONNECT - Usenet Access in the UK!!
Phone: +44 81-863-1191            | Sun? Don't they make coffee machines?

In article <1990Sep22.174312.29336@ibmpcug.co.uk>, dylan@ibmpcug.co.uk (Matthew Farwell) writes:
: In article <7154@dog.ee.lbl.gov> leres@helios.ee.lbl.gov (ucbvax!leres for uucp weenies) writes:
: >I sure hate to contradict you but you're wrong. The golden rule of smtp
: >is, "Be liberal in what you accept and conservative in what you send."
: Actually thats the golden rule of all TCP applications, as stated in
: RFC 1123. It applies generally to most things like that tho.

Unfortunately I've seen this phrase abused by both the sender and the
receiver implementers.  The sender says the receiver should be more 
liberal in what they accept.  And the receiver says the sender should
be more conservative in what they send.  Either that or they say 
"It's not a bug, its a FEE_TURE (as in fee_cees)."

-- 
Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey  07102
uucp !andromeda!galaxy!argus!ken *** NOT ken@bellcore.uucp ***
bitnet(prefered) ken@orion.bitnet  or ken@orion.njit.edu

In article <2016@argus.UUCP>, ken@argus.UUCP (Kenneth Ng) writes:
[ "Be liberal in what you accept and conservative in what you send."]

> Unfortunately I've seen this phrase abused by both the sender and the
> receiver implementers.  The sender says the receiver should be more 
> liberal in what they accept.  And the receiver says the sender should
> be more conservative in what they send.  Either that or they say 
> "It's not a bug, its a FEE_TURE (as in fee_cees)."

Kenneth, this is an easy one to solve.  You should be liberal because
people sometimes screw up, but in a case like the above, either the
address is standard (so the receiver is in error) or the address is
non-standard (so the sender is in error).

But people who have to use the system don't care who's guilty; they
just want it to work.  This is why the receiver shouldn't be pedantic
about rejecting things that commonly appear for historical reasons
(i.e. they were allowed in the previous (maybe ad-hoc) standard).

--
Joe Buck
jbuck@galileo.berkeley.edu	 {uunet,ucbvax}!galileo.berkeley.edu!jbuck