On 12/17/2016 8:15 PM, Theodore Ts'o wrote:
On Sat, Dec 17, 2016 at 06:38:07PM -0800, Dave Crocker wrote:
4. The folk using DMARC for c2c are not seeing a significant problem from
that use and they do report significant benefit. Sitting here in the IETF,
we might not like their assessment, but it's their business, not yours or
mine.
Right, the problem is not with c2c, where the affected mail might be
0.5%. But for d2d (developers to developers), it's much more serious.
First, what makes that demographic distinctive? Are there any other
distinctive demographic groups that might share the solution space?
Second, it is such a narrow (and small) demographic, any requirements
specific to it are likely to need solutions specific to it.
5. The IETF has no meaningful leverage over those service providers. Any
thoughts about what to do should keep that in mind.
That's been clear. To the extent that though that some service
providers might want to have developers stay on their platform because
they might be powerful influencers, there might be *some* influence,
but it is admittedly very little.
The world of consumer-oriented email deals with scale that makes the
'developer' market segment almost unmeasurably small. It is unlikely
any consumer service is going to want, or be able, to make adjustment
for the developer segment.
7. The providers' affected users have no leverage on their providers.
None.
Well, it *might* be that Google might not appreciate headlines of the
form, "Linus Torvalds is leaving gmail because Gmail has become
fundamentally incompatible mailing lists", but it is again,
admittedly, very small.
Yahoo's original foray into expanded DMARC use incurred that possible
expense and, again, the effect was immeasurably small.
8. It is easy to tell those providers' users that they should go to a
different provider, but take a look around for choices of consumer email
providers: there are precious few choices on the Internet today. And for
the affected consumers, they need a free, well-run provider who operates at
scale.
So what we might end up with, in the long run, is mailing lists will
only work with developers who switch to mail services such as, for
example, fastmail.fm.
Name 3 others that have a significant operational history, very good
reputation, very low fees, and are likely to be able to handle a
significantly increased user base.
9. ARC is expected to help this situation, but I suspect it won't be as
much help as anyone would like. At the least, it requires adoption by both
the mailing lists and the receiving MTAs, and that's a lot of adoption to
require.
I have the same worry that ARC may not do as much to help as has been
hoped. Certainly not in the short term. That's because it won't just
be mailing list servers that will need to adopt ARC, but also mail
forwarding services such as those used by alum.mit.edu,
alumni.stanford.edu, linux.com, etc.
Yes, forwarding services are another form of message re-posting. The
differences from mailing lists are significant, but not with regard to
DMARC issues.
I suspect the best in the DMARC world where ARC turns out not to be
completely successful is a setting where mailing list recipients can
specify whether their mail service honors DMARC requests, and if it
does, *and* if the sender is one that has a DMARC policy, the From
field will have to get mangled, and if that screws up the recipient's
Yahoo or GMail contacts database, it will be up to that mail provider
to decide how to deal with it.
Expecting end users to take such actions already crosses over into an
extremely high barrier against adoption.
I believe some mailing lists have adjusted to detection of DMARC (maybe
just when p=reject?) for a given author by making author From: field
changes /only/ for such authors. They don't make changes when mail is
from non-DMARC authors.
This restricts the scale of the disruptive effect, but doesn't change
its nature.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net