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