SM wrote:
>> - A testing attribute should used for Migration ideas, by it its very
>> natural definition, a testing attribute is limited in scope and time.
>
> Yes. But it's not up to the specifications to define the scope
> and time.
It can be open-ended without specifics. The point is, domain risk harm
to themselves if they think t=y is going to be marginally viewed, There
is high potential for abuse. Extremely easy to do and Murphy's Law says.....
>> I guess if a DOMAIN adds t=y, then it really doesn't care what is
>> the deposition of the message. After all, its only a test.
>
> "t=y" means that the domain is testing DKIM. Some domains can run a
> test in a few days and reach a conclusion while others may require
> in-depth testing. The sender do care about the disposition of the
> message, hence the test.
There you go, you have some form of inherent scope and time.
Personally, I think systems with DKIM today are using it to mean "We are
in BETA mode!" because they had the t=y for years now. Which is fine,
but RFC4871 is official now. No one should expect it to be *PERPETUAL*
fail-safe concept and once, if ever, we get into full production with
wider adoption, I don't think it is will be tolerated, again, and I
repeat, especially when it *perpetually* fails.
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.
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.
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.
--
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