I thought you just said that you know people who reject signatures if
the l= covers less than some percentage of the message.
I know of at least one implementation that offers that possibility, but it is
clearly divided into an assessor portion and a verifier portion. They happen
to be packaged together.
The verifier reports a good signature if RFC4871 has been satisfied even if l=
covers a tiny portion of the whole message.
The assessor is free to establish rules that stipulate a valid signature that
covers a tiny portion of the message is not a valid signature. The verifier,
in this case, makes that additional data available to the assessor.
For that matter, the assessor is free to establish a rule that says Subject:
header fields must be signed for the signature to be acceptable, even though
RFC4871 makes no such stipulation.
Consumers of this implementation made specific requests to reject messages
whose signatures didn't validate even though RFC4871 specifically advises
against doing so. It is also possible to make the assessor portion of that
implementation consider a small "l=" case as an invalid signature, thus causing
its rejection, even if the verifier portion gave the signature a thumbs-up.
I submit that RFC4871 can make assertions about the verifier, but not about the
assessor. I further submit that many assessor implementations will prefer the
benefits of a verifier that provides more than just a Boolean output.
So where do you draw the "interoperability" line?
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html