[ietf-dkim] Re: t=y

Bill.Oxley at cox.com Bill.Oxley at cox.com
Fri Nov 9 07:34:36 PST 2007


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.org
[mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of SM
Sent: Friday, November 09, 2007 10:18 AM
To: ietf-dkim at mipassoc.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



More information about the ietf-dkim mailing list