Re: header-munging

[Tim Goodwin <[e-mail]>]

[ Concerning 1. SUBMIT extension vs 2. generating conforming 822 in the
first place vs 3. SMTP submit port. ]

> 1. To implement SUBMIT on a client, you have to:
> ...
> This seems like 100-200 lines of code, tops.

OK, sounds about right.  Don't forget that every server implementation
will need code changes, too, if it is to support SUBMIT.

> 2. On the other hand, for a client to generate conforming RFC 822
> messages, it must know the client machine's fully qualified domain

Sorry, I was being slightly flippant.  Obviously we're not going to
persuade every client to generate conforming 822.

> 3. The "connect to another port" alternative seems somewhat simpler:
> ...
> 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.

Yes, I agree.  I've added text to my proposal to make this point clear.

Now, just how much simpler is the SMTP submit port to implement?

If you are a client that already makes the port number used for SMTP
configurable, then no code changes are required.  Otherwise, the
requirement is to make the port number configurable.  All clients which
might use the SMTP submit port already have a configurable "smarthost";
by extending the syntax to `mailhost.company.com:25', the port number
can very easily be made configurable.  10 - 20 lines of code?

In a particular administration which has deployed submit port servers,
it would be possible to kludge the non-configurable clients to use them;
either by making the one line change to the source and recompiling, or
by (horrors) hacking the binary.

On the server side, the major issue is whether the MTA can do both pure
relaying and submission fixups.  For those that can, both proposals
are straightforward to implement; for those that can't, both proposals
will require a similar, possibly large, effort.  However, I claim that
the SMTP submit port will never be harder to implement than the SUBMIT
extension.

In fact, with two MTAs I have access to here, PP and qmail, I have
already set up servers which do pure relaying on port 25 and submission
fixups on another port.  No code changes were required; it was a simple
matter of configuration.

Whichever proposal goes forward, I'm not hopeful that it will see
widespread deployment.  The status quo works well enough, often enough,
that most people will see little need to change it.  I believe the
submit port proposal is sufficiently simple, requiring in some cases only
configuration changes, that it might just fly.

Tim.

P.S. My "SMTP Message Submission Port" proposal is still awaiting an
official internet draft filename.  In the meantime, you can retrieve it
from here.

    ftp://ftp.pipex.net/pub/mail/draft-goodwin-smtp-submit-00.txt