On Mar 18, 2008, at 9:09 AM, Dave Crocker wrote:
Steve Atkins wrote:
Without that check, an unsigned mail from
foo(_at_)bar(_dot_)baz(_dot_)ebay(_dot_)com will
be considered to comply with ASP unless there is an ASP record for
_asp._domainkey.bar.baz.ebay.com or for _asp._domainkey.baz.ebay.com
...
The domain existence check means that only a defined number of ASP
records need to be published (the number of hostnames you publish
would be an upper bound unless you're using wildcards anywhere else
in your DNS, in which case all bets are off).
(Thanks for Barry for reminding me to review this.)
Steve,
Many apologies, but I am simply not understanding this.
Assuming the domain does not use wildcards for some purpose, then
finding the non-existence of the domain offers a means to reject the
message. The check could depend upon the presence of SMTP discovery
records, MX or A.
Just to make sure we are on the same page about the hierarchy trick
in the spec:
The one-level-up hack might be useful for saving some
administration, but it does not provide meaningful "protection",
since all an attacker has to do is use a level down.
This assumes an existence check is being made _and_ the non-use of
wildcards. Policy only needs to be published at nodes where A or MX
records are being published, as not having these records should
disqualify the domain being valid for SMTP.
With respect to an A record, its presence does tell you that the
name is valid, but it does not tell you anything about ADSP
support. Initially there will be virtually no adoption of ADSP. So
what does finding an A record, but no _adsp
record, tell you?
Either an A or MX record would mean the domain potentially supports
SMTP.
I think what this is uncovering is that adoption of ADSP requires
ensuring ADSP query results for all valid names. In that context, I
guess I can see the benefit of having an A record serve to define
what names are valid.
Mumble. This is still feeling a bit squishy to me, although at
least I'm starting to see the possibility of its being useful. (I
think the doc at least is going to have to be much more clear about
its role.)
Good. A feature offering even stronger refutation than invalid
signatures and strict policy would be to require MX records be
published in conjunction with DKIM/SMTP policy. In this way, when a
DKIM/SMTP policy record is published (even an empty record) without an
MX record, then both DKIM and SMTP are indicated as not being
supported at the domain.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html