[GF-Users] OpenARC

[luca-ml at vom-bruch.org]

Or maybe not as relevant as I thought, even though google promoted in in 
2025. But now I read:

https://redsift.com/resources/blog/ietf-calls-for-end-of-arc-experiment-what-it-means-for-email-authentication


Am 2026-02-02 17:51, schrieb luca-lists at vom-bruch.com:
> Hello,
> 
> I was wondering if anyone would be interesting in having an EL rpm
> package for OpenARC.
> 
> The original OpenARC package included in the official repos by
> trustedomainproject seems mostly dead.
> 
> There is a fork that is maintained and works fine I think. (compiled on
> el9).
> 
> https://github.com/flowerysong/OpenARC
> 
> This is relevant for a stack like SpamAssassin, Opendkim, Opendmarc,
> -->OpenARC
> 
> work with Postfix.
> 
> If you run a rspamd mail stack then that seems better, as it does all
> already.
> 
> Explanation:
> 
> The problem OpenARC solves:
> 
> Email has security checks:
> 
> SPF: “Is this server allowed to send for this domain?”
> 
> DKIM: “Was this email changed after it was sent?”
> 
> DMARC: “If those fail, should I reject it?”
> 
> Now the problem:
> 
> Mailing lists, forwarders, and gateways often change emails
> (add footers, rewrite headers, re-send from another server)
> 
> That breaks DKIM/SPF → DMARC fails → legit mail gets rejected
> 
> What ARC is (one sentence)
> 
> ARC is a way for mail servers to say:
> “Hey, I checked this email earlier and it was legit when I saw it.”
> 
> What OpenARC does
> 
> OpenARC is the software that implements ARC.
> 
> It lets a mail server:
> 
> Record authentication results
> (“SPF passed, DKIM passed, DMARC passed at my hop”)
> 
> Cryptographically sign that record
> So it can’t be faked later
> 
> Pass that record along
> So the next server can decide whether to trust it
> 
> Think of it like a tamper-proof receipt trail for an email.
> 
> Luca
> _______________________________________________
> users mailing list
> users at lists.ghettoforge.net
> http://lists.ghettoforge.net/mailman/listinfo/users