What you miss is that mailing lists are not the whole scope. All forwarding creates trust problems and all modifications by intermediaries will cause trust problems.
Modification is done by many spam filters, and the prevalence of modification seems to be increasing. If any of that traffic is auto-forwarded, it also has the mailing list problem. Reverse transformation may help with the modification problem but it cannot help with the larger problems of forwarder trust. And there are many users of forwarding. A forwarder needs to do more than gain trust that it did nothing unacceptable, it also must help the recipient conclude that the originator did nothing unacceptable. We have lacked a strategy for doing this. Right now, forwarding under SPF and DMARC causes important information to be discarded. So they make the forwarding trust problem worse. Unverifiable Received entries make the problem even harder. ARC is a technology which should be able to address the forwarder trust problem, whether modification occurs or not. Whether it currently conveys all of the needed information to satisfy recipients must remain to be seen. I do not believe that it does at present, but I believe that it could and should. On Thu, Dec 10, 2020, 6:23 PM Michael Thomas <[email protected]> wrote: > > On 12/10/20 2:58 PM, Dave Crocker wrote: > > On 12/9/2020 3:05 PM, Michael Thomas wrote: > > we know that amount of traffic going through mailing lists is tiny -- like > a couple percent. > > > Keeping in mind that mailing lists have been a legitimate Arpanet/Internet > email activity since the start of network email and that it is DMARC that > created operational problems, rather than mailing list activity creating > problems, the onus for declaring a nearly 50 year activity no longer > supported should be pretty compelling. It should not rely on anecdotes or > the views of an isolated few. And it certainly should not justify the > change with some broad, cavalier claims about security. > > For starters: > > - Please document attacks and other misbehaviors that have been > attributed to mailing list operation > - Please provide objective, validated documentation for you assertion > that the traffic through mailing lists is tiny. > - Please include similar substantiation for the percentage claim > - Please explain how this type of long-standing legitimate activity > can reasonably be otherwise conducted; a generic reference to the web is > not sufficient; what is needed is a point-for-point evaluation of mailing > list group and technical functionality and an comparison to replacement > choices. > > > This assumes that the IETF has any say whatsoever in this matter. It > doesn't. DMARC and ADSP before it gives the world the ability to say "i > don't care about mailing lists". Apparently Yahoo is one of them. That > horse has left the barn. Many domains would rather the security > improvements with p=reject. And it's not mailing lists that are the problem > per se, it is that the security posture that facilitating them leaves > organizations vulnerable to phishing attacks. Many organizations are giving > that a nope, and there is nothing we can do about that. > > There are many things that had their day and died because they couldn't > adapt, were redundant, or their time was just over. Usenet is a great > example. After 16 years of trying to deal with the mailing list problem, > we're right back where we started. Murray's hacks for recovering the > signature are not different in kind to my heuristics and hacks I did 15 > years ago. And ARC seems to boil down to requiring the previously unsolved > problem of "trusting" the mailing list. > > So no, I won't be doing any of those things because they are completely > beside the point. Feel free trying your hand solving it. > > Mike > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
