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@elan.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 >...