Hi Doug,
At 17:07 23-05-2014, Douglas Otis wrote:
I have been asked nearly the same question by others. A section
will be added to explain the how and why and its impact on
privacy. Senders and receivers desire a scheme that improves
protection of the From header field. The business aspects of this
became extremely clear to PayPal by effects on their customers then
obligated to sift through massive amounts of email abuse. The
benefit of timely out-of-band notification instead caused an exodus
of customers. To staunch customer loss, direct appeals to major
ESPs to reject non-aligned PayPal messages helped, and helped
everyone. Unfortunately, direct appeal does not scale. Hence we
have a limited stop-gap scheme.
I was not thinking about privacy in that comment. Some time back I
looked into why abuse occurred in different systems. I was not
trying to understand the matter instead of trying to resolve
it. Note that I have read the relevant papers. Anyway, you did not
answer the question I asked. :-)
PayPal is the not really a good case in my opinion. I do not get
money by solving PayPal's problem. I might put it some effort as
encouraging abuse is not a good idea. A problem, which you
identified, is that a scheme would have to scale or else be workable
at some scale.
As has become extremely clear, although there was early evidence,
DMARC did not fully consider important "corner cases". It seemed
okay to leave these issues for receivers to sort out. Now AOL and
Yahoo! have made it evident receiver cooperation is in jeopardy. If
you are like most others, you have had malicious and socially
engineered messages from someone you know prompting you to click a
link or call a number, etc. Resorting to the only functional policy
scheme able to reject messages is understandable, but this came at a
dear cost. As John Levine describes, "a death by a thousand cuts".
If you push things too strongly I (as a receiver) would be no longer
be inclined to be cooperative.
Asserting whether all messages must have From/Source domain
alignment is somewhat analogous to the type of federation supporting
single-sign-on schemes. A federation has the purpose of protecting
identifiers. In other words using laissez faire protocols where the
strategy of "block on event" is inverted to become "accept on
event". In the case of DMARC + TPA, "accept on event" is derived
from DMARC feedback/log review accurately determining which domains
require exception. Further review can even characterize how domains
authenticate and which header elements confirm or narrow authorization.
I'll say ok to the above.
Cute comic. It is not really the information protected by a
federation scheme. It is not even the exclusion of bad stuff. It
is protection of federated identities by receivers implementing
DMARC + TPA. By using this scheme, associated identities can be
protected while also avoiding disruption of legitimate
messages. Even Eliot Lear's mother becomes safer. (I hope this is
the right example as it was discussed many years ago.)
The problem might be one of trust. I won't even try to analyze that
as it is going to end up being a lot of work.
Unfortunately, that approach now only works for authenticated
domains. :^( Dane anyone?
You'll have other problems then. :-(
Regards,
S. Moonesamy
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
