On Mar 18, 2008, at 9:09 AM, Dave Crocker wrote: > Steve Atkins wrote: >> Without that check, an unsigned mail from [EMAIL PROTECTED] 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
