🚀 go-pugleaf

Eliot et al, the ZMailer action in the case of the recent Sendmail flap would
have been essentially as Dennis described: completely nuke the bad address
header and replace it with a correct synthesized one and an opaque header
complaining about the error.  This action corresponds to none of the choices
presented but it is, I think, robust.  Of course, if a badly-formed message
had been submitted to a ZM in the first place, it would have been spit back
right there with a graphic admonition (literally, and no, it only took a day
:-).

Dennis says:
>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.

Scared, actually.  I briefly considered sending an error message back
to the postmaster at the originating site (which still would not give
the Sendmail scenario, btw).  For about 2 seconds.  There is an
incidental problem of what to do when such a message bounces (SMTP
"Mail from:<>" being irrelevant since no other transfer protocol has
the concept of `absense of sender') and I didn't want to think up some
magic loop-avoidance scheme.

What really convinced me to NOT do this was that I don't have a
particular desire to be hated by all the world's users and postmasters.
[begin slight exaggeration for emphasis] 90% of broken hosts don't have
a postmaster.  90% of the remainder have postmasters that don't want to
know and don't care.  90% of those that do, don't know what to do to
fix it, or cannot due to site policies ("We'll run whatever the vendor
provides, period.").  That leaves about 1 per thousand of hosts out there
that will be able to fix problems due to such a notification.  Lets see,
that makes around 500 hosts on the internet.  They're probably just fine
already and no-one needs to tell them... so what's the point.

I'm resigned to hoping that recipients seeing flagged syntax errors
will get curious and ask their own postmasters, or their correspondents,
and that very slowly the general level of awareness may be raised.

Karl, as for the rather draconian enforcement of the rules: I think of
a protocol spec as an obligation agreed to by the MTA implementation of
the protocol.  Namely: "If I receive a <specification>-conforming
message, then it will be understood properly and processed."  If there
is some kind of protocol error, all bets are off.  This general
description is the only assumption you can make about a remote MTA's
behavior.  Therefore you *really* want to eliminate the "all bets are
off" possibility.  You do that by making very sure that messages sent
out are as spec-conformant as possible.  In the case of RFC822 the
major part of the protocol spec is the syntax.  It is also the only
part that is universally applicable to '822-like environments.  Hence
the pendantic syntax checking.  The RFCs also define Internet semantics
which fall on their face when dealing with non-Internet environments.
Therefore address semantics are generally left to the graces of a mail
guru who one hopes has a deep hatred for all things mailish.  Otherwise
they not be guru yet.

rayan
--
"It's 11pm, does *your* Sendmail deal properly with mail groups?"

Novice:			What's "Sendmail"?
Beginner:		What's a "mail group"?
User:			What do you mean "properly"?
Expert:			Hmm, never thought of that.
Wizard:			YES!
Guru:			Like, who cares...
Honeyman's corollary:	It's only mail.