On Oct 15, 2010, at 7:13 PM, John Levine wrote: >> In this case, we've gone to some lengths to make the environment >> pure, by using the underscore branch. And then along come these >> pesky wildcards. > > Even without wildcards, there's been a variety of broken key records. > > I would hope it would be obvious that you have to assume that any data > you haven't previously verified is potentially hostile, either > deliberately or by mistake. This refers to DNS keys, DKIM signatures, > and the message you're trying to sign or verify. > > By the way, has everyone tested their signing code to see what happens > if there's no From: header at all? Do we even agree what the right > thing is?
h=From with no From header is fairly well defined, I think. The message will be signed, and that signature will validate just fine, unless something in the message is modified - such as adding a From: field. > I'd think it'd be approximately the same as if the private > signing key (the only other mandatory input I can think of at the > moment) wasn't present. If it fails, it's broken, I think. There's nothing special about the >From field, other than it having to be one of the signed headers. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
