Jeff Macdonald wrote:
This validates what I have always been felt is the high promise for
DKIM exclusive (1st party or passive 3rd party) operations. �Policy is
inevitable to facilitate policy (domain expectation) fault detection.
Yet 55.8% of the keys were tagged as being in test mode. I also
suspect that many implementations don't offer any alternative than 1st
party. I believe this is true for IronPorts. It be interesting to see
a MTA breakdown in respect to 1st and 3rd party signatures.
Lets keep in my that this report includes an interoperability testing
event that took place 3 years ago, when POLICY still on the table.
Yet, at the time the main two libraries in year, in particular ALT-N,
the host of the event, had SSP support built-in in its open source
library! The sendmail library also had SSP support. They both
followed RFC 5016 "Requirements for a DKIM Policy."
In any case, things has changed drastically in the last three years,
and we will need "three" more years before more good information can
be used.
Sure, millions of domains are signing but with little wide-spread payoff.
That is whats missing in this report - the PAYOFF.
The fact is this - 1st party signatures is dominant and the continue
effort to nullify that "tidbit" doesn't seen to help anything by deny
a reality.
As long as 100% of the domains sign with a 5322.FROM there will also
be an binding and none separating association regardless on how much
we want intermediary freedom to sign mail.
--
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