[ietf-dkim] Features that could be reconsidered as part of the bis process

[Murray S. Kucherawy]

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=".