Murray Kucherawy wrote:
A reasonable verifier can completely ignore x= and still get the right
result in all non-silly cases, which tells me that x= should go.
[...]
PS: This is the same reason that l= should go.
I think "l=" and "x=" both put more information into the hands of the
verifiers. It's true they can ignore such information, but they can also
elect to observe things like "Hmmm, the verifier didn't intend for this to
verify beyond time T. Maybe I should treat it differently somehow."
Same goes for "l=". And the opposite goes for "l=" as well; a verifier could
decide it will not accept mail that has had more than a certain volume, or
percentage, of additional text beyond what the signature covers. I know of
one such implementation already.
Just because one verifier (or even many) could decide to ignore "x=", doesn't
mean all of them will want to do so.
I'm not sure I agree with the rhetoric that DKIM's base spec should include
absolutely nothing other than the bare essentials. I'm a fan of providing
more information whenever possible.
The motivation of x= was twofold:
1) life of the key and life of a message signature aren't the same thing. A key
may be _very_ long lived, where you might want to throttle the signature
validity
to "transport time" (= ~ 2 weeks, say)
2) there seems to be some expectation DNS based key management is a trivial
matter.
Well, it's not. Half of the trouble of DKIM is mail admins getting keys
into DNS
in the first place. Expecting that you're going to have regular key
rollover is
a pipe dream for a lot of folks. We'll be lucky if they can manage things
in a
fire drill.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html