--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