[Top] [All Lists]

Re: Options for the ID Command

2005-05-17 16:41:47

At 06:12 PM 5/17/2005 -0400, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:

On Tue, 17 May 2005 14:56:56 PDT, David MacQuigg said:

> 1) It provides an unambiguous Identity that we can pick from the SMTP
> session without transferring the DATA.

> 2) There are no restrictions on the Identity that will favor one method
> over another. i.e. It's just an Identity that we can check, no additional
> requirements like it must be the PRA Identity (The reason SUBMITTER is out.)

You *do* realize that you're screwed at this point, because the different proposals
check different things.  What should the "identity" be when one proposal wants
"the hostname claimed on the 821 MAIL FROM", another wants "the hostname claimed on the 822 From:", and another wants the entire left/right side of one or the other?

You misunderstood the proposal in this and the next four posts. I'll provide one answer here.

The ID declaration is independent of the method, because we defer selection of the method until the next step, which is the DNS query. The response to that query tells you what methods the ID offers for authentication, and each method may place additional restrictions on other identities in the email.

For example, let's say you get an email like this:

   MAIL FROM:<bob(_at_)sales(_dot_)some-company(_dot_)com>

Checking the TXT record at gets a response:

   svc=S1:A,M2:A,H1+:B  dmn=QR1,SPF1+5,DK2

The supported methods are QR1, SPF1, and DK2. QR1 makes no demands on any other identities. It just says "Any IP outside these blocks is not us." SPF1 requires that either the MAIL FROM or the HELO identity match the declared Identity, and DK2 calls for a signature check using the public key provided in this record.

It is important that we not overload the ID Declaration with any other meanings, particularly any meanings assigned to pre-existing fields. As the SPF folks have discovered, you can't get people to change the way they have been using MAIL FROM, even if you scream "forger" at them.

If there was *agreement* on what to check, we'd not have competing proposals.

There are good and bad aspects to the present competition. Good is that we will have available a variety of methods, so if one or another develops the problems their competitors worry about, we can switch to another. Bad is that the competing groups are so hostile to each other that they won't cooperate on anything, and that lack of cooperation has blocked progress for nearly a year.

************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

<Prev in Thread] Current Thread [Next in Thread>