--On Sunday, December 18, 2016 02:28 +0000 John Levine
<johnl(_at_)taugh(_dot_)com> wrote:
In article <9AD6AAD6812D3B9F8379226B@PSB> you write:
+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, ...
While I am no fan of what Yahoo has done, I think we should
limit the conspiracy theorizing.
I really didn't claim a conspiracy. I was just pointing out
that, intentionally or not, they stood to benefit from
disrupting mailing list traffic, IANAL, but antitrust lawyer
acquaintances tell me that, if a player is sufficiently dominant
that its behavior can cause damage to smaller actors and that
damage works to its advantage, intent may not be a requirement
for violating the law.
I have it on excellent
authority that the reason Yahoo turned on DMARC was entirely
the user complaints about spam with forged addresses taken
from stolen address books. It had nothing to do with Yahoo
Groups.
I have no doubt that you are correct. However...
Yahoo management knew this would screw up every mailing list
in the world, and they explicitly didn't care.
And that is the point. It was also the point of mentioning the
potential antitrust situation because I imagine that initiation
of such an action would get the attention of Yahoo management
even if the cries of some small (or even large) number of
zero-revenue mail users would not.
I'm reasonably
sure that the people who run Yahoo Mail had different opinions
but they didn't get to make the decision. While it is true
that it would not be hard to circumvent DMARC, crooks are as
lazy as the rest of us and I continue to be surprised at the
amount of phish stopped by DMARC's simplistic checks.
I will defend Yahoo's right to run a mail service that offers
increased protection against some types of attacks, as long as
they accept responsibility for breaking some services and uses
of email, just as I will defend others who choose to violate
Internet standards -- that is why those standards are voluntary.
But the community has the right to quarantine bad behavior
rather than trying to figure out not-quite-as-broken-workarounds
to the damage they cause. Their users can then decide whether
to live with the restrictions or to move elsewhere.
I hear that the amount of legit mail that DMARC breaks is well
under 1% of the total non-spam mail at large providers, and
even though they know it is mail that the recipients are very
interested in, it's hard to make a business case for doing
something for that 0.5 % unless they are very sure it won't
let a lot of the phish back in. That's the rationale for ARC,
which is a complicated crock, but lets the provlders make a
reasoanble guess about what's non-spam from mailing lists.
(FYI, they also tell me that legit lists leak spam all the
time due to compromised or forged subscriber accounts, so it
has to be more than just whitelisting the lists.)
ok. And so? I can remember, and I think you probably can too,
when it was necessary to maintain email accounts on several
different providers because the gateways didn't quite work
(because gateways between disparate systems never completely
work). That would be a sad result of all of this and the
associated anti-spam/ anti-phishing efforts, but it is outside
the IETF's power to control the situation.
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. ...
I appreciate the theory, but we also need to consider how much
blood loss we are willing to accept to cut off our noses to
spite our faces. It is pretty clear that within the next year
Gmail will turn on a DMARC policy, too, and I expect other
large mail providers to turn it on, too.
That reasoning leads to the ability of a handful of large
providers to dictate the way email works in practice. To
exaggerate only a bit, if that is the situation, the IETF might
as well go out of business, at least at the application layer.
On the other hand, if you are measuring blood loss, some of us
manage a sufficient volume of email that a switch to some of the
remedies that have been proposed would drive us out of the IETF
or at least off of several of the IETF-related lists to which we
now subscribe. There isn't an option, other than more careful
and carefully-configured use of DMARC (if even that is
sufficient) that avoids shedding any blood at all. So the
question is not "how much we are willing to accept" but whether
we prefer to shed the blood of those who are violating the
intent of the standards (and I think that intent is a bit more
clear than Dave Crocker's recent note implies) or the blood of
those who are avoiding doing so.
If we tell people, sorry, you can't participate in the IETF
using the giant mail providers you use for everything else,
what do you expect the response to be? Wow, what a bunch of
noble principled idealists, or wow, I don't have time for this
nonsense, maybe I'll go work on some open source stuff on
github instead. We have enough trouble recruiting people now
without putting more roadblocks in their way.
Again, please don't think of it as keeping everyone if we make
kludge-level changes to accommodate Yahoo-style use of DMARC
versus losing people if we don't. Either option is likely to
lose some people and the questions of how many and how valuable
are probably impossible to assess. Ted T'so's observations
about developers are particularly relevant in that regard.
A few of us have been doing some experiments on DMARC
avoidance, looking to see if there's something we can do that
will survive DMARC, not screw up the mail too badly so it's
legible and recipients can reply reasonably, while uglifying
it to remind people whose fault it is. Some of the
possibilities involve wrapping the real message in an outer
one, some involve changing the From: address to a mutated
version of the sender's address (*not* the list's address.)
I look forward to your report on the results of those
experiments. As with ARC, I presume alternatives will need to
be deployed to be really useful and effective, but I'd be happy
to be wrong.
Maybe ARC will work well enough that we won't have to do
anything, but I expect ARC will be a half solution at best,
since it assumes recipient MTAs have a rather sophisticated
filter system that can handle all the stuff in the ARC chain
of forwarding headers.
I'm trying to adopt a wait and see attitude.
best,
john