RFC 4405-8. Since the requirement is out of scope we are fully within our rights to merely note the existence and widespread use of the scheme in a non-normative reference.
> -----Original Message----- > From: Michael Thomas [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 05, 2007 2:15 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: > > 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. > > There is? What is the RFC #? > > Mike > > > > 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
