> On Sep 19, 2022, at 09:15, John Levine via mailop <mailop@mailop.org> wrote: > > It appears that Jim Popovitch via mailop <jim...@domainmail.org> said: >> On Mon, 2022-09-19 at 17:07 +0200, Alessandro Vesely via mailop wrote: >>> >>> ARC is the authentication of choice in this case because, being devised for >>> this task, it is supposedly straightforward to configure for it, whereas >>> whitelisting after SPF or DKIM smells like a hack. >> >> I wish ARC was straighforward to configure and implement, but sadly I >> haven't experienced that. ... > > I entirely agree that ARC isn't yet ready for prime time. I know the > guy who runs OpenARC and I believe he is looking for people to resume > work, but even at the big gorillas they are not yet using it to > fix mailing list filtering mistakes.
Arc's biggest problem is that nobody trusts it, because it's a second party sender. I.e. why should gmail trust lists.foobar.org <http://lists.foobar.org/> to sign for microsoft.com <http://microsoft.com/>. I mean, if foobar was known-trustworthy, then maybe. (Other examples, perhaps, might be nanog.org <http://nanog.org/>, mailop, ietf, etc). I run a fairly large mailman install at the day job, where we talk about a piece of open-source DNS software. I'd like to think we're trustworthy. We've had our mailing lists since before gmail existed :) Getting openARC running, using the standard FreeBSD port was not terribly hard, (but could have been more straightforward, I'll admit), and we're arc-sealing with our existing DKIM keys, using openARC. Those arc seals are validating, at least according to the validator gmail is running. I also have commit access to the Trusted Domain Project's repositories, and want to do more things with this, but I am not natively a C coder. I'm trying to wrangle community patches into play between github and sourceforge, get better documentation written, and spin up more CI infrastructure, as well as triage the "this needs code" fixes that someone else can review. My current task (as you may have seen in an earlier post) is trying to get a version of openDKIM that supports newer encryption types into a released version, and that I am sure also plays nice with openSSL 3.0 (i.e. doesn't just stop validating sha1 because some OS packager decided anything with that algo is bad) and also solving any latent CVEs. I think OpenDKIM has one, but it's about the test suite, which most people never run, but I'd like to fix it anyway. OpenARC could certainly use more docs about where in the milter chain to put it, and on which machines. -Dan
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
