William, I don't want to discourage you -- if you can find
others to explore these ideas with you, please go ahead and do
that. But I share Dave Crocker's skepticism: because of some
"been there, tried to figure out how to really make it work,
couldn't" issues, I'm disinclined (as he is) to spend a lot of
time on something like this until there is a fairly detailed
proposal on the table.
Where previous analysis has led us is that strong trust
relationships are best handled end to end. Given the store and
forward --and responsibility handoff-- model used by all
networked mail systems so far, that usually ends up meaning a
trust and authentication infrastructure as part of the message
payload, rather than server to server (which tends to get very
messy in relaying). I'm not saying it can't be done in
transport, but I haven't yet seen a plausible argument for doing
it, and, at least as important, we've had fairly poor
operational experience with things that increase the amount of
handshaking (e.g., number of transaction turnarounds) or
calculations and contemplation during mail transport
transactions.
While SMTP is not my favorite protocol either, our experience
with deploying new protocols when something is out there that
sort of does the job has been just miserable. Consequently, I'd
also encourage you to ask yourself the question of whether the
mechanisms you think you need could not be fitted into SMTP
extensions and, if not, for what reason. To do that, you are
going to have to dig into the existing stuff sufficiently to
avoid comments like "SMTP AUTH uses clear-text passwords": they
are used in some situations, and may actually be reasonable for,
e.g., first-hop (submission) handling in many dialup
environments, but they are certainly not the only option and my
impression is that they are uncommon amount SMTP AUTH
implementations. I don't know that I'd recommend it (i.e.,
please work through this, do the analysis, and tell us), but the
ESMTP machinery is flexible enough that a client could abandon
the attempt to send mail if the server didn't advertise the sort
of trust-negotiation extension you ask for, and the server could
reply to the first RCPT command, or even to DATA, with some sort
of "you need to exchange certifications and negotiate trust now"
if the client didn't send the relevant information when it was
expected.
john
--On Tuesday, August 20, 2002 6:37 PM -0700 william(_at_)elan(_dot_)net
wrote:
I do not have such a "detailed" list, I do have number of
notes on the topic and if insist I'll share some of them. I
do think most of this should be discussed on te mailing list I
created just for that very topic.
Basicly I'm looking to create a way for mail servers to
negotiate with each other based on the particular
transmission received (that means after TO and FROM have
already been sent and not at EHLO level), the idea is that if
possible email should be sent with maximum amount of "trust"
between parties and that means if for example several protocol
for trust are available, the servers would decide which to
use. If certificate trust is supported and desired, the
...