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 ebay.com, 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.
EHLO mailserver7.bigforwarder.com
MAIL FROM:<bob(_at_)sales(_dot_)some-company(_dot_)com>
What do you do next?
--
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 *
************************************************************ *