On 2/7/2014 10:31 AM, John Levine wrote:> An acquaintance notes that
many of his clients still have t=y in their
DKIM records. Do any DKIM implementations pay any attention to it?
RFC 6376 still says:
y This domain is testing DKIM. Verifiers MUST NOT treat messages
from Signers in testing mode differently from unsigned email,
even should the signature fail to verify.
which is fine. except that verifiers are supposed to ignore broken
signatures anyway.
Currently, we have no built-in action logic for DKIM results other
than processing and recording. ADSP has been abandoned and there is
no other policy layer augmentation to cover what domains expect. I
was among the advocates for the MUST NOT semantics in the description
above. DKIM processors should also ignore this testing flag when used
over any extended period by the same domain. IOW, testing and
migration phases should not be forever. If a DKIM processor is going
to learn (monitor) how a domain is operating with its mail, it could
for example, allow for a X time period for the domain to use the t=y
flag. In the 2006 DSAP proposal, for example, it is described this way:
http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-01.html#anchor22
4.7. DSAP Tag: t=y
The t=y tag is optional. If defined, the domain is currently
testing DKIM. Verifiers SHOULD
NOT treat testers any different from production mode signers. It
SHOULD NOT be used as a way
to bypass a failed signature classification policies. However,
verifiers SHOULD track testers
for over extended usage of test signatures and MAY consider using
the results to provide
feedback to the domain.
But right now?
Nada. t=y is ignored for our implementation.
Without a policy layer to helps puts some actionable material behind
DKIM, it is currently pure processing recorded waste. I would love to
finally find out where the DKIM payoff can be found. It seems we are
at a point where valid or invalid signature doesn't matter. We have
no policy layer to allow receivers to act on the behalf of the signer
wishes with zero false positive considerations.
--
HLS
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops