FAQ: SMTP Message Submission to Proposed Standard

[Chris Newman <Chris.Newman@xxxxxxxxxxxx>]

SMTP Submit FAQ:

(1) Why is this urgent now?

The email industry desperately needs an authenticated submission
service.  A large number of ad-hoc mechanisms have been tried, but many
have serious flaws and none have widescale support yet.  This leaves us a
window to _architect_ an authenticated submission protocol if we can get
it done in the next few months before this window closes.  Regardless of
what the IETF does, the email industry will eventually reach rough
concensus on something.  If the IETF acts quickly, it can influence that
something.

(2) Why have a separate submit port?

Submit and relay are separate services.  Submit needs to have more
stringent validation of content, can easily provide helpful content
gatewaying services and can communicate errors interactively to the
submittor.  Relay has to be more efficient and can't communicate errors
interactively to the submittor, relays which gateway content have proven
to cause serious interoperability problems.

If you put these services on separate ports, it allows them to come from
different vendors, have separate sets of authentication rules, have
different levels of efficiency, and easily permits features which are
beneficial in a submission service and harmful in a relay service.

We have lived with both on port 25 and can continue to do is if absolutely
necessary (just as we probably would have survived if email was still
transferred with FTP).  Just because something works doesn't mean it's
well architected.  You may not be aware of the interoperability
problems that submit-based "fixups" continue to cause to relayed email.
The industry doesn't care much about architecture and won't use separate
ports without an IETF standard.  If separate ports aren't used, then
submit-based features which might cause relay problems will be strongly
opposed in the IETF.

(3) Why not design a new protocol from scratch?

Suppose you're an MUA vendor.  You can use your current code which submits
email on port 25 and works almost everywhere.  Or you can spend months
writing code to support a new whiz-bang protocol which might cut the
average submission time from 2 seconds down to 1 second and might add a
few minor features, but isn't available at most customer sites.  If you do
the latter, you still have to maintain all the current submit-to-port 25
code.  I think it's obvious that very few MUA vendors would be motivated
to spend those months adding the new code.  I wouldn't be.

But if we create a SUBMIT protocol based on SMTP which supports
submit-specific extensions, then we can add features later.  We've been
much more successful at evolving protocols than we have at deploying new
ones.

(4) Why doesn't security protocol X solve all the problems?

MTA/MUA vendors have to sell products which work out of the box.  That
means they can't insist on the installation of custom TCP/IP stacks or
special gateway boxes or ftp'ing free software from outside the US or the 
purchase of certificates from Verisign before working.  In short, all the
security code has to be in the MTA/MUA vendor's product with commercial 
support by the MTA/MUA vendor.

(5) What does this have to do with SPAM or roaming users?

This allows a site to positively identify which account was the source of
locally-generated SPAM.  It allows roaming users to submit email remotely
without having to enable anonymous relay of SPAM or use a custom hack. 
No, authenticated submission won't solve "the SPAM problem", but it's a
useful and much needed tool in the arsenal. 

(6) Why doesn't SUBMIT make AUTH mandatory?

A lot of sites are happy with restricting submission to only local IP
addresses.  Even more sites would be happy to restrict submission to local
IP addresses _or_ authenticated users.  If AUTH were mandatory on the
SUBMIT port, then it wouldn't be possible to simply reconfigure all the
clients to use vanilla SMTP on the submit port and get the advantages of
the modular architecture right away.  You'd have to wait until *all*
clients at the site supported authentication before you could deploy a
submit server.

(7) Why doesn't SUBMIT make PIPELINING mandatory?

It'd sure be nice if we could.  But clients won't try the submit port out
of the box unless submit servers are easy to deploy.  It's not hard to run
a server on a different port.  It is hard to upgrade a server to support a
feature that isn't supported by your current vendor.  The architectural
advantages of different ports won't materialize until we can deploy the
submit protocol.

(8) Why not remove feature X from the Submit spec?

The author is working on a last-call revision which removes or pares down 
most of the controversial features.  The vital features are:
 (a) a separate port
 (b) a reference to SMTP AUTH
 (c) a way to add submit-only extensions (which could be harmful in a
     relay scenario)
The core group of email experts which have been working on this for two
years demand at least those features.  Support for the other features was
admittedly a bit luke-warm.

		- Chris