-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
A quick note to add on to some things others have said.
DKIM has features that are useful in some places but not in others.
One of those is l=.
It seems to me that some people think that DKIM is going to be used
uniformly throughout an email system, and that's in my opinion naïve.
For example, I'm sending this message to you through a security
gateway that I make -- PGP Universal. My PGP Universal server does
not presently do DKIM, but it *knows* that I am sending to a mailing
list. It knows that "ietf-dkim(_at_)mipassoc(_dot_)org" is the address of a
list, not an individual, and it handles that specially.
It is possible for software to detect mailing lists and perhaps use
l= on those messages, but not on others. It is even possible for
software to automatically detect its own signatures that break
because of trailers put on, and then start using l=. It could happen.
It's not a computationally infeasible problem.
Similarly, software could take messages coming from some hosts and
trim the dangling trailers on some messages, and not on others.
I also think that warnings about appropriate lengths is not only
unnecessary, but inappropriate. It's arrogant for the standard to
tell the implementer and the deployer how to do their job. Like all
rules of thumb, it can be carried to an absurd extreme, so I'm not
interested in hearing about the exception case.
I'm especially uninterested because DKIM is a system that when
misused, it hurts the signer and no one else. If I start signing
messages with l=2 and some spammer uses that, guess who's hurt? Me.
Not you, me. The purpose of DKIM is not to make bad mail actors go
away, but to *identify* them. If misuse of l= is as bad an idea as
having an open relay, people will figure it out!
I also expect that someday someone will figure out that it is not
computationally infeasible for software to say, "Huh. There's an
awful lot of text appended after the signed portion" or "Wow, that's
sure a short signed length" and figure out something to do with that.
An especially clever developer might even already be thinking about
it because a system that does cool things with DKIM would be a
competitive advantage. It could happen.
Please, let's stop trying to do the implementor's job. Let's stop
trying to do the deployer's job. Let's make a standard that permits
them to do a good job.
Jon
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.5.2
Charset: ISO-8859-1
wj8DBQFFuTY9sTedWZOD3gYRAtR0AKCj2a4mjBXMz4ID/om2tFaM03P0uwCffsuO
eDlt6hvkC6RRgfV8ZgBeIHQ=
=lBzJ
-----END PGP SIGNATURE-----
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html