On Mon, 11 Jul 2011 05:53:58 +0100, Murray S. Kucherawy <[email protected]> wrote:
> Actually, let me revise that a bit: > > "Agents that evaluate or apply DKIM output need to be aware that a DKIM > signer can sign messages that are malformed (e.g., violate RFC5322), or > become malformed in transit, or contain content that is not true or > valid. Such an action might constitute an attack against a receiver, > especially where additional credence is incorrectly given to a signed > message without evaluation of the signer. Moreover, an agent would be > incorrect to infer that all instances of a header field are signed just > because one is. Agents will need to account for these issues when > deciding how to apply DKIM results to message, especially when > displaying them to users." OK, there is much good stuff in that. In particular, it makes it clear that Bad Stuff can originate from the signer as well as from men-in-the-middle and replayers. But I am still concerned that multiple occurrences of "singleton" headers fields are not explicitly mentioned, even as just one possible example. So perhaps, just before the last sentence: "... , in particular if that field was not supposed to occur more than once." After all, you were seemingly happy to mention that particular trap in 8.14 in draft-12. Not sure about the word "incorrectly", but s/without evaluation/without adequate evaluation/ might make your point better. Though I expect, of the millions of perfectly legitimate domains that will exist without special recognition in any reputation system, it will be hard to spot a newly appearing 'badguy' one. I still don't think that paragraph is what we really need, but I will withold judgement on that until I see how it gets incorporated into the other bits of text that are around. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: [email protected] Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
