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(_dot_)edu
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html