Murray S. Kucherawy wrote:
On Mon, Jul 23, 2012 at 7:28 AM, Dave Crocker <dhc(_at_)dcrocker(_dot_)net>
Here are two small tweaks that might correct things:
y This domain is testing DKIM. Verifiers MUST NOT treat messages
from Signers in testing mode differently from unsigned email.
This covers both successful and failed verification.
Verifiers MAY wish to track and report testing mode results to
assist the Signer.
This isn't quite right, I think. For a signed message that verifies, a
negative reputation should still be considered applicable. A positive one
should not. That's not equivalent to unsigned.
It is if POLICY is applied. If the conditions are:
DKIM record has t=y
ADSP record has DISCARDABLE
MAIL is unsigned (or failed to verify)
Should ADSP processor honor the DKIM t=y? I don't think so since this
opened the door to abuse. This is why the t=y flag was pulled from SSP
draft rev2. This is why the text in I-D DSAP was:
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.
The issue is mixed up with the concept of domain experimentation and
reporting, the desire to report results to domains during a
testing/exploration phase and to make sure the receiver processor does
not reject their bugs during the testing phase.
Well, thats nice, but it opens the door for abuse and there are still
domains out there since 2006 with t=y causing waste in processing
their failed DKIM signatures, generally broken because it was passed
thru middle ware (i.e. list server).
But people wanted reporting, so in DSAP, a tag was provided for the
email address but also guideline to track and limiting the reporting.
DKIM doesn't cover reporting, so t=y can be considered less required.
But I see no harm keeping it in as long as receivers and publishes are
aware that it can't be used for change results. I think the current
text is sufficient, but clarification could be added if warranted.
Overall, I can see Advanced receivers do things like suggested in
DSAP, advanced implementations can explore time limits for failure of
domains with t=y before taking action. Tolerating it just waters it
done and no one will pay attention to it anyway, most likely many DKIM
implementations today. I know we don't honor it.
I don't see any difference in regards to "reputation." Either it
trusted or not, passes or Fail or unknown, same type of fail
processing has to be done.
NOTE WELL: This list operates according to