mail-ng
[Top] [All Lists]

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

2004-01-30 01:58:14

--On 2004-1-29 11:24 PM -0800 Chuq Von Rospach <chuqui(_at_)plaidworks(_dot_)com> 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