Re: header-munging

"D. J. Bernstein" <djb@koobera.math.uic.edu> Tue, 06 August 1996 23:56 UTC

Received: from ietf.org by ietf.org id aa23961; 6 Aug 96 19:56 EDT
Received: from cnri by ietf.org id aa23957; 6 Aug 96 19:56 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa17497; 6 Aug 96 19:56 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id TAA12809; Tue, 6 Aug 1996 19:16:13 -0400
Received: from koobera.math.uic.edu (qmailr@KOOBERA.MATH.UIC.EDU [128.248.178.247]) by list.cren.net (8.6.12/8.6.12) with SMTP id TAA12760 for <ietf-smtp@list.cren.net>; Tue, 6 Aug 1996 19:15:57 -0400
Received: (qmail-queue invoked by uid 666); 6 Aug 1996 19:20:01 -0000
Message-Id: <19960806192001.24837.qmail@koobera.math.uic.edu>
Date: Tue, 06 Aug 1996 19:20:01 -0000
X-Orig-Sender: owner-ietf-smtp@list.cren.net
Precedence: bulk
Sender: ietf-archive-request@ietf.org
From: "D. J. Bernstein" <djb@koobera.math.uic.edu>
To: ietf-smtp@list.cren.net
Subject: Re: header-munging
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

> would have to try the
> new port number, and if it timed out, use the standard SMTP port.

I don't see how that could ever be useful.

_If_ the server accepts broken messages on the new port, there's no
problem. Retrying is a bad idea here.

_If_ the server and client have an out-of-band agreement that the server
will fix up random messages on port 25, then the client can always use
port 25. Retrying is a bad idea here. (This is a common situation today,
and there's no reason to change it if both sides are happy with it.)

_If_ the server hasn't agreed out-of-band to accept broken messages, and
doesn't agree to accept broken messages on the new port, then the client
is out of luck---just as it would be with your SMTP extension. Neither
the client nor the server is willing to produce a valid RFC 822 message.
Retrying is a bad idea here: the client must not send a message through
that server at all. (This situation arises occasionally with clients
that use servers without their permission.)

Remember, the reason for the client to use the new port is that the
relevant server administrator says ``make sure you configure it to use
port XXX for outgoing mail.'' The reason the administrator would say
such a thing is that his port 25 server is _not_ willing to fix up
broken messages.

Exactly what situation are you worried about?

> Also, the draft includes techniques for guessing that the message is in
> fact a submission even if the client doesn't use the extension.

Indeed, some qmail servers now have an out-of-band agreement that
they'll fix up messages from clients at certain IP addresses.

However, most qmail hosts have no interest in wasting the time on this.

If you send a broken message through them, they'll pass it along without
even looking at it (or bounce it, if the recipient domain name isn't a
FQDN).

If the receiver is running sendmail, sendmail will corrupt the message.
For example, the _receiver's_ domain name will be appended to the header
field ``Sender: joe''.

---Dan