Re: header-munging

["D. J. Bernstein" <[e-mail]>]

> So the SUBMIT extension takes real-world situations and makes them more
> deterministic.

Exactly what problem are you trying to solve?


1. A problem

Here's the interoperability problem I'm worried about.

   naive client ---> fast server ---> rewriting server

A naive client (e.g., Netscape) produces a message with several RFC 822
violations (e.g., ``Sender: joe'', missing Date, etc.) and sends it
through SMTP, in violation of RFC 821, to a fast SMTP server that
doesn't even look at the message (e.g., qmail), which passes it along to
a server that, in violation of its fundamental responsibility as an MTA,
tries to ``fix'' the header (e.g., sendmail).

The result is often a corrupted message. For example, ``Sender: joe''
turns into ``Sender: [e-mail]''.

Sometimes it's even worse: the message bounces. Unless the envelope
sender is correct (which it rarely is), the bounce never comes back.

I'm sure everybody agrees that this is a problem.

The client is violating all the relevant standards. Hopefully it will be
fixed. However, there's still a problem as long as there's still an
installed base of naive clients.


2. A solution by out-of-band agreement

Under the latest version of qmail, it's very easy to take all messages
from certain clients (identified by IP address, for example) and send
them through a fix-up program. Some hosts do this.

Of course, most hosts have no interest whatsoever in acting as a relay.
They set up qmail to reject messages addressed to outsiders. They
certainly don't rewrite messages on behalf of anyone who asks. You have 
no business sending an invalid message to one of these hosts.


3. A better solution

We could register a port for SMIP: the Simple Message Injection
Protocol. Just like SMTP, but no restrictions on the envelope or body.
Any format, any line lengths, any characters, anything the server can
deal with.

qmail can trivially be set up to run on the SMIP port. Some existing
clients can be configured to use SMIP. For the rest, as I've explained,
you can simply set up a proxy.

The virtue of this solution is that the client is no longer violating
RFC 821. It doesn't have to rely on an out-of-band agreement from the
server to accept broken messages.

Of course, any explicit protocol would have the same virtue. Two
particular advantages of SMIP are (1) the ease of implementation and (2)
the ease of setting policy.


> If the client knows it can't produce proper Message-ID, and/or Date
> headers, for example, and doesn't know if the server accepts the new
> port or not.

I still don't see what problem you're addressing.

Let's try some specific cases.

1. The server is sendmail 8.6. It will accept broken messages on port 25.
The sysadmin tells naive clients to use port 25.

2. The server is qmail 0.90. The sysadmin is willing to fix up messages
upon request, subject to policy limitations. He runs a SMIP server and
tells naive clients to use that.

3. The server is qmail 0.90. The sysadmin has no interest in relaying
messages. He doesn't run a SMIP server. He rejects messages that aren't
addressed to him.

In which of these cases would it be a good idea for a client, let's say
Netscape, to try more than one port?

Or do you have another client-server combination in mind? If so, which?

> In no case is the client out of luck; the message does make it where it
> is going.

On the contrary. The amount of damage depends on the importance of the
821/822 violation. A bad envelope can and will cause the permanent
destruction of your message. A minor problem like a missing Date usually
won't---but it will when the recipient is running certain software.

> The point of the SUBMIT extension is to formalize the process, so the
> first MTA knows it is being given permission to fix the message, and
> all other MTAs leave it alone, but to still allow the proper thing to
> be done when a client doesn't use SUBMIT when it should have.

I don't understand. If the server _is_ willing to do ``the proper thing''
for the clients, with no special hints, then what's the problem?

If the server _is not_ willing to provide that service, the client has
no business sending a broken message.

> Also, the draft specifies that the MTA which fixes the message documents
> what changes were made.

Oops, I missed that. Now I really don't understand what problem you're
trying to solve. Users would kick and scream if

   From: bill
   To: joe@cs

   I've picked up the T-Rex---stop by my office and we'll digitize it.

were turned into

   Date: 7 Aug 1996 02:16:35 -0700 (this field added by zoo.movie.edu)
   From: [e-mail] (was ``bill'', fixed by zoo.movie.edu)
   To: [e-mail] (was ``joe@cs'', fixed by zoo.movie.edu)

   I've picked up the T-Rex---stop by my office and we'll digitize it.

---Dan