Okay, everyone. I think this thread has run its course. As the working group is winding down with the bis documents moving through the IESG process, it's time to take these matters to either MAILMAINT or DKIM if there are solutions relevant under their charters.
Seth, as Chair On Tue, Mar 4, 2025 at 9:35 PM Douglas Foster < [email protected]> wrote: > I observe that my comments were in the context of a written proposal to > address the problem. > > It is a fundamental attribute of adulthood that one has to seek solutions > to one's own problems. The mailing list administrators and the mailing > list software developers should have been working together to solve this > problem a long time ago. That's how things get done in a market economy. > It is neither my job nor Ale's job to do this for them. > > But it is an IETF problem because IETF is a significant implementer of the > technology, and fully capable of either building a custom solution or > motivating a vendor to do so. Not only has it not done so, it has not > used DMARC to protect its lists from the most conspicuous form of > impersonation, as demonstrated by a white-hat research attack. > > The root problem goes back at least to RFC 7960, which laid out the > problem for all to see. Presuming that mailing list messages are wanted, > the problem is that evaluators were (and are) using DMARC to disposition > incorrectly, so they need guidance on how to use sender authentication to > allow wanted messages and block unwanted messages, even though sender > authentication depends on imperfect and crowd-source data. But it offered > no such help. > > When the evaluator is unwilling to make exceptions to support user's > wants, as apparently occurs at AOL/Yahoo, it becomes the sender's burden to > find a way to make the message acceptable. When mailing lists alter the > message, they become the sender for purposes of these evaluators. But RFC > 7960 gave no advice to mailing lists either. > > So the implication of RFC 7960, which has persisted into DMARCbis, is that > authentication and mailing lists are doomed to permanent conflict in a > negative-sum game. The effective goal of RFC 7960 and DMARCbis is to > promote reduced use of DMARC to protect mailing lists. They were here > first. Lists are not a party to DMARC. etc. Dave Crocker's proposal to > discredit the idea of RFC5322.From authentication is the explicit version, > DMARCbis does it more subtly. > > It is a false dichotomy. Sender authentication, used correctly, helps to > identify safe and wanted messages from acceptable senders. When > authentication is minimized, successful network penetration is maximized. > DMARC protects the student at Columbia.Edu from failing prey to an attack > that drains his Citibank account, but it does not prevent Citibank from > falling prey to an attack using a Columbia.Edu impersonation. > > I am sorry that so few people have tried to make them work together that > the group cannot imagine, and has not looked for, the solution. There is > a huge ethical problem created by the decision to position DMARC and > Authentication as mutually exclusive. Consequently, the DMARCbis document > should be rejected. > > Ale's document would be a good starting point for generating something > constructive rather than something destructive. > > Doug > > > > On Tue, Mar 4, 2025 at 1:59 AM Murray S. Kucherawy <[email protected]> > wrote: > >> On Fri, Feb 28, 2025 at 5:28 AM Douglas Foster < >> [email protected]> wrote: >> >>> It should be obvious that lists need conditional munging. Since the >>> feature is lacking, I have to ask why? The problem has festered for more >>> than 10+ years, so there has been plenty of time for new code to be >>> written. I have to conclude that people like to complain about the >>> problem but don't really care to get it fixed. This is especially true of >>> IETF, since they had the resources to develop a custom munging algorithm >>> but never had the motivation to make it conditional. >>> >> >> I think this paragraph betrays a misunderstanding of what it is we do >> here. If you think this needs to be done, do you have an implementation we >> can look at? Experimental test results? Anything beyond theorizing? >> >> Otherwise, I think I can reduce this to "This group needs to go implement >> this and standardize it" with an inferred "(but it won't be me)", and at >> some point that pattern becomes insulting. Speaking for myself, my time >> and energy is not unbounded. If you want something to happen in a group >> like this, it's on you to build consensus about it. Convince us you're >> right, that a general investment has a chance of paying off. Write a >> draft, show your work. Data wins arguments. >> >> Any real fix to the munging problem depends on the lists changing their >>> behavior. The lack of interest in Ale's solution, or anything like it, is >>> consistent with the historic pattern of whining about the problem rather >>> than solving it. >>> >> >> This tone doesn't motivate me to do much of anything but get annoyed. >> >> The way you sway consensus is not to cast aspersions, but to prove you're >> right. DKIM was successful because contemporaneously with development of >> the standard, we wrote the code and gave it away for free so people could >> test it live. There was broad adoption in lots of environments, so we >> could see it working, at scale, with many implementations. We could change >> or drop parts of the spec as needed because we could see they weren't >> working. >> >> Nobody is doing that here. So, before you accuse the rest of us of >> whining and inertia again, I'd love to hear your answer to this: Who has, >> or plans, to implement this idea? Any MLMs? Major clients? Anyone? Does >> it stand a chance of success? Why is this the right investment? >> >> Rough consensus and running code. >> >> -MSK >> > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- *Seth Blank | Chief Technology Officer* Email: [email protected] This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
