[Top] [All Lists]

Re: Sender's Declaration of Identity

2005-05-17 03:13:48

At 11:58 PM 5/16/2005 -0400, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:

On Mon, 16 May 2005 14:49:02 PDT, David MacQuigg said:

> The ID is used only to locate the authentication records. The actual check
> is done per the requirements of whatever method is specified in the DNS
> records at the ID. For example, if the ID is, and ebay says "Here
> is an SPF record to use in checking that IP", then the check will be done
> against the MAIL FROM and HELO domains.  If ebay says "Here is a Sender ID
> record", then it will be a different set of domains that gets
> checked.  Whatever method is used, it is the ID that is responsible to
> chose the method and provide proper DNS records for that method.

But Sender-ID and SPF already *know* where to look for the data they want.

And we don't know, when the message arrives, whether it uses Sender-ID, SPF, or some other method.

You stick an ID record in there, what are you *really* accomplishing?

Avoid multiple DNS queries hunting for authentication records.

Let's say we're looking at a scheme that validates MAIL FROM. Either:

1) The ID and MAIL FROM match.  Why bother?

2) The ID and MAIL FROM don't match. Now you either have to check the MAIL FROM
*anyhow* and flag an error, or allow the spammer to hand you a valid ID and a
bogus MAIL FROM.

You seem to be assuming SPF.  What if the method is CSV?

Work through your protocol, and assume that the spammer will *LIE* with whatever
value they think they can get the best results with.

Let's work through it together.  Here is an incoming email.

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

What do you do next?

************************************************************     *
* 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          *
************************************************************     *