Murray S. Kucherawy wrote:
And you thought this list was dead.
I was asked to consult recently on some DKIM questions raised by a customer
of a former employer. The questions involved the meaning of "t=" in DKIM
keys and the text in RFC6376. The focus of this tag has always been, to
the best of my recollection, the notion that "We're only testing DKIM, so
please don't punish this mail if the signature fails to verify." We nearly
deleted this during the Draft Standard update because that's effectively
the same advice we give to failed signatures in general, making "t=y"
pretty much meaningless. The only interesting thing we say about it now is
that if a verifier wants to be extra helpful, it could collect extra
information about failed signatures referencing "t=y" keys to help the
signer figure out what went wrong.
That customer brought up an interesting point. "t=y" could also be useful
for messages whose signatures do verify. Specifically, it could be used by
a signer to say "It's possible this message shouldn't have been signed by
us. Please don't give it any preferential treatment based on our name's
reputation if the signature verifies, which could then tarnish our
reputation." Unlike the verification failure case, I don't think this has
any practical use by an attacker because it's explicitly declining any
special positive treatment. That means it's actually useful in the success
Any comments about this? I talked to Dave last week as we happened to be
at the same event, and he thought this warranted a new erratum against
I've opened a ticket to arrange that "t=y" suppresses any positive impact
domain reputation has in the next version of OpenDKIM, as an experiment.
Keep in mind this has been a deeply discussed concept since SSP and
My input has always been t=y should not be tolerated for long
durations. In other words, continued failures with t=y should allow
receivers to take action. It was meant to allow companies to test
trial the concept, not be used forever. There are domains out there
that still have t=y for years and their stuff always fails - pure
That was the somewhat the semantics that was added. Let me check..
ok, DKIM has:
Verifiers MAY wish to track testing mode results to assist the
That was the compromise text added after my input years ago because I
was never of advocate of t=y nor reporting ideas. I think I had
proposed text that actually added time limits, i.e. X months, Y Years,
etc to encourage domains to get their the stuff right before bad
reputations or direct actions weight in.
It was the same concern I had for SSP in draft-ietf-dkim-ssp-01 and it
was eventually removed by draft-ietf-dkim-ssp-02. Also keep in mind
that DKIM has a "Fail to No Signature" concept so a strong DKIM policy
could cause rejection. A t=y allows rejection to be preempted.
This is what I had for the 2006 I-D DSAP. I do recall others did help
with the text because I wanted to provide a start/end testing period
concept, i.e, once a receiver sees it, it can be used for a new entry
DB record and give the domain X period for testing.
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.
I was never an advocate of reporting ideas, hence see section 4.5
which added some of the same time limiting ideas as well.
Verifiers should be aware this reporting address can be a source of
an report attack vector (Section 7.4). One possible implementation
considerations would to limit the report to one report only and to
track the reception and/or response of the reporting.
I should note, that t=y topics and threads were pretty extensive and
what I had in DSAP was done as I saw was a general consensus and
agreement from all the discussions, but again I, myself, was never a
reporting advocate. I accepted the consensus for a desire for it, I
just didn't support or add any code for it.
Anyway, I think what DKIM has now is ok although I was not really keen
with the "assist the signer" part. But it is good enough to open the
door to allow receivers to get "smart" about it if abuse is seen. I do
think that when abuse does become obvious it doesn't matter if it has
t=y or not, but if it does, it can help make the decision faster to
act on it.
If your open ticket reflects what I am writing here, then I agree its
probably good to clear that up.
NOTE WELL: This list operates according to