If mfilter system is changed, might aswell use one that does it all.
In response to Joeās comment āā¦that a bunch of major mail providers are using it. I donāt think Iāve seen evidence of that.ā I would like to offer this advice from Googleās Gmail section titled:
āEmail sender guidelines => ARCā
āWe recommend that senders use ARC authentication, especially if they regularly forward email.ā
Also from search:
Q: Does outlook.com use ARC for email?
A: Yes, Outlook.com uses ARC (Authenticated Received Chain) for email authentication. Outlook.com, like other major email providers, is actively adopting and enforcing ARC to enhance email security and ensure the integrity of received messages.
Q: Does Cloudflare use ARC for email?
A: Yes, Cloudflareās Email Routing service supports Authenticated Received Chain (ARC).
Positive results are also found for Yahoo Mail, ProtonMail, Mail.com, Apple Mail/iCloud Mail and in the hosting panel space, Plesk (Linux only) and cPanel (experimental) since version 122.
I agree with āShouldersā that it would be good to have a single, well-maintained milter that does everything, especially as it comes from a vendor specialising in email. Only Jamie, Joe and Ilia can comment on how hard or easy it would be to implement.
2 Likes
Hi all, sorry-- Real Life has been a bit 'whelming for a while.
If I may, Iād like to chime in with a few simple insights ā hopefully helpful ā into DMARC, ARC, etc.
How is ARC helpful?
The primary purpose from where I sit is NOT getting the receiving server to trust forwarded emails. Not quite.
- Primarily it allows my server to forward directly to Google etc, and (correctly) say āI am certifying this email did NOT originate with me. Here are the headers as I received them.ā
- Result: my server is not blamed if spam gets forwarded to Google.
- This really doesnāt require that Google trusts my server very much.
Note that the above is NOT me certifying the email is good, at all!
Note too: it still helps a lot if Iām able to discard most spam. Even with ARC implemented, Google tends to get upset if too much spam is forwarded to gmail accounts 
How is DMARC helpful?
DMARC empowers savvy email servers to reject massive amounts of spam.
Hereās the setup for a real world example.
I (accidentally) created one of the oldest domain names in the world (octopus.com) ā sold that one, but still own a verry old domain with interesting properties:
- ds.org is only used by us for infrastructure.
- That domain is never the named source or recipient of valid email. (ie never from/to who@ds.org etc.) Yes, required exceptions ok, eg postmaster and root.
- Our servers typically are in that domain. aster.ds.org is our (Virtualmin) email server.
A brief history:
- For decades, our emails blissfully were sent and received. No visible issues.
- Spam became a Thing. We implemented spf, then dkim. Incoming spam reduced.
- Then our email server began to be blocked, marked by some major providers as a spam source??!!?? Impossible, I thought! We hardly send any email at all! And we never send any email as ds.org! Our email server, aster.ds.org was being blamed anyway.
- So, we implemented DMARC, including basic reporting. (At the time, dmarcian.com was free for small users. Iād love to have basic DMARC reporting inside Virtualmin at some point. AFAIK there are some pretty good open source solutions. I just donāt have time to investigate right now.)
Suddenly, everything became clear:
- Due to DMARC reporting, a variety of email servers around the world started giving us data on emails they were rejecting, attributed to our ds.org domain.
- Turns out, spammers in eastern Europe and Asia (mostly mainland China) were sending 1-2000 spams a day faking our domain name. Or subdomains: somebody@subdomain.ds.org
- With DMARC instructions in place (āplease reject and report all such emailsā), our domain name again became āclean.ā Whew!
- Importantly, unlike SPF, DMARC allows control over ALL subdomains, without specifying any particular subdomain. Thatās crucial, since of course itās impossible to define all possible subdomains.
BTW, thanks for the pointer to the FastMail implementation. Iām running OpenARC, which is not exactly robust.
2 Likes
Google seems clear about the future: SRS is not mentioned, ARC is required.
And since gmail is end-of-life-ing POP3 support NOW (medio 2026M01) for fetching email from external email servers, many that use gmail will need to switch from POP3 fetching to forwarding. SPF/DKIM are of course key, but servers most will already have that set up (as Virtualmin has been facilitating that for a while now). ARC is not yet facilitated but is part of Googleās list.
And, frankly, SRS will never be part of the Googleās recommendations, as it is a āhackā and does not fully solve the problem (only ARC does that). Even though they will process SRS info (for now), so SRS is still a very necessary thing at this moment, as it will ensure the forward works without ARC (as without SRS, the SPF check will fail, and mail will likely not be accepted from servers with a low mail volume).
In short: SRS is highly recommended (if not required) for Virtualmin users to set up themselves (so maybe we need an āofficialā manual for it), until Virtualmin starts supporting it natively. Setting up ARC yourself is possible, but not easy and will likely require rework when Virtualmin will officially support it (which, imho, is very urgent).
PS: The reason SRS is needed is that ARC only works if there is trust; lacking that trust, the receiving server will āfall backā to SRS to not fail on SPF.
2 Likes
This is what would prevent dmarc failures for mailing lists right?
apart from ARC/SRS I still believe Virtualmin does not perform inbound DMARC checks.
Opendmarc is not installed and SpamAssasin is doing spf and dkim but not combining for dmarc.
I think it could be implemented, I have it running, part of most distros to have opendmarc in repo.
So the DNS records is there to tell others how to treat your mail, but you should still check the incoming mail to honor the same compliance.
the same is true for virtualmin MTA-STS it does not actually check the policy.
(although we can let that slide, it would require very recent postfix and also postfix-tlspol)
But dmarc should be checked properly.
I think with all of these new technologies that the email stack should be revisited. The current one does have some issues and the GUI needs some improvements (yep, I have submitted a load on GitHub)
It has been mentioned in the past they might do it for VM8 but I donāt think that happend (not looked though).
ARC, MTA-STS, DMARC, SPF, DKIM, BIMI, SRS, GreyListing, SpamAssassain and I am sure there are some more.
2 Likes
Also there is no āreportingā in Virtualmins dmaRc.
together with opendmarc I use:
GitHub - oh2fih/OpenDMARC-Reports: Automate OpenDMARC reports securely.
DMARC reports would be an excellent Pro feature. You can define where to send the information I believe.
the DNS entry with email is for someone else sending a report about your servers dmarc
what we miss is us checking their email and sending them the report report about their server.
we are not following the spec, it is incomplete.
any chance you can fire up a GitHub issue with everything outlined including adding a GUI for reading local DMARc information and reports?
maybe a big task for virtualmin, but migrating to rspamd can provide all those features and various daemons/configurations, in just one package = rspamd using included plugins.
so, no opendmarc, opendkim, postfix-policyd, opensrs/openarc, postgrey, spamassassinā¦
imho, rspamd is much faster, lighter in resources, and easier to manage than spamassassin.
(have already migrated virtualmin-gpl hosts to rspamd, running fine for the past couple of years or so. ).
2c.
2 Likes
Iāve looked into rspamd in the past, and was put off by lack of a package in the repos for EL. But, packaging something isnāt necessarily a disqualifying requirement (we package jailkit, for instance).
I would like a lighter-weight mail stack, but SpamAssassin really isnāt that big of a resource consumer relative to the rest of the mail stack. Itās written in Perl, so itās got some overhead that rspamd doesnāt necessarily have, but itās still pretty light and quick. Iāve never used rspamd, so I donāt have any hard data about what resources it uses, but ClamAV is proof you can write huge, resource-intensive, software in C.
Iāll try switching one of my mail servers over to rspamd sometime soon and see what it looks like versus the current stack.
3 Likes
you can try official package : Downloads | Rspamd Documentation
for Debian family (+Ubuntu) : Downloads | Rspamd Documentation
you also need redis (or the valkey fork).
btw, my first tests were about manually training from a spam database.. (got a few k spam emails for training..). spamassassin (sa-learn) ran for a few minutes, while rspamd (rspamc learn_spam) took seconds to scan the same volume of spam. canāt recall exactly but the speed difference in spam learning was pretty obvious.
and the big plus for me was not having to deal with 6-7 extra daemons necessary for the modern SA/amavis setup stack.
best 
I definitely rspamd is worth looking into, thanks Joe
1 Like
If itās not in the OS standard repos (or EPEL or Code Ready on EL, something maintained upstream), we have to build it ourselves, as weād need to put it in our repos, and Iām not signing anything Iām not involved directly in building and vetting.
2 Likes
I think it works.
dnf install openarc
mkdir /var/spool/postfix/openarc
chown openarc:openarc /var/spool/postfix/openarc
usermod -a -G openarc postfix
nano /usr/lib/systemd/system/openarc.service
Comment out protections and change umask:
UMask=0002
#ProtectSystem=strict
#ProtectHome=true
apply:
systemctl daemon-reload
Copy DKIM key to ARC:
/etc/opendkim/keys/default.private
to
/etc/openarc/keys/default.private
Also copy
/etc/opendkim/TrustedHosts
to
/etc/openarc/
nano /etc/openarc.conf
Syslog yes
UserID openarc:openarc
Socket local:/var/spool/postfix/openarc/openarc.sock
SignHeaders to,subject,message-id,date,from,mime-version,dkim-signature
PeerList /etc/openarc/PeerList
MilterDebug 2
EnableCoredumps no
InternalHosts /etc/openarc/TrustedHosts
FinalReceiver yes
Mode sv
Canonicalization relaxed/relaxed
Domain yourvirtualmindomain.tld
Selector default
KeyFile /etc/openarc/keys/default.private
Add to postfix config:
smtpd_milters = inet:localhost:8891,local:/run/milter-greylist/milter-greylist.sock,local:openarc/openarc.sock,local:opendmarc/opendmarc.sock
non_smtpd_milters = inet:localhost:8891,local:/run/milter-greylist/milter-greylist.sock,local:openarc/openarc.sock,local:opendmarc/opendmarc.sock
In this example we add: local:openarc/openarc.sock (we donāt add the full path here because it is running in the /var/spool/postfix directory
Virtualmin has opendkim on port. Thats ok. This example is with opendmarc and openarc running as socket.
Next:
systemctl enable openarc
systemctl restart postfix
systemctl start openarc
Check it
systemctl status openarc
or
journalctl -xeu openarc.service
Check some headers:
ARC-Seal: i=2; a=rsa-sha256; t=1769863710; cv=pass; ā¦
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; ā¦
ARC-Authentication-Results: i=2; mx.google.com;
dkim=pass header.i=@vom-bruch.com header.s=default header.b=S95YoHA4;
arc=pass (i=1);
spf=pass (google.com: domain of luca@vom-bruch.com designates 2XX.2XX.2X8.23 as permitted sender) smtp.mailfrom=luca@vom-bruch.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=vom-bruch.com
Authentication-Results: home.vom-bruch.com; arc=pass smtp.remote-ip=2607:f8b0:4864:20::1130
maybe it is also necessary to add:
FinalReceiver yes
to the openarc.conf config.
## FinalReceiver { yes | no }
## default "no"
##
## If set, causes this filter to pass chain signatory information downstream for
## local policy evaluation in the event of an authentication failure.
Iād recommend against using OpenARC, since it has been unmaintained for many years. There are alternatives that are maintained.
Ok but the current stack includes some of the features for modern email security.
If you were to change it, I think it would make more sense to switch as many features as possible to the new implementation.
rspamd for example. It can do almost all of it. DKIM DMARC SPF Spamā¦ So for me the addon was openarc since all other areas were already covered.
But need to consider that it also wants redis, which will be a requirement for some other things users might run. - No experience with multi instances of that.
Is redis mandatory or recommended?
not sure about the fastmail implementation with redis
Anyway opendkim is also not maintained and virtualmin uses it.
maybe it would be worth it look into rspamd
Anyway maybe it is better to install the fork. I will have a look at it. It has been maintained: