The problem, Seth, is that you cannot write a good document unless you know what a successful implementation looks like. Ale has a successful implementation, and he knows that a successful implementation is "inspired by" RFC 7489, not guided by it.
In response to the charter, the group needed to write a "Best Practices" or "Applicability Statement" document, not a recapitulation of RFC7489. An A/S that draws on successful implementations would help others from falling into the trap that AOL's p=reject created for mailing lists. The group could have spent part of the last 10 years comparing notes about what each of us have learned from our successful implementations. Then we could have spent our time trimming our pooled knowledge down until it fit in the confines of an RFC document. Unfortunately, we have very few successful implementations represented, and disinterest in the ones that have been presented. Perhaps the dominant view is that a successful implementation of DMARC is not possible. The document before us is a mixture of pooled ignorance and hypocrisy. How many work group members have the intention and power to implement this work product because they believe it solves problems that could not be solved previously?. This group and its document have a legitimacy problem. Ale threw you a lifeline and you threw it away. Doug On Tue, Mar 4, 2025 at 9:58 PM Seth Blank <s...@valimail.com> wrote: > 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 < > dougfoster.emailstanda...@gmail.com> 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 <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 >> > > > -- > > *Seth Blank | Chief Technology Officer* > Email: s...@valimail.com > > > 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 -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
