Re: IESG and the Sender's Identity

David MacQuigg wrote:
> So what do you do if your sender is using CSV, and you are expecting SPF?
>
> > The sender should have no input whatsoever in how the recipient decides
> > to authenticate the credentials that the sender can't help supplying.
>
> You seem to be assuming that the sender will provide DNS records for any 
> method that the receiver might prefer.  I think it is more likely the 
> other way around.  The sender will chose its preferred method, and the 
> receiver must comply.
I think you hit the nail on the head. Some common way for the recipient 
to know which of (CSV, SPF, DomainKeys, etc, etc) is available would be 
nice. Otherwise, the recipient is left "hunting", ie, searching all 
places it knows about, on DNS or wherever. I'd be willing to allow the 
recipient to make the choice of which of the available methods it will 
use, and in what order, under the MSMR rule (my server, my rules) :)
But I also agree with Mark and Frank that advertising the available 
methods in the SMTP dialog is a flawed concept, because:
1. It would change the SMTP protocol.
2. We start with the premise that the MAIL-FROM may be forged. So 
believing that the *ID* is true is not a good assumption.
What do you do if the forgers start traffic to a.com just because they 
blessed it by mentioning it in the *ID* they faked?
Current SMTP authentications involve only the two parties involved for 
good reason. As soon as one of the parties can name a third party, you 
have abuse. When an authentication mechanism does require a third party 
(such when the server uses SASL or Kerberos and queries some other 
server for authentication tokens), it does so by configuration. In that 
case the local administrator has complete control over the traffic 
caused by incoming connections.
For the *ID* to be trusted, you'd have to trust the server at the other 
end of the connection. How can you do this without prior arrangement 
between the servers?
I'm willing to concede that maybe I don't understand what you are 
proposing, but if you can show a clear chain of trust from the sender to 
the recipient, maybe the idea has wings. :) After all, with domainkeys 
you have that clear chain of trust. It *is* possible.
I think that whether this idea works or not, the underlying problem of 
"how to avoid 'hunting'" remains on the table.
Incidentally, I also think someone should start working on MTP, as a 
descendent of SMTP. Really all we are doing currently is patching a 
system which is broken by design. Maybe it will take 20 years for MTP to 
become the accepted standard. I see no problem there.
Greetings,
Radu.