I posted over two years ago that I thought it was time for Virtualmin to add ARC-signing to emails. Joe found that the Fastmail people had an all-in-one milter on Github that performed ARC as well as DMARC etc., however it couldn’t be used because of a Perl incompatibility in Centos 7.
Since then, I’ve noticed that cPanel added ARC last year, while GMail and Microsoft had already adopted it. I believe the Centos 7 issue may now be less relevant as well. ARC may not be useful to everyone but as it is being used by more and more major players, the absence of it in Virtualmin causes increasing issues for some users.
I’ve even thought of finding someone to hack my system with the Fastmail milter, but then I’d end up with a non-standard system that would break on updates. I’m really hoping that the devs could look at this again, as without it, Virtualmin appears to be more of an outlier in the area of modern email security.
But I am going to tell you why ARC is plain bullshit.
ARC works on trust.
That trust is set by the receiving email server admin.
Example
Server 1 sends an email to Server 4 (you)
On route, Server 2 and Server 3 process the message and are modifying the message somehow, sealing it with ARC after.
Server 4 receives the message, sees the ARC seals, but without configuring ARC to trust those servers/domains, it means exactly didly squat.
If your email server receives email from just 1 or 2 other email servers, I can see this working.
But for a real email server receiving email from all over the world, this is just assine.
Then again, I was wrong in the past, I can be wrong now.
Please change my mind.
It’s not about catching up, many panels out there don’t support ARC.
With this feature I have mentioned it to the team and I will leave it up to them because I am not skilled enough to be able to say one way or the other, however it must exist for a reason like DNSSEC.
DMARC is just another layer of verification. It tells the world what information your domains must provide in order to be accepted; i.e. it gives permission to receiving mail servers to trash mail “from” your domain if it arrives without the specified details matching (e.g. SPF and/or DKIM).
For mail servers that already reject if SPF and DKIM are invalid, it makes no difference. For mail servers that treat missing/incorrect SPF/DKIM as a spammy trait but don’t necessary block, maybe they’ll be less likely to accept that email if it has a DMARC record saying “we will sign our email and it will come from a server listed in our SPF record”.
Adding DMARC can only improve delivery if mail servers are blocking on lack of DMARC even if SPF and DKIM are present and valid. I am unaware of any servers that are blocking based on missing DMARC if SPF and DKIM are present. I would be shocked to find one exists.
I’m not opposed to adding DMARC (including automating/managing it in Virtualmin), but it’s the least impactful item in the list of things you need to do for good email deliverability and it presumes SPF and DKIM exist and are valid if it’s going to help prevent spam. Mostly DMARC helps other mail servers reject spam claiming to be from your domains rather than helping you improve deliverability. Its adoption has been slow, because it’s just not very useful in the grand scheme of things. Nobody should be blocking based on lack of DMARC if SPF and DKIM and everything else is right, because DMARC just says, “I will always use SPF and/or DKIM, and you can reject email that claims to be from my domain if it doesn’t have those.”
The “alignment” feature of DMARC is maybe useful for large organizations with a lot of subdomains without centralized control (e.g. a university or large multinational corporation), in that you wouldn’t want a customer support rep at a remote affiliate office to be able to send a million spams from support@cy.google.com or something just because DNS for that subdomain happened to be delegated to that affiliate office. But, that’s not a concern Virtualmin admins have. We all pretty much manage all of our own DNS and subdomains and such, so we know what SPF and DKIM records we have, and we know where we want mail to come from for our domains.
One of the things DMARC offers is reporting. I am not sure the exact scope of report analytics it proves but there are services out there that will parse the reports for you.
I have mentioned this before, maybe a DMARC reporting section for pro users.
Yeah, I haven’t tried it so I don’t know what the reporting looks like or what useful thing we can do with it. The reports would be about email that fails to verify, which I guess we have a lot of folks who misconfigure things and getting an error sent back about what was wrong might be useful (but you can find out what’s wrong via many mechanisms, you don’t need the receiving server to tell you). Again, it kinda feels like a feature for much bigger organizations than the kind using Virtualmin. If you have a thousand subdomains, maybe you want to know about one of them misbehaving.
It allows remote servers to send information back to your server about spam not just verification issues so you can see if a particular account is spamming out etc..
Obviously DMARC needs to be enabled on the remote server.
I’m pretty sure I set this up because some company made it required. Setting it up isn’t hard. Managing was a pain in the axe to start. I think the initial setup is for ‘do nothing’ as a testing stage. Some places will reject that because they see it as a set and forget.
The reports aren’t human readable. Again, that was painful. But, if the initial setup is correct, you can forget about it. Basically, I think except for the damned ‘tuning features’ for testing, this wasn’t hard. (Not sure why you would tell someone to reject 80% of failures, but oh well… )
@Joe and others…
I started this topic about ARC (“Authenticated Received Chain”) not about DMARC (“(Domain-based Message Authentication, Reporting, and Conformance”), which I am fully aware that Virtualmin already supports.
“ARC” is particularly useful if a user forwards emails from Virtualmin to another MTA, like Gmail etc.. ‘Forwarding’ naturally breaks the ‘trust’ that the originating MTA recognised from the DMARC and SPF records that it checked on receipt of the original email. “ARC” enables the forwarding MTA to add headers saying “This email passed authentication checks when I received it”, so that following MTAs know that it’s good, even though the chain of custody has been broken by the forwarding process.
It’s not uncommon for people to forward one of their business email addresses to a private mailbox, possibly on Gmail, Hotmail etc., but without ARC, this process increasingly fails. Cloudflare, who also support ARC, have a domain email forwarding service that they claim has millions of users, so while it may be uncommon it’s certainly not unknown.
I don’t believe adding “ARC” requires a major rewrite and it could help alleviate issues that some users are experiencing with email. It’s been considered worthwhile by Fastmail, Gmail, Microsoft, Cloudflare, cPanel and others and being as Joe discovered what appears to be a suitable open-source milter from Fastmail, I believe it should be adopted by Virtualmin as well.
Not really, no. DMARC (Domain-based Message Authentication, Reporting & Conformance) isn’t the same as ARC (Authenticated Received Chain).
DMARC protects a domain by making sure emails sent from it are properly authenticated using SPF and DKIM, and it tells receiving servers what to do if those checks fail.
ARC doesn’t protect a domain directly – it helps preserve the results of those checks when emails are forwarded or passed through other systems, so the final receiver can still see the original authentication was good.
DMARC is about setting rules, while ARC is about keeping the proof as emails move along.
Yeah. I tried rejecting on failed SPF and had to stop that pretty quick.
If this is the actual way it works it is pretty much useless and a big spam hole. I trust the content because YOUR server said it was OK? Is this a joke? Seriously. For the protocol to be trusted MY server now needs to check both MTA’s. Period or no sale.
And is it limited to a single forward? Spammers will hop through as many hoops(servers) as needed.
Yes, and this is precisely the problem. New servers don’t have any email history, so services like Google or Proton will probably ignore their ARC headers anyway.
Google only trusts ARC if the sender has a good reputation. Proton Mail is even pickier, only trusting ARC from sources they already consider reputable.
Yet, I’m still not sure how having this as an option in Virtualmin would actually help. @Jamie, what do you think about it?
Though, since EL systems already have the openarc package, technically speaking adding support for it shouldn’t be too hard, from what I can tell. However, Debian and its derivatives don’t seem to have it (openarc package) yet.
