[ietf-dkim] Features that could be reconsidered as part of the bis process
Murray S. Kucherawy
msk at sendmail.com
Sun May 10 21:15:35 PDT 2009
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
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=".
More information about the ietf-dkim