I submitted an unsubscribe request and was told I would no longer receive these
emails, and yet here is another one.
Since I "officially" followed the procedure, what do you recommend I do to STOP
these emails?
On Feb 7, 2014, at 3:00 PM, dkim-ops-request(_at_)mipassoc(_dot_)org wrote:
Send dkim-ops mailing list submissions to
dkim-ops(_at_)mipassoc(_dot_)org
To subscribe or unsubscribe via the World Wide Web, visit
http://mipassoc.org/mailman/listinfo/dkim-ops
or, via email, send a message with subject or body 'help' to
dkim-ops-request(_at_)mipassoc(_dot_)org
You can reach the person managing the list at
dkim-ops-owner(_at_)mipassoc(_dot_)org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dkim-ops digest..."
Today's Topics:
1. What does t=y actually do? (John Levine)
2. Re: What does t=y actually do? (Hector Santos)
----------------------------------------------------------------------
Message: 1
Date: 7 Feb 2014 15:31:18 -0000
From: "John Levine" <johnl(_at_)taugh(_dot_)com>
Subject: [dkim-ops] What does t=y actually do?
To: dkim-ops(_at_)mipassoc(_dot_)org
Message-ID: <20140207153118(_dot_)3210(_dot_)qmail(_at_)joyce(_dot_)lan>
Content-Type: text/plain; charset=utf-8
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.
R's,
John
------------------------------
Message: 2
Date: Fri, 07 Feb 2014 12:51:41 -0500
From: Hector Santos <hsantos(_at_)isdg(_dot_)net>
Subject: Re: [dkim-ops] What does t=y actually do?
To: dkim-ops(_at_)mipassoc(_dot_)org
Cc: dkim-ops(_at_)mipassoc(_dot_)org
Message-ID: <52F51D2D(_dot_)7030907(_at_)isdg(_dot_)net>
Content-Type: text/plain; charset=UTF-8; format=flowed
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
End of dkim-ops Digest, Vol 41, Issue 2
***************************************
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops