SM wrote: > Adding text in RFCs to prevent lies doesn't usually solve problems. :-)
Sure, but that is what h= attempts to trap using another level of authenticity requirements. We can categorized that scenario many ways but its simply about the domain trying to exclude an method a "bad guy" can use fraudulently. > >> Overall, my suggestion for the text would be something like: >> >> h= A colon-separated list of hash algorithms that might be used >> as acceptable hash algorithms. (plain-text; OPTIONAL, >> defaults to allowing only standard registered algorithms). >> >> When signing mail, the signer MUST use one of the h= methods >> explicitly specified or implicitly using one the default >> standard registered hash algorithms. >> >> Verifiers not recognizing a hash algorithm or does not >> match a= value MUST invalidate the signature. > > The key in the text proposed earlier is "operational choice" (see what > Tony suggested). It is a fix that does not introduce any requirements. > The text proposed earlier takes into account what is stated in other > sections of draft-ietf-dkim-rfc4871bis-05. The point in my text is to spell it out. Yes, its an operational choice, but one that does come with a non-written technical requirement. If you specified h=, you are expected to use one of the methods listed for signing. Otherwise, current verifiers will see you as a "liar" (or bad guy mail) when using something else. :) -- HLS _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
