John Levine
2016-12-18 02:28:23 UTC
+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 theprovider 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, ...
conspiracy theorizing. 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.
Yahoo management knew this would screw up every mailing list in the
world, and they explicitly didn't care. 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 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.)
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 bloodto find another mechanism to participate in IETF work, that is
the fault of the provider, not the IETF. ...
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.
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.
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.)
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.
R's,
John