--On Sunday, December 18, 2016 02:28 +0000 John Levine
<johnl@xxxxxxxxx> 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