Re: header-munging

"D. J. Bernstein" <djb@koobera.math.uic.edu> Tue, 24 September 1996 20:36 UTC

Received: from cnri by ietf.org id aa27948; 24 Sep 96 16:36 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa05222; 24 Sep 96 16:36 EDT
Received: from localhost (localhost.0.0.127.in-addr.arpa [127.0.0.1]) by list.cren.net (8.7.6/8.6.12) with SMTP id PAA29335; Tue, 24 Sep 1996 15:56:12 -0400 (EDT)
Received: from koobera.math.uic.edu (KOOBERA.MATH.UIC.EDU [128.248.178.247]) by list.cren.net (8.7.6/8.6.12) with SMTP id PAA29317 for <ietf-smtp@list.cren.net>; Tue, 24 Sep 1996 15:56:01 -0400 (EDT)
Received: (qmail 27979 invoked by uid 666); 24 Sep 1996 20:00:45 -0000
Message-Id: <19960924200045.27978.qmail@koobera.math.uic.edu>
Date: 24 Sep 1996 20:00:45 -0000
Sender: owner-ietf-smtp@list.cren.net
Precedence: bulk
From: "D. J. Bernstein" <djb@koobera.math.uic.edu>
To: ietf-smtp@list.cren.net
Subject: Re: header-munging
X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN

> 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 SMTP server is NOT generally able to determine the domain of the sender.

This is a frivolous objection.


Look at what happens with local mail. Consider, for example, mailx
feeding a message through qmail-inject.

qmail-inject was configured by the sysadmin with a single default domain
for everybody. Sender and recipient addresses without a domain will have
the default domain appended.

The user can override the default domain by specifying a domain. (Duh.)


The fixups being discussed here are (as Einar observed) _exactly the
same situation_.

One part of the MUA is feeding a message through another part. The
second part (in fact, qmail-inject again) fixes typical 822 violations.
To handle addresses without domains, it appends a default domain. The
user can override the default domain by specifying a domain.


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


> 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: joe@utk.edu
   (at brl.mil)     (at brl.mil)          (at utk.edu)          (wrong!)

Everyone agrees that (1) the sender (Netscape, in this case) is
producing an invalid message, and (2) sendmail, by trying to fix it, is
making it even worse.

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.

---Dan