Good Show! Some inline comments:
Paul Midgen wrote:
I wanted to address Hotmail's use of ADSP, clarify our position
on the issue of authentication policy, and share a few bits
of information the list may find interesting.
Hotmail's use of DKIM+ADSP should not be interpreted as
a political statement;
And it should not need to be. Is Live.com included?
we implemented DKIM to offset the impact of well-known SPF
false-failure scenarios. We viewed DKIM+ADSP as a package deal
and a first step to fully integrating authentication policy
controls into our delivery pipeline.
Fantastic! It was Microsoft's entry into SPF that started MARID and
hopefully some IETF eyes will see restarting IETF policy standard
development efforts again.
SPF fails for ~1.5% of our inbound traffic, so that's the
percentage of mail for which we currently run DKIM. The next
phase of our DKIM project begins soon and will expand
DKIM's "scope" to all non-passing SPF results, or ~49% of
total inbound volume.
We have eight years worth of statistics at:
http://www.winserver.com/public/spamstats.wct
The LMAP column includes SPF, and the early DMP and Microsoft's XML
version of SPF "Caller Id Email Policy" (CEP) which by the way is
still alive for hotmail.com. :)
nslookup -query=txt _ep.hotmail.com
Non-authoritative answer:
_ep.hotmail.com text =
"<ep xmlns='http://ms.net/1' testing='true'>
<out><m>
<indirect>list1._ep.hotmail.com</indirect>
<indirect>list2._ep.hotmail.com</indirect>
<indirect>list3._ep.hotmail.com</indirect>
</m></out>
</ep>"
For many years, SPF was low percentage, probably like your 1.5 if you
average it out since 2003. But it began to climb as more SPF domains
switched to hard fails. This month, you can see its 6.2%
BTW, we reduced the DNS overhead by 60% by checking SPF after RCPT is
determined to be locally valid. This follows the tip in SMTP RCF5321
section 3.3:
3.3 Mail Transactions
.....
Despite the apparent scope of this requirement, there are
circumstances in which the acceptability of the reverse-path may
not be determined until one or more forward-paths (in RCPT
commands) can be examined. In those cases, the server MAY
reasonably accept the reverse-path (with a 250 reply) and then
report problems after the forward-paths are received and
examined. Normally, failures produce 550 or 553 replies.
We check ADSP every time we run DKIM and see the
following policy distribution:
97.98% "unknown" (including domains not explicitly publishing policy)
2% "discardable"
0.02% "all"
Which is expected. SPF showed similar, if not lower startup percentages.
We'll continue to evaluate ADSP's utility as we increase the
DKIM validation rate, though our research suggests the current
policy distribution won't profoundly change.
You might be surprise! Microsoft makes it know and there will be more
motivations for domains to add ADSP support to reach your users. It
will help increase the branding for business service operations.
Positive marketing will steer corporate customer mailings in your
direction. At the personal level, I will have more trust now to use
my alias hotmail.com account currently use for MSDN. Seriously, I
have lesser reasons to use my GMAIL.COM account now.
Moving forward, we fully support the creation of a mechanism
for deterministic authentication-based sender-published message
disposition policy as well as the feedback loop(s) necessary to
help senders overcome their reluctance to deploy aggressive policies.
Wonderful!
While we believe our authentication policy controls will
initially consume policy from intermediaries, we've designed
them to use DNS-based policy should a broadly-acceptable
standard emerge. We're taking the long view and betting that
such a standard is possible, and are looking forward to
being part of creating it.
+1. I have strong convictions Policy with be DKIM's White Horse.
Thanks for your input.
--
Hector Santos, CTO
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html