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