Newsgroups: comp.mail.misc
Path: utzoo!utgpu!dennis
From: dennis@gpu.utcs.utoronto.ca (Dennis Ferguson)
Subject: Re: Interesting header/error message
Message-ID: <1991May17.225350.23454@gpu.utcs.utoronto.ca>
Organization: none at all
References: <1991May13.033329.24202@chinet.chi.il.us> <1991May13.112332.20564@oar.net> <May.17.14.40.18.1991.14102@turbo.bio.net>
Date: Fri, 17 May 1991 22:53:50 GMT

lear@turbo.bio.net (Eliot) writes:
>
>karl.kleinpaste@osc.edu writes:
>
>>Rayan's mailer is unquestionably to be awarded Most Picky Mailer Ever
>>Devised, but it has the good taste to deliver anyhow, in view of the
>>wide disregard for this particular bit of syntactic pedanticism.
>
>The above situation is a recipe for disaster.
>
>Imagine, if you will, a message sent to a very large international
>mailing list with a completely trashed To: header, but with the
>envelope intact.  What is a mailer to do?
>
>	[a]	Bounce the message as undeliverable.
>	[b]	Continue to process the message, possibly logging an
>		error.
>	[c]	Continue to process the message AND send an error to
>		the sender.
>
[...]
>
>That leaves [b] (preferably logging an error message).

Actually I think [b] is what the mailer in question does.  In addition
to this it appears to remove the offending header, whatever it was,
replacing it with a fancy error message (which must have taken a week
of coding to get to come out right) in a dreaded Illegal-Object: header
and synthesizing a (syntactically correct) replacement from the envelope
if the header is one which really needs to be there.

This, of course, means only the recipient finds out about the error,
which I always thought was odd since the recipient is far less likely
to be able to do anything about it.  It appears the implementor was
smarter than I.

Passing on a message which you know contains an error is at least as bad as
sending back an error (I'd argue that sendmail has both these bugs, and
both were equally important in causing the trouble you mentioned).  If
"Continue to process the message" doesn't include fixing it up so that
downstream mailers won't see an error as well I think you are violating
the robustness principle even more seriously than you would be by bouncing
it.  Zmailer may be obnoxiously picky, but I think this is all in the cause
of robustness and is probably appropriate.

Dennis Ferguson