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 <superu...@gmail.com> wrote: > On Fri, Feb 28, 2025 at 5:28 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> 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 -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
