On May 29, 2009, at 2:22 PM, John R. Levine wrote: >> I don't understand what "cruft" you think I'm talking about. > > Telling people that it is reasonable to add a chain of A-R headers > to messages with broken signatures, and expecting recipients to > apply some ill defined algorithm to decide how much they believe > each level of alleged signature.
By having the l= value defined, the length of the message that was signed has been make explicit, where appended notices or ads can be omitted which is the intended use of this parameter. In the case of A- R permitted cruft, the l= value allows rechecking the body hash as a simple process when the DKIM header contains both the length and the signed body hash. MUAs annotating signed messages already must exclude portions of the message not included in the hash from being annotated as having been validated by a signature from the signing domain. The MUA may also check the reputation of the signing domain and wish to assert a green/red bar. Even with the A-R header, without some means to trim off appended messages, which is the original purpose of the l= feature, recipient may confuse which message content and reputation should this apply, that of the signer or that of the provider. They may easily be confused as to who they are trusting. Those purchasing ad space may even attempt to leverage the resulting confusion. Perhaps this issue should be reviewed in a few years. Making changes now would be based upon conjecture. > I would really like to remove l= from DKIM to make it clear that it > is not a good idea to even try to guess the history of a message > based on signatures that don't verify and cover the whole message. Without the l= feature, annotations based upon DKIM may prove uncertain whenever providers are lax at applying notifications or advertisements. It is purely guesswork as to how this situation might be best resolved. It seems appropriate to make statements about any attempt at message annotations covering all portions of a message based solely upon A-R headers. I don't think there is any burning need to add additional cautions about the use of the l= parameter. It seems such effort is aimed at allowing sloppy and likely dangerous annotation practices. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
