Re: Last Call: SMTP Message Submission to Proposed Standard

[Lyndon Nerenberg <[e-mail]>]

> It's now time to create a distinct posting service and to create it as
> simply as possible.  Instantiating SMTP on a separate port and with some
> very explicit statements about the strictures at the server, distinguishing
> relay processing from submission processing, is the easiest way for us to
> accomplish this.

The problem with SUBMIT (according to the latest draft I reviewed) is that
AUTH is optional. Unless SUBMIT *requires* authenticated message injection
it isn't going to do anything to solve the spam problem. In fact, it makes
it worse: SUBMIT servers, by definition, *must* support relay.

I still contend that the existing SMTP, coupled with AUTH, and including
the SUBMIT header processing extensions described in the draft, will work
just fine one the existing port. In the course of identifying yourself to
the SMTP server (via AUTH), the SMTP server is able to determine (through
those authentication credentials) whether the authenticated entity is
entitled to "submit" messages. (E.g., if the "submit" bit is lit up in the
credentials for the authentication entity, the server allows relaying and
enables the SUBMIT header processing functionality.) As a bonus side
effect, it ensures the rapid deployment of SMTP AUTH. 

--lyndon