On Wed, Jul 25, 2012 at 10:42 PM, Roland Turner <
roland.tur...@trustsphere.com> wrote:
> 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?
>
Pretty much.
>
> 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.
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
