ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: t=y

2007-11-09 08:59:28
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