Re: header-munging

[Keith Moore <[e-mail]>]

> > But the time when the send button is pushed is NOT necessarily the
> > same as the time that the message is posted to an SMTP server,
> 
> It's the closest available approximation. I agree that a user who wants
> a better approximation should acquire higher-quality software.

The question in my mind is not whether this works sufficiently well in
some cases, but whether it works sufficiently well to recommend for
general use in the Internet for the forseeable future.  Given the
growing popularity of disconnected clients, I believe it will not work
sufficiently well, and that the use of this kind of fixup should not
be encouraged.

But if the biggest problem that this caused was an occasionally
incorrect date, we wouldn't be having this discussion.


> > The SMTP server is NOT generally able to determine the domain of 
> > the sender.
> 
> This is a frivolous objection.

No it's not.  Again, I'm concerned with what practices to recommend or
discourage for the Internet.  Specific solutions to specific problems,
including SMTP fixups, are fine for people who are knowledgable enough
to know when they should be applied and what their limitations are.

But at present we have frequently occuring operational problems with
Internet mail that are caused by a misapplication of this very
technique.  I don't want to encourage it further.

> > In other words, the SMTP server doing the fixup has to know when it
> > has better information than the sender himself.
> 
> Nonsense. It is providing a _default_ domain. Users who are happy with
> the default can use it. Users who aren't can override it.

And if there's a significant chance that the SMTP server is providing
the *wrong* domain, it's botching the message.  

Users may indeed be happy with what they think their mail system is
doing, but most users aren't aware enough of what the mail system is
really doing to have a useful opinion.

If we really want users to be happy, we can fix up their envelope
return addresses to be unreplyable.  That way, they will never be
annoyed by nondelivery reports!


> > The reason I keep harping on this is that I see a
> > significant number of failures which appear to be caused by SMTP
> > servers that rewrite addresses.  The failures usually get detected
> > only by an offsite recipient,
> 
> Let's get some specifics. Are you talking about this type of problem?
> 
>    Sender: joe ---> fast SMTP server ---> sendmail ---> Sender: [e-mail]
>    (at brl.mil)     (at brl.mil)          (at utk.edu)          (wrong!)

No, I don't have the 'C' flag set on my sendmail mailers.

I'm talking about this type of problem:

Joe's MUA         SMTP server
(at foo.com)      (at foo.com's ISP, zot.net)
Sender: joe  ---> Sender: [e-mail] ---> ...

and this type of problem:

Joe's MUA            SMTP server
(at foo.com)         (at foo.com's ISP, zot.net)
Sender: joe@foo ---> Sender: [e-mail]

and this type of problem:

Keith's MUA            SMTP server
(at a pop client)      (at utkux1.ns.utk.edu)
To: [e-mail] ---> To: [e-mail]

(Though in this last case, the mail eventually bounces to me, so at
least I'm aware that there's something broken.  In the other cases,
the mail goes to Joe's recipients, who can't reply to the message.
Joe may wonder why he rarely gets replies from the outside world, but
as long as he gets *some* mail, he might not notice enough to complain
about it.)

> The situation changes completely when you replace the first SMTP link
> with the mail-injection protocol that we're discussing. Then Netscape
> isn't doing anything wrong. The server will fix up the Sender address.
> The SMTP violations disappear. Everybody's happy.

> > There's a general principle here: don't add information to a document
> > unless you're an authoritative source of that information.
> 
> This ``general principle'' denies that defaults are ever useful.

Context-dependent defaults are indeed hazardous.  The sender may
assume one default value, while the the SMTP server assumes a
different one.

Keith