[ietf-dkim] RFC4871bis - whether to drop -- l= and x=

[Paul Russell]

On 6/2/2009 16:56, John Levine wrote:
>>> Both l= and x= are bad for interoperability, because it is utterly
>>> unclear what a recipient will do with them.  Whevever I ask, the
>>> answer is they might do this and they could do that.  If I put a
>>> really long x= into a signature, will recipient systems accept a
>>> stale message that otherwise they wouldn't?  If I sign the first
>>> 100 bytes of a 10K message, will recipient systems accept it, and
>>> if so, what will users see?  There's no way to tell, because
>>> everyone just makes something up.
> 
>> I would argue that your specification of l=100 when the actual
>> message size is 10K is intentional breakage of your own signature.
> 
> I mean that the body hash covers the first 100 bytes of the body, and
> doesn't cover the other 9900 bytes.
> 
> The question remains: given a message with such a signature, which is
> entirely valid in the current DKIM, what will a recipient system do
> with it?  What will users see?  Ask ten people, get ten answers, which
> is about as far from interoperable as you can get.

Ah! I have a less-than-complete understanding of the current specification.
Why does the current specification allow the signer to specify an arbitrary
value for l=, rather than requiring the value of l= to be the actual length
of the message body at the time the message is signed?

-- 
Paul Russell, Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame
prussell at nd.edu