Re: Why are we here? What are our goals?

--On 2004-1-29 11:24 PM -0800 Chuq Von Rospach <[email protected]> 
wrote:

> Part of the reason we're in the trouble we have today is we can't
> authenticate and authorize (different things!) a piece of email and
> its source.

Yes we can. PGP and S/MIME will do this. IP does not try to 
authenticate the applications running above it. And neither should 
(son-of-)SMTP. We *have* to divorce the messaging transport from the 
message content.

Son-of-the-mother-of-shut-up-and-play-your-MTA has to stick to ONLY 
transport issues. Dealing with (e.g.) language translation and end-user 
entrance gatekeepers MUST happen at the application layer. Think about 
it: how could the transport possibly know what language translation 
features my MUA-of-the-minute (and yes, I use them that way) supports?
These conversations about having the transport layer try to communicate 
end-to-end MUA feature capabilities (hard-wired on a per-user basis, no 
less) are absurd. And how can we ensure end-to-end integrity of signed 
message body (and header) content if the transport is, once again, 
mucking about in the bits of the body content?

As far as authorizing and authenticating the source: Who cares where 
the message was injected at? What matters is who sent it. All the 
attempts to block IP addresses just make my life hell when I'm on the 
road. These schemes don't authenticate *me* in any way, shape, or form. 
So if you mean authorizing and authenticating the *composer* of the 
message, now we're back to the application layer, and beyond the scope 
of the messaging transport.

The successor to SMTP *must* concentrate solely on the efficient 
transport of *arbitrary* payloads. It cannot make policy decisions 
based on the content of the messages, any more than IP or TCP or UDP 
can.
(Well, I'm sure someone will make an argument about QoS, however I'll 
save that counter-argument until I've had some sleep.)

--lyndon