For Seth. As I have previously stated, I am not opposing adoption of the charter as it stands, but I do think Ale's language is more appropropriate.
To Alex/s questions,, which are also germane to the charter. DKIM2 may be technically perfect, but it will not solve the mailing list problem. Solving the problem with DKIM2 requires that: - every allowed poster adopts DKIM2 - every evaluator evaluates DKIM2 - every evaluator chooses to trust the mailing list's reversible transformations as innocuous and acceptable, - the mailing list and every evaluator make no mistakes related to encoding and decoding the transforms - the mailing list knows that every evaluator has granted that trust. Since mailing lists are not currently willing to collect data about the behavior of their recipient organizations, there is no reason to be optimistic that the last item will be achieved, even if the first four are completed successfully. This mailing list is a case in point. There is probably no need to mung Comcast addresses, because every participant is probably willing to trust IETF. But IETF has never asked, so they do not know. The mailing list problem is primarily a problem between the recipient and his evaluator, and therefore it is not really in scope for IETF. If my mail system admin blocks my favorite daily horoscope messages, will IETF get involved if Horoscopes4U.com complains in their direction? Of course not. For exactly the same reason, if I am missing messages from [email protected], this is an issue between my mail admins and myself, not an IETF problem. But of course, it does not really matter if my mail admins grant an exception that allows me to receive unmunged messages from the list. Unless the list knows that I have obtained an exception, and acts on that information, then nothing changes. The list industry wants some magic that makes all of their messages acceptable to every recipient, and does so without exerting any effort of their own, and this is silly. But the biggest problem is that the misuse of DMARC causes evaluators to act as if malicious impersonation is only dangerous when p=reject. DMARC has caused evaluators to move their attacks from p=reject domains to unprotected domains. In the last 90 days, I have zero attempted impersonations of citibank.com, and cannot remember when, if ever,they have been attacked. But I have 424 messages that impersonate Yale.edu. The mailing list problem proves that they do not accept impersonation of p=reject domains, but it also implies that it allows malicious impersonation of all other domains. Hence my assertion that the mailing list problem only exists if the evaluator serves his users poorly, by being indifferent to safe and wanted messages that get blocked, while also being indifferent to dangerous and unwanted messages that get allowed. The mailing list problem does exist in part because evaluators have misunderstood what DMARC can and cannot do, so it may be possible for IETF to fix that misunderstanding. It is really impossible to intelligently discuss whether ARC helps or hurts implementers until we have a shared understanding of the goals for authentication technology. Doug On Mon, Mar 9, 2026 at 7:44 AM Brotman, Alex <[email protected]> wrote: > Doug, > > I’m not sure why you equate lack of support for ARC with lack of interest > in solving the “mailing list” problem. I think there are many parties > interested in solving that case, and they’ve determined that ARC isn’t that > solution. Or perhaps, isn’t the solution they want due to other issues > that come with implementation (which are enumerated in Trent’s draft). I’d > say based on the interest in DKIM2, there are parties interested in > resolving that particular problem. > > > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > > > > *From:* Douglas Foster <[email protected]> > *Sent:* Monday, March 9, 2026 7:15 AM > *To:* Laura Atkins <[email protected]> > *Cc:* IETF DMARC WG <[email protected]> > *Subject:* [dmarc-ietf] Re: Proposed Recharter to Conclude the ARC > Experiment > > > > I would certainly like to believe that evaluators need no advice because > they know what they are doing, but the evidence suggests otherwise. > > > > The "mailbox problem" indicates that evaluators are not acting in the > interest of their users, by blocking acceptable messages that users want. > It also indicates, indirectly, that evaluators are failing their users > because they are configured to accept some malicious impersonation that > they should be blocking. > > > > Doug Foster > > > > > > > > > > On Mon, Mar 9, 2026 at 6:45 AM Laura Atkins <[email protected]> > wrote: > > > > On 8 Mar 2026, at 20:59, Murray S. Kucherawy <[email protected]> wrote: > > > > I think we're going in circles here. You're saying there might be value > in ARC worth pursuing, and we won't know unless we try. But for "try" to > happen, there need to be people interested in putting in the work to get to > the answer. I'm not the one that gets to make that call, but I think > there's a dearth of interest in doing so. > > > > Putting it in the charter doesn't guarantee people will show up to do the > work. In fact, part of chartering a WG is asking "Who will do this work if > we charter it?" and, well, I personally think the answer is plain. > > > > Following on to this. Big mailbox providers have done the work to > implement ARC signing on their mail. We’ve heard from a few major mailbox > providers they have looked at using the data on the inbound. They aren’t > interested in working on more experiments in ARC. > > > > I don’t think there’s anything here and we should just end the ARC > experiment. > > > > laura > > > > -- > The Delivery Expert > > Laura Atkins > Word to the Wise > [email protected] > > Delivery hints and commentary: http://www.wordtothewise.com/blog > <https://urldefense.com/v3/__http:/www.wordtothewise.com/blog__;!!CQl3mcHX2A!Dln8pxYfwtpEt76WgweiNBTmH9WTb6Wv426tK9l6CB3qC-WZ6H5QG_ZYfVe5RsJ0jADdlwQmwaJ7n7p_O-7N_05kTMLoNCQ$> > > > > > > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] > >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
