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
