On Wed, Jul 25, 2012 at 10:42 PM, Roland Turner <
This appears to be the inverse of the use case that was originally put
forward ("we're concerned that we're signing rubbish, please disregard
signatures made with this selector"); the very case that you're arguing
should be sustained despite t=y (considering negative reputation gained
because rubbish is being signed) is exactly the one the ignoring of which
started this discussion, no?
I wonder whether it would make more sense to view t=y as a holdover from
DomainKeys and its o=-; that the need for a "testing mode" in fact only
arose from the need to be able to tread carefully around making a "we want
some (presumably fraudulent) mail with our name on it blocked" assertion.
If this view prevails then t=y is merely a vestige that should have been
removed when o= was punted to SSP/ASP/ADSP.
I'd suggest that the opportunity to remove the (small) complexity
represented by a feature that's not solving a useful problem (and has to
some extent been superseded by DMARC: "if you're not yet confident then
stay at p=none") is worth taking.
We could, if we ever want to change DKIM again. It sounds like Barry's
approach to register a new "t=" value, or a new tag altogether, is a viable
path forward until someone decides to take up the reins and push DKIM to
Internet Standard status.
NOTE WELL: This list operates according to