One interesting take away is that the corporate email servers were less likely to have SPF and DKIM in use. On the weekends, more email was sent from home users who tended to use Google, Hotmail, etc., which did use SPF and DKIM.
I will admit my original intent on getting SPF and DKIM was to get a good score from SpamAssassin. You would think corporate emailers would want this as well. This went out on hacker news a few days ago : https://news.ycombinator.com/item?id=11396089 Original Message From: Viktor Dukhovni Sent: Saturday, April 9, 2016 7:42 PM To: postfix-users@postfix.org Reply To: postfix-users@postfix.org Subject: Re: reality-check on 2016 practical advice re: requiring inbound TLS? On Sat, Apr 09, 2016 at 09:36:09PM -0400, Curtis Villamizar wrote: > > https://www.google.com/transparencyreport/saferemail/ > > https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf > > https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security > > Thanks for the links. I emailed one of the authors asking why so > little was said about DNSSEC and nothing at all about DANE. https://www.ietf.org/mail-archive/web/uta/current/msg01458.html https://www.youtube.com/watch?v=36WDbfKEIRI (final minutes of Q&A) https://www.ietf.org/mail-archive/web/uta/current/msg01459.html Short version from my perspective: The authors seem to have STS/WebPKI tunnel-vision and appear to be buying the party line that DNSSEC is too difficult to deploy, while underestimating the deployment timescale for STS. STS can only be deployed quickly between the handful of large providers, and, on that scale, they have simpler means to exchange the same data without new complex protocols. This is of course much faster than deploying DANE for a substantial fraction of the Internet. Deployment of STS for the Internet at large is unlikely to be much faster than doing DANE at the same scale, and DANE is less kludgey in this space. That said, we may well support both at some point, when STS becomes stable enough. It need not be an either/or story. -- Viktor.