Re: header-munging

[Keith Moore <[e-mail]>]

> > Neither one of these solves the real problem.

Indeed, I think of the problem as MUAs that generate garbage due to a
lack of information or mis-configuration by an ignorant user.  

> Right now this problem is solved by bilateral agreement: the MTA will
> take the time to fix up messages from certain IP addresses. 

I disagree that the problem is solved.  In my experience, the problem
is worsened at least as often.  That is, the MUA generates garbage,
and the MTA not only fails to mung the garbage into a reasonable
message, it makes things worse by trying.  Sometimes the MTA takes a
perfectly reasonable message and damages it.

> A separate port would solve it by IANA agreement.

No, it doesn't solve the problem in general, because the MTA is often
not in a position to supply the information (date, timezone,
fully-qualified domain for the return address) that the UA lacks.

There are of course MUAs and gateways that generate garbage even when
they have all the information they need.  This isn't due to any
failure or omission in the mail standards (unless they're so poorly
written that they're misinterpreted), but simply a failure of an
implementation to conform to the specs.  Under those circumstances,
a "fixup" server on a separate host or port could help.  But
in my experience, it's the errors due to incomplete information, not
those due to incorrect implementation, that people expect the MTA to
fix.

> Another problem I've mentioned is a very real speed problem for one
> common MTA: sendmail does a lot of DNS lookups to fix up messages from
> clients that don't want any fixups.
>
> The RELAY extension would solve this problem. An alternative solution is
> for sendmail to stop doing the fixups by default; of course, this causes
> interoperability problems, just as it does for fast MTAs.

I agree that RELAY could be helpful, and I'd like to see it pursued
independently of a SUBMIT option, SUBMIT port, or whatever.

(I *really* like the fact that it doesn't require any special
configuration for either MTAs or MUAs.)

> You seem to be concerned with a third problem: the aforementioned crappy
> MUAs often generate messages missing crucial information. (For example,
> what does a user mean by ``to: eric@cs''?)
> 
> To the extent that this is a problem, the obvious solution is for the
> MUAs to generate more information.

Yep.  And if they can't generate the right information because the
users or their sites don't supply it, then I see two ways to combat
the problem:

1. Insist that users submit messages to an alternate SMTP server (on
another host or port) that *bounces* incorrectly formatted messages.
That way, the problem gets detected early and fixed at the source.
(ISPs might find this useful for dealing with individual dialup
subscribers.)

I'll note that it's easier to deploy a solution based on an alternate
host or IP address, because this requires no code changes to the MUA.

2. Define a way for a site to easily supply config information to all
of its UAs (this doesn't help everybody, but would be useful for sites
with several machines under a common administration)

So the two approaches aren't mutually exclusive.

However, I do object to legitimizing the practice of having SMTP
servers "fix up" a message by guessing at missing information.

Keith