A better question is how many domains will move signing into production
without the testing flag, then fix the inevitable issues.
Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of SM
Sent: Friday, November 09, 2007 10:18 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Re: t=y
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. I don't see how removing "t=y" would change that.
Keep in mind that systems like SPAM ASSASSIN will be taught to watch
for such t=y marking. A verifier might just record all this and
this weight to the SA heuristics.
Yes, some people may do that. It's like assigning a negative spam
score to a message based on whether the DKIM signature verifies.
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.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html