----- Original Message -----
From: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
To: "Jim Fenton" <fenton(_at_)bluepopcorn(_dot_)net>; "william(at)elan.net" >
Somewhat at odds with this is the t= flag, signifying testing. We
should recognize it for what it is, a request to the verifier/recipient
to "be gentle" in the event of a failure.
And my receiver will say,
"ok, but you better hurry up with your Migration and Testing,
because this behavior will not be acceptable over an
extended period. I'll be watching you. And by the
way, your 1 year test key expiration is way too long.
I will limit this behavior of yours to X month(x)."
In my view, TEST MODE is a very unique operation. It basically says, you
ain't ready for production mode operations. So anything that comes out ?>
of it should be viewed as void. This should be one mode that is
watched by receivers and clocked for long term usage.
This is a threat entry point.
Real life example: Microsoft Caller ID Email Policy (MSCEP)
MSCEP is an early proposed LMAP protocol, a early clone of SPF, before the
merger of the two become SENDER-ID.
Do a DNS TXT record lookup for: _ep.hotmail.com
_ep.hotmail.com text =
"<ep xmlns='http://ms.net/1' testing='true'>
After nearly 1.5 years, this "deprecated" concept is still in TEST MODE by
Microsoft's HOTMAIL.COM domain.
Either some engineer forgot to pull it or Microsoft is still working with
MSCEP. Either way, Microsoft raised the bar and the TEST mode is ignored by
our receiver suite of LMAP technology detectors. We knock out all the
non-conforming HOTMAIL.COM abusers.
Hector Santos, Santronics Software, Inc.
ietf-dkim mailing list