It is in Debian ‘experimental’ so it should eventually trickle down.
Yeah, I got misled about what this topic was about by the discussion of DMARC. I’m not great at dealing with a lot of cross-talk (which is why I’m pretty strict about insisting we focus on one topic at a time). Nobody’s good at multitasking, but I’m particularly bad at multitasking.
According to the folks that actually study this kind of thing, it is expensive. Kind of the same thing as doing page swaps in computing terms. Memory, to disk, and back. So take someone with a full time job elsewhere trying to keep track of the forum… 
I was reading what you replied to me about DMARC and was wondering when and why I had a beef with DMARC.
All clear now.
I would like a solution to the issue of forwarded email being classified as spam! Can ARC reliably do that though? I didn’t real this entire thread, so if someone wants to summarize the current state of the art that would be useful for me to decide whether it’s worth adding to Virtualmin.
Just from what someone quoted above, it is a flawed theory IF that summarization was correct. You trust a second server that the first server is OK.
Seems like a kludge to fix something that really should be addressed at the MTA level. I want MY server to check the whole damned chain if necessary to see if ANY server involved is blocked on my end.
You presumably only trust the first server if it provides DKIM and SPF that verifies.
ARC (Authenticated Received Chain) preserves email authentication results like SPF, DKIM, and DMARC as messages pass through intermediaries such as mailing lists or forwarders. This prevents those results from breaking when emails are modified, which is a common cause of delivery issues.
There’s a potential flaw or at least a limitation in ARC’s “chain of trust” model:
ARC relies on the integrity of the chain – each hop that adds an ARC seal is saying: “I trust this message and its authentication results”. Only works if each hop is trustworthy. There’s no global trust system to verify that each ARC-sealing server is actually reputable or secure.
Anyone can add an ARC seal. There’s no built-in way to validate whether that ARC participant is honest or malicious.
If a shady or misconfigured server adds a seal that says “Yep, SPF and DKIM were fine when I got it”, the recipient might accept it – even if the original email was spoofed or altered. This opens the door to potential abuse, especially if email receivers over-trust ARC data without other checks.
Major providers like Google or Microsoft tend to weigh ARC seals only from known or reputable sources, not blindly trust any ARC chain.
1 Like
I think a real non-spam mail server can build up a good reputation over time. Most probably, we should just make it an option—set it up for the user—and let them handle the rest as they go.
Hmmm .. that feels like a big issue. I really like the idea of being able to trust forwarded emails, but without some chain of trust like what DKIM provides via DNS this feature seems low-priority to me.
SRS will stop forwarded email going in spam. It rewrites the sending envelope to match the server forwarding the email.
Arc I think is a reputation thing
ARC works somewhat like DKIM; mail servers can add ARC headers and sign them with a private key, while the public key is published in DNS like selector._arc.example.tld.
However, there is a catch—receiving servers like Google or Proton don’t trust any ARC headers blindly. They only accept them if they come from a domain that already has a good reputation.
So, even though anyone can add ARC headers, they are usually ignored unless the server has a solid track record of sending legitimate emails.
That said, couldn’t we simply configure things for the user if the openarc package is available and ket the user (server) to build its reputation?
I suppose … I’ll put this on my TODO list. Is there a good doc on how to setup openarc integration?
I cannot recommend any, really. However, I assume it’s not much different from a DKIM setup.
Hmmm … maybe I will hold off on this for a while then. Also, according to Authenticated Received Chain - Wikipedia , ARC is still considered “experimental” .
OpenArc Configuration/Setup Tutorials
I will find some more and add them to this post
When I posted about ARC in January 2023, Joe replied that OpenARC is poorly maintained, although there is now a fork of OpenARC at https://github.com/flowerysong/OpenARC
Joe found what appeared to be a superior milter from the Fastmail people, who have been in the email business for over 25 years. https://github.com/fastmail/authentication_milter At the time, Joe thought this would be a better way to go, however it wasn’t supported in Centos 7, although that may no longer be a problem.
I agree that ARC is labelled ‘experimental’ and has been for eight years or more. But the biggest email players and many smaller ones have embraced it, presumably with at least some benefit. Perhaps Webmin/Virtualmin could include it with a switch, so those who so wish can disable it. This would be in keeping with the unparalleled flexibility of Virtualmin.
1 Like
that implies a default everyone gets it even if they don’t want it! Although I have no real opposition to what still seems “of little use” I think it should be made so that those who wish to can enable it
1 Like
This is perhaps where server templates come it.
We definitely don’t wan to waste time on OpenARC. It has now been unmaintained for 7 years, as far as I can tell. (I wish folks would look at stuff like this before suggesting it. Unmaintained software is a terrible thing to add to a server on the Internet, especially in a role that interacts with unauthenticated incoming data from untrusted sources.)
The Fastmail implementation is seemingly maintained, though. But, it also does everything, so we’d probably want to refactor how we currently handle stuff like DKIM/DMARC/SPF, etc. in the interest of not having a half dozen different milters happening when only one can do all the jobs.
I’m ambivalent about the assertion above that a bunch of major mail providers are using it. I don’t think I’ve seen evidence of that. But, it is a real problem…if ARC solves it, that’d be nice.
1 Like