ietf
[Top] [All Lists]

Re: "why I quit writing internet standards"

2014-04-20 13:26:16

On Apr 20, 2014, at 10:08 AM, Dave Crocker <dcrocker(_at_)bbiw(_dot_)net> 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