Re: IESG and the Sender's Identity

At 09:02 PM 4/12/2005 -0400, Radu Hociung wrote:

> David MacQuigg wrote:
This discussion was originally about how the sender should declare its ID 
to a receiver (explicitly or by some default).  It got sidetracked on how 
the receiver should know which method to use in authenticating that ID.
> > > 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.
Declaring an ID is not the same as advertising the available 
methods.  Those methods will have to be discovered by DNS queries.
Considering the fact that most email now has garbage in the SMTP names, and 
it still gets through, I don't see how replacing some of the garbage with 
an ID declaration is going to be a big problem.
Nobody said anything about trusting the declaration.  It still needs to be 
authenticated.
To use the border guard analogy, the guard should not have to hunt for an 
ID, and check each one he finds, only to have the traveler say "Those 
aren't my IDs.  I was just asked to deliver them to someone else."  The 
traveler should declare his ID, and if it turns out to be fake, he should 
be held accountable.
-- Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *