Hello Lyndon,
At 00:57 04/01/30 -0800, Lyndon Nerenberg wrote:
--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.
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.
Do you use PGP when you are on the road, without any computer?
If you have your own notebook, using ssh lets you avoid IP blocks.
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.
The name of this list is mail-ng, not smtp-ng or mail-transport-ng.
In my view, this means we can and should look at layering issues,
and relationships between layers. In the end, ideally, we should
end up with a clear architecture, but it is in no way clear yet
that this will be the same pieces as we have now, and that the
relationship between between the pieces will be exactly the same.
Regards, Martin.