On Thu, 8 Nov 2007, Hector Santos wrote:
- A testing attribute should used for Migration ideas, by it its very
natural definition, a testing attribute is limited in scope and time.
We actually have to say that, i.e. define "testing", in an RFC?
- Not having any guidelines on how VERIFIERS will deal with perpetual
failures, especially those with a testing attribute, is a problem.
Why?
I don't see why this is not understood.
Conversely, I don't see why you think it's obvious.
Therefore, its going to be ignored just like in other similar ideas with
testing attributs, or the worst case is that it will exploited and used
to reject mail.
How can one exploit a test mode which is already explicitly telling
verifiers, "This may or may not work, don't trust the results"?
I guess if a DOMAIN addres t=y, then it really doesn't care what is the
deposition of the message. After all, its only a test.
Precisely.
My recommendation is basically spell out that no one should depend on it
and that no one should use it over extended periods.
See my first comment above.
Finally, yes, I agree, it does have some reporting ideas behind it, but
it still a LIMITED IN TIME concept. It can't be a persistent t=y issue.
One day, CISCO.COM will have to remove its t=y attribute from its
policy.
I'd bet real money that they will.
Thats all. It really isn't that hard.
We certainly agree there.
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html