David,
A few things:
1) No one is going to trust what a client says. You need an "anchor" that
he has basically no control of. Like the IP address.
2) If you do use a ID command, what method does the server use? It would be
more appropriate with something like:
ID method method_entity
3) But #1 still applies.
In short, the server defines what security context the client will run
under. Not the client.
4) Enforcement. How do you plan to enforce it?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "David MacQuigg" <david_macquigg(_at_)yahoo(_dot_)com>
To: <Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu>
Cc: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Tuesday, May 17, 2005 5:08 AM
Subject: Re: Sender's Declaration of Identity
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 *
************************************************************ *