Re: header-munging

[Keith Moore <[e-mail]>]

> I suppose, maybe, if you're a client that already does ESMTP but submits
> broken messages, there might be some point in using SUBMIT.  Such
> clients are currently a tiny minority.  For other clients, it would be
> simpler to generate conforming RFC 822 messages in the first place.

Let's see...

1. To implement SUBMIT on a client, you have to:

a) send EHLO instead of HELO first; retry using HELO if EHLO fails
   (and perhaps be prepared to reopen the connection before trying
    HELO to work around bugs in old servers, sigh)
b) parse the EHLO response to look for the SUBMIT keyword
c) if the EHLO response contains the SUBMIT keyword, 
   add the SUBMIT keyword to any MAIL FROM command sent to the server.

This seems like 100-200 lines of code, tops.


2. On the other hand, for a client to generate conforming RFC 822
messages, it must know the client machine's fully qualified domain
name and the correct timezone for its clock.  The client probably also
needs to be able to rewrite addresses of the form "user" to
"[e-mail]"main", and addreses of the form "user@alias" to
"[e-mail]" (so default.mail.domain is another
configurable option).  

This isn't terribly difficult, but neither does it seem like a big win
over the code to do SUBMIT.


3. The "connect to another port" alternative seems somewhat simpler:
if a connection to the submit port fails with ECONNREFUSED, connect to
port 25 of the same host.  However, the fact that an attempt to
connect to the mail-submit port is rejected, doesn't mean that there's
not normally a mail-submit daemon running...it could be temporarly
shut down or out of resources.  In which case either illegal 822
messages get through (without any notice) or the normal smtp server
has to be able to rewrite the messages anyway.

So if you want to put the server on another port, the client needs an
"either-or" config option: either it connects to the mail-submit port
or it connects to port 25, with no automatic fallback to the other.


But I fear this is missing the point.

I see two reasons why we want to 'fix' messages at the MTA:

1. clients are often broken, and the MTA is more malleable than the
   client.

2. it's easier to configure one MTA to know the correct domain,
   timezone, etc, than it is to configure N clients.

The latter reason makes me think that we can't expect everyone to
configure their clients correctly.  It's too tempting not to, at least
until something like DHCP (which also allows centralized configuration
control) gets widely deployed.

On the other hand, while having an MTA do the fixup might work on many
LANs, it doesn't work in general.  There's no particular reason that a
client has to have the same domain, or be in the same timezone, as the
MTA to which it submits mail.  (especially not if the MTA is operated
by a large ISP, and the client is operated by one of its customers).

So we need both.  We need to fix broken clients because it's not
always possible for the MTA to fix what's broken.  But because it's
too tempting to do the configuration at the MTA, we also need some
sort of submit protocol (whether SUBMIT or a separate port) to
distinguish newly submitted mail from relayed mail.  That way, newly
submitted mail could either be "fixed up" (if it's broken and the MTA
can fix it) or rejected at the source (if it's broken and the MTA
cannot fix it).

Keith