Some thoughts on SMTP Verification

I wanted to share a few thoughts with you. Leaving the LMAP proposals 
aside, are there any other methods or changes that can help verify the 
SMTP transaction as being authentic?

1. "What" - what are we seeking to do with SMTP verification. It seems 
to me that what we want to do is to make sure that none of the 
parameters in the SMTP session are forged and also that the MTA is 
authentic, and is not a hijacked computer. If would be helpful if we can 
clarify as to what type of data we want to know.

There is also a second issue that has been discussed before - a 
possibility of having the sender and receiver exchange policy 
information during the mail transaction. Currently SPF and CID seeks to 
do this somewhat. My question is what kind of policy information do we 
seek to exchange. If it is simply support for protocol A or protocol B, 
ESMTP mechanism provides a way to do so. If we can get some picture on 
what kind of policy mechanism we are talking about, that would help.

[A side comment: I would like to ignore the LMAP proposal for the policy 
discussions. What I want to look at here, is if we were making a policy 
mechanism for email from scratch, what would it look like?]

2. "Why" - the goal is to make sure that a specific message is not spam 
as early as possibly, even within the SMTP session. The basic reason of 
why is to make the Internet players more accountable for their actions. 
Regarding policy information I am not sure why we want to exchange 
anything beyond simply protocol support indications or something like 
LMAP (the NO-SOLICIT extension is a legal effort, and is a separate 
discussion).

3. "When" - as early as possibly. If we can reject the connection before 
the HELO prompt, that would be the best. Rejecting anytime during the 
SMTP session before the final 250 answer is also desirable. A side 
effect of this would be that the sender is notified immideatly instead 
of DSNs being sent to forged addresses.

4. "Where" - it seems that the best place to deal with spam is at the 
SMTP level not at the MUA, since it gives us a chance to reject the mail 
as early as possible. However, the MUA should be able to do that as 
well, and should also be able to display results of the SMTP session 
verification process.

5. "How" - leaving the LMAP proposals aside which publish information 
about MTA/domain name relationships, there is a range of other 
mechanisms available to us: ESMTP extensions, other DNS methods, 
possibly out of band protocols, TLS with matching certificates, etc.

Yakov