Ale, this thread is about choosing a path for Trent’s document, not discussing details of ARC. Please keep your comments to the topic at hand.
Seth, as Chair -mobile On Thu, Feb 5, 2026 at 15:51 Alessandro Vesely <[email protected]> wrote: > On Thu 05/Feb/2026 15:58:54 +0100 Baptiste Carvello wrote: > > Le 04/02/2026 à 17:36, Alessandro Vesely a écrit : > > > >> […] ARC-sealing wouldn't be needed for forwarders > >> who do proper DMARC filtering, but mailing lists don't seem willing to > >> change. […] > > > > what do you mean by that? The "DMARC vs mailing lists" problem has been > > repeatedly analysed for more than a decade, and there is nothing the > > mailing lists alone can do to solve it. > > > Mailing lists suffer all the harm DMARC can cause, but reap none of the > benefits it can bring. This list accepts any message whose From: header > contains a subscribed address, regardless of any authentication. This > way, > attackers who obtain a list of addresses (easy, since the archive is > public) > can flood the mailing list, and consequently its subscribers, with their > spam. > This is why ARC provides the Arc-Authentication-Results: header field. > > > > Many still have adopted unsatisfactory workarounds as a stopgap. What > more > > can we possibly ask from them? > > If you knew the list applied DMARC filtering, DKIM signatures would be > sufficient to whitelist it. ARC is only needed because it doesn't. > > Anyway, this is just theory. We don't have a protocol for whitelisting > allowed > streams. It would require the receiver to track the subscription/ confirm > process. > > > Best > Ale > -- > > > > > _______________________________________________ > 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]
