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