On Sat, 9 May 2009, Steve Atkins wrote:
q: List of query methods
I don't think q= is going to be controversial either, but I'm
mentioning it separately as it currently only has one value, the
default, it's unlikely to be extended, and if it were it would require
a whole new RFC to do (which rather than extending the q= header,
could add a "new" q= header). It doesn't hurt to keep it, though, as
it's so simple.
If we drop it, it would just get added back in later when some other key
publication mechanism is needed. That said, I'd rather leave an unused
but potentially useful hook in there versus removing it now only to have
it added back in later, possibly poorly.
l: Body length count
This opens up a whole host of security issues, related to being able
to change the rendered content of the message entirely after signing
without breaking the signature. Removing it would remove a security
hole you can drive a bus through. Is it being used? Are there any
situations where it has proved useful?
Despite the warnings we've posted about it, at least one site has
contributed patches to our implementation that extends its basic utility.
That means there's at least a little demand for its use.
z: Copied header fields
Has this been useful? Is it likely to remain useful beyond a testing
phase?
Yes, it has proven useful in debugging specific installations, not simply
specific implementations. -1 on removing it.
Is anyone supporting t=y in a DKIM validator? What does it do in terms
of delivery and communication with the sender that's different to
normal non-test usage? And is it useful?
Yes, we do. If a message fails and a customer has actually (against our
defaults and recommendations) configured the filter to reject mail that
fails signature validation, the "t=y" key drops the "fail" result to a
"neutral" one and avoids rejection.
I don't know if that's actually useful behaviour (our user base has been
slack when it comes to replying to such inquiries), but yes, we do have
specific code that pays attention to it. But I'm less insistent about
this one than I am of "z=".
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html