SM wrote:
At 04:35 09-11-2007, Hector Santos wrote:
I don't think I can avoid adding logic for a time table for domains
with t=y vs the # of failures. Domains with a high failure t=y rate
will be pre-empted, trigging a skip process and a "unsigned status."
If it continues, the domain will be blocked, and reported to RBL sites
- DOMAIN REPUTATION IS HARM UNBENOWST TO THE DOMAIN.
People are already evaluating domain reputation, with or without DKIM.
Of course, one might have a:
Non DKIM/SSP transactions:
POSITIVE REPUTATION --> OK
UNKNOWN REPUTATION --> Indeterminate
DKIM/SSP failed t=y transactions
POSITIVE REPUTATION --> OK? REJECT? BY REQUEST?
UNKNOWN REPUTATION --> Indeterminate? REJECT? BY REQUEST?
But in the real world, I am not aware of any open standard widely
adopted Positive Reputation system in place. Negative Reputation, scores
of DNS RBL sites. Using the negative reputation:
DKIM/SSP failed t=y transactions
NEGATIVE REPUTATION --> REJECT
UNKNOWN REPUTATION --> Indeterminate? REJECT? BY REQUEST?
So the verifier is left in limbo when there is unknown reputation,
negative or positive.
The point is that with wide adoption, a failed t=y, the odds are very
high there would be NO reputation to access leaving the verifier
continued abuse if t=y is honored. So lacking reputation or any other
layer specification, a perpetual encounter of failed t=y transactions is
not going to be ignored because by doing so, you are putting the
verifier, the primary domain and ultimately the end-users in harm.
One question is why would a DKIM domain testing his implementation have
a perpetual failure? That would not be the expectation.
I don't see how removing "t=y" would change that.
Well, to be clear, I wasn't proposing to remove or eliminate this
option. But that its definition be better fined tuned to real world
possibilities.
In a production environment, it only makes sense for the good primary
domain to perform their test quickly and remove that attribute as soon
as possible.
The message about the DKIM Interoperability event shows that even after
DKIM has been published as a RFC, there may still be some "bugs". Some
can be identified during interoperability testing while others may only
be noticeable in a production environment. It makes sense for a domain
to remove that attribute only when they are comfortable that their
implementation is working correctly.
Agreed.
Thanks SM. I appreciate your comments.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html