On Apr 20, 2014, at 10:08 AM, Dave Crocker <dcrocker@xxxxxxxx> wrote: > On 4/14/2014 8:28 PM, Scott Kitterman wrote: >> If that's true, it's my impression it's true because the DMARC proponents >> insisted any possible working group charter preclude meaningful changes to the >> base specification because the work was already done. > > > That statement is incorrect. > > What we pressed for was to get community rough consensus on the kinds of technical work that needed to be done to the -base (core) specification, /before/ chartering the effort. > > This was explicitly to avoid the trap of declaring the existing spec unstable -- and that's what starting an open-ended development effort automatically does -- when there was no demonstrated need to do that. > > In spite of repeated efforts -- in at least two venues -- to get folks to state what work they thought was needed and to get community support for that work, no tasks were produced. > > That meant that any wg charter permitting changes to the protocol would have been entirely without any foundation based on need. > > In fact, it would have a foundation of NON-need. Dear Dave, Each group sees need differently. The need driving DMARC was to prevent recipients being flooded by an onslaught of transactional phishing attempts that also involved establishing improved feedback to facilitate take-downs. Without this protection, there would be a high rate of customer loss, at least according to numbers provided by PayPal. They felt handling their domain's email policy by setting up arrangements with each ESP did not scale. That said, DMARC was never intended to address needs beyond the narrow scope of high value transactional email. There were early warning signs as well. Even Paypal employees initially posted to mailing-lists in clear conflict with their DMARC policy. That behavior was then replaced by linkedin.com, e-ngine.nl, junc.eu, and yahoo.com. There should have been clear warnings rather than expecting ESPs to deal with a flood of complaints. There is not enough header or transactional bandwidth to expect each email to authorize individual third-parties. The original TPA specification would have been able to address this with very low overhead. Is it reasonable to expect user desired third-party services to carry a high cryptographic burden for each unique message destination. It seems better to expect these services to simply verify their domain by currently available means. It is also common to find List-ID header fields declaring the path taken that can also be specified using TPA. TPA use could the be declared in conjunction with DMARC to allow each domain seeking protection from DMARC to make specific exceptions and effectively react to abuse. Had SMTP been properly federated, none of this would have become a problem, and it would have also avoided pervasive monitoring. Regards, Douglas Otis