On May 22, 2008, at 2:50 PM, J D Falk wrote:
On 22/05/2008 10:03, "John Levine" <johnl(_at_)iecc(_dot_)com> wrote:
So I like Arvel and Wietse's approach, say to do it but don't try
to define it since any definition would be wrong. Other thoughts?
I'm confused. Arvel and Wietse's approach seems to make perfect
sense to me, but some other very smart people who I also have a lot
of respect for are disagreeing with them...so I have to assume that
I'm missing something.
Arvel has suggested disqualifying the innocent absence of an ADSP
record can rely upon NXDOMAIN when requesting _any_ record from the
domain ADSP is below. More than one DNS transaction is therefore
required. Such a strategy creates an unfortunate situation in that
domain-wide ADSP protection then requires publishing ADSP records
directly below _each_ domain within the parent domain seeking
protection. Such an "existence" test also provides little to merit
the check. In addition, there would not be any means to curb these
checks when they prove troublesome for domains being spoofed.
Could someone please summarize, perhaps with suggested solutions to
allow us to move forward?
A complete ADSP draft has been submitted to permit the review of an
alternative path forward.
As a separate topic, this ADSP draft eliminates restrictions on DKIM
identity parameters. When the message has a valid signature by the
Key Domain, identity affirmation MUST be based upon the trust of the
Key Domain to exclude spoofing. Determining whether the Key Domain
has affirmed an identity within the message remains a separate, and
fully independent function, completely unrelated to whether messages
containing the Author Domain are always signed.
It is no wonder people have become confused, even though the charter
is rather clear. Placing restrictions on DKIM identity parameter use
is clearly at odds with the charter, as this forces DKIM to confirm
Author identities, even when such confirmation should not occur.
Unfortunately, compliance with SSP provides unnecessary coercion and,
at times, requires multiple signatures. : (
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html