Re: DMARC methods in mailman --- [LEDE-DEV] DMARC related mass bounces / disabled subscriptions (fwd) Jo-Philipp Wich: [LEDE-DEV] DMARC related mass bounces / disabled subscriptions

[Dave Crocker <[e-mail]>]

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