Charles Lindsey wrote:
Surely, t=y will be used in one of two scenarios:
1. Someone is intending to roll out DKIM, and is trying it out. He is
not sure whether he has implemented it right, so it may fail.
But in that case there will be no SSP record, or if there is one it will
say "we do not sign (yet)".
2. An existing DKIM user is rolling out a new algorithm. As before, he
may get it wrong and the signatures may fail.
That might be GOOD GUY scenarios. How about the EXPLOITED scenarios?
With those two provisos, the existing rule, to ignore any failed t=y
signature (as though there had been no signature) makes perfectly good
sense.
hahahahahaha. :-) Sorry. I just don't see how its not seen that what
you think is GOOD can also be BAD. :-)
And, answering another point that was made, it may make good sense to
report back to the signer on t=y signatures that failed, so that he can
fix his bug. A t=y user can reasonably expect to receive such reports.
OTOH, without a t=y attempts to regularly report failures would amount
to harassment, and are a Bad Thing.
Thats a different issue, but it highlights even further why something
like t=y should not be taken lightly.
What is to stop someone, for the sake of example, take cisco.com, and
create a forged messages complete all the DKIM markings, and does so in
an highly efficient manner by wasting no time in creating or trying to
create a fake hash, and just create a fast random junk hash and blast
the world with spam and/or malicious eViruses?
Is this not familiar today with/without DKIM?
If DKIM/SSP is suppose to help some DOMAINS here, then it is important
that t=y is not abused and/or forgotten. For the SAKE of the domain own
reputation, it is in its ADVANTAGE and BEST INTEREST that it is removed
as soon as possible. Never mind the "GOOD GUY" usage, it is the BAD GUY
exploitation I am worry about.
I don't want to waste alot of time adding DKIM/SSP to our own outgoing
mail, only to have exploiters FORGE our mail because we have a t=y.
Once we remove the t=y, I expect to be protected when this FORGED mail
hits DKIM/SSP compliant sites. By keeping in there, I am not doing
myself a favorite. I would think all HV domains would agree that the
expense in adding DKIM requires that they don't reduce their investment
by exposing t=y for any prolonged period.
All I ask is for better clarification on this t=y and to highlight its
danger and should be used with extreme limits in scope and time.
--
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