+1. FWIW, I have to agree with Ted here. When a large mail
provider knowingly and unrepentantly does something that
violates well-established and well-defined standards and fouls
up mailing lists for others, especially when that provider also,
within their business model, pushes a "forum" service that is an
alternative to those mailing lists, and then effectively says
"everyone else needs to adapt to what we are doing", we should
not be rushing to make the Internet worse by adapting to those
moves. If that large provider joins with other large providers
to either develop the technique or push it on others, that is
known in some countries as a conspiracy in restraint of trade,
and, again, not something about which we should be participating
or abetting.
If the net effect is that users of that provider's systems have
to find another mechanism to participate in IETF work, that is
the fault of the provider, not the IETF. And, as Randy
indirectly mentioned, if that provider has repeatedly been the
victim of attacks that compromise user information at very large
scale, we may sympathize with them as victims (even through
failure to notify the people whose information was compromised
for months should reduce the sympathy level somewhat) but, if
any action by us is called for, it is reviewing our security
standards and recommendations to see if more or different
measures should be explicitly recommended as best practices.
If the best practices are already clear and that provider is not
following them, it is Not Our Problem except insofar as some of
us, in other capacities, might suggest either that their users
move sensitive information elsewhere or support non-technical
mechanisms for getting the provider's attention.
Just my opinion, of course, but the fact that a provider has a
zillion users doesn't mean that a "running code" doctrine mean
that we need to change standards or internal IETF practices to
conform to what they decided to do any more than the observation
that they have allowed personal data for many of those users to
be compromised makes that ok.
best,
john
--On Saturday, December 17, 2016 10:14 -0500 Theodore Ts'o
<tytso(_at_)mit(_dot_)edu> wrote:
On Sat, Dec 17, 2016 at 03:20:17PM +0200, Yoav Nir wrote:
It's hard to move the pain in a predictable way. If I send
you an email message and it's not delivered or gets mangled
or goes in your spam folder, who feels the pain? That depends
on which of us needs the email more.
The primary problem is that DMARC is fundamentally flawed, and
was not enacted using a standards process that respected all
of the stakeholders. As a result, it fundamentally becomes a
matter of power politics.
If there are a bunch of people who need to participate in a
particular mailing list --- say, IETF mailing list or the
Linux Kernel development lists --- more than they need to
stick with a particular mail provider, it becomes possible to
say to them, "you want to participate in our community"?
Change mail providers.
In the cases where a mailing list community badly needs the
Yahoo users, Yahoo can dictate to the mailing list --- change
your mailing list software and inflict pain all off your
mailing list users, or you don't get access to our e-mail user
community.
The group you want to feel the pain are the administrators
who add DMARC records, but other than spamming them with
error reports, there's not much we can do. I don't think
the administrators at Yahoo care too much whether their users
are able to use IETF mailing lists or not.
As a proxy we can "punish" those senders who have a DMARC
record for their domain.
If we do nothing, their messages sometimes get lost. They
have real problems participating effectively in the IETF
unless they switch to using gmail or hotmail accounts like
many of us have already done. But that gives us pain as well
because we're missing messages as long as they keep using
their own accounts.
Yeah, it's the "sometimes mail gets lost" problem which is the
main issue. So it might actually be better to have the
mailing list software refuse to accept a mailing list posting
from a domain with a DMARC record, and it can be bounced back
to the sender immediately with a "sorry, try again using some
e-mail address that does not have DMARC support".
But again, doing this fundamentally is a game of power
politics --- just as DMARC being inflicted on the entire
e-mail ecosystem was a matter of power politics.
Cheers,
- Ted
If we apply the mitigations only to such accounts, we solve
the bounce issue, but then depending on the solutions we
poison some of the other participants' email addresses, or
we make the UI show weird unhelpful things. Seems like
everybody else gets the pain.