I do not think it makes any sense to be publishing a policy that says alsdkfjasdf.example.com is signed when no mail is going to ever be sent from there.
We already have mechanisms to say alsdkfjasdf.example.com sends no mail, and they block the attack without any need for complexity in the search scheme. Defining a mechanism for nomail is out of scope, stating that we might rely on existing nomail schemes is not. One of the reasons the group agreed that we did not need to do nomail is that it is already done by SenderID/SPF. I am saying that it makes no sense to kill ourselves creating a means of specifying mail sending policy for domains that never send mail. > -----Original Message----- > From: Michael Thomas [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 05, 2007 1:54 PM > To: Hallam-Baker, Phillip > Cc: Stephen Farrell; Scott Kitterman; [email protected] > Subject: Re: I think we can punt the hard stuff as out of scope. > > Hallam-Baker, Phillip wrote: > >> From: Michael Thomas [mailto:[EMAIL PROTECTED] > > > >>> NOMAIL is out of scope, but wildcard is in scope. > >>> > >>> The relevance here is that it looks like we can get 95% or > >> better coverage of the real use cases here by acknowledging that > >> wildcards are primarily an issue for NOMAIL. > >> > >> It is? If I sign everything for my domain, I'd like to be > able to say > >> that for both the top level domain, and all of the subdomains too, > >> right? > > > > Why would you be signing a subdomain that does not have an A record? > > > > Come to that how does your understanding of DKIM policy > work for a node that has no A record, no MX record and no > related key records? If you have a policy 'I sign all mail' > what restrictions do you impose on the key records? > > Huh? > > Let's review the attack: > > example.com: "I sign everything" > > attacker sends mail purportedly from example.com. I look up > example.com, get the "I sign everything" record, I know it is > forged. All is good. > > attacker then sends mail purportedly from > alsdkfjasdf.example.com. I look up policy for that node, and > find nothing. All is not good. > > If I use a wildcard as well: > > *.example.com: "I sign everything" > > It will cover all subdomains *except* ones that have an RR > (usually an A record). Thus, we need something that covers > those nodes too. Hence the tree walk, forcing those nodes to > have the policy RR there too, etc. > > I don't understand what you wrote above has to do with this attack. > > Mike > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
