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 2:14 PM, Brian E Carpenter wrote:
> I don't. Accept the posting but also send a friendly warning seems to do less damage.
>
>> The DMARC policy is not to forward, and we should respect it.
> Why does DMARC, which is a broken solution, deserve that much respect?
>
>> When ARC gets standardized, we should implement it.
> Assuming it solves the problem, sure. But if it doesn't, the problem will
> get much worse.


Folks,

I am probably more frustrated about the expanded use of DMARC than most 
folk, since I participated in creating the DMARC spec.  For the 
constrained scenario that motivated its design -- let's call it b2c -- 
it works pretty well.  The expanded use -- let's call that c2c -- was 
initially the ad hoc choice of one service provider, but it turns that 
quite a few others also like it: there is a broad-based belief in that 
community that aggressive requirements for author authentication will 
alleviate many abuse problems.  On the average, the downsides of that 
view do not resonate in that community.

At any rate, the expanded use is what's causing the problems.

There are some realities that folk should note, when forming their 
opinions about this problem:

    1. There is nothing 'broken' about DMARC.  There is a problem with a 
particular use of it, but the mechanism, itself, works as designed.

    2. Mailing lists have always been an odd architectural wrinkle. (I 
commend RFC 5598 to anyone interested in the formalities.) An author 
sends a message to the list address.  The message gets /fully/ 
delivered; that is, it goes into the mailbox specified by the mailing 
list address. The mailing list posts a new message.  Whether the mailing 
list retains all, or only almost all, of the original message, and even 
all of the original envelope (except a new envelope addressee list) it 
is a new message:  And this is worth repeating: if the message undergoes 
any changes beyond classic, minimal MTA addition of tracing information, 
the message being sent is a new message.  But the user-level experience 
is of an author sending to a collection of end recipients.  The users 
don't really experience this as a re-posting.  But the reason it's 
important to understand that it is, indeed, a different message than 
what the author posted is that mailing lists can and do do all sorts of 
damage to the original.  The essential challenge in trying to 
accommodate a mechanism, like DMARC, that is designed to work within one 
posting/delivery sequence, when there is more than one, is that we don't 
currently know how to make it fully seamless.

    3. The folk using DMARC are not violating any rules.  Some are 
causing problems for some of their users and some of the folk that their 
users interact with, but that's different than saying they are violating 
a protocol, or the like.

    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.

    5. The IETF has no meaningful leverage over those service providers. 
  Any thoughts about what to do should keep that in mind.

    6. Any thoughts about what to do should pay very close attention to 
who has to take action, how considerable that action is, how long it is 
likely to take for that action to happen, and what their incentives are 
for taking that action.  And remember that all of this has to satisfy 
business concerns, not good-neighbor appeals.

    7. The providers' affected users have no leverage on their 
providers.  None.

    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.

    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.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net