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:
EHLO mailserver7.bigforwarder.com
ID bigforwarder.com
MAIL FROM:<bob(_at_)sales(_dot_)some-company(_dot_)com>
Checking the TXT record at _AUTH.bigforwarder.com.ID-check.net gets a response:
svc=S1:A,M2:A,H1+:B dmn=QR1,SPF1+5,DK2
QR1=ip4:?170(24.30.23;24.28.200;24.28.204;24.30.18;24.93.47;24.25.9),
+4(65.24.5.120;24.94.166.28;24.29.109.84;66.75.162.68;24.24.2.12)
DK2=dk:MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5
o6lMIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7
EXzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
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.
--
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 *
************************************************************ *