rspamd package has redis as recommended, not required. (for basic functionality).
but for some modules (extra functionality) to work, you need redis (or the foss valkey fork).
if virtualmin was to replace amavis/sa stack → rspamd, redis/valkey would be needed.
2c.
Virtualmin does not use Amavis.
The fork works nicely just like the native repo one. But now I found this:
IETF calls for end of ARC experiment: What it means for email authentication
interesting considering google picked it up not too long ago:
lol. See, this is why we don’t rush into things WRT email.
I guess so, but I still believe Virtualmin should at least perform DMARC checks with OpenDMARC or another solution, instead of just having a DNS entry telling others how to deal with us.
We should also enforce policies for senders.
Only been going for ten years, still early days 
Update the whole email stack and make virtualmin a leader for email provision.
Obviously keep postfix but give the GUI some TLC.
you’re right of course, just got confused 
have also migrated other non-virtualmin systems to rspamd, and amavis+sa was the most common setup there.
best,
We’ll be updating the email stack during the Virtualmin 8 dev cycle. It’s tricky to make changes to the email stack, as it’s so complicated, and active users will have custom procmail rules and such, and procmail goes away in any mail stack overhaul (replaced by Sieve). It’s plausible we’ll switch off of Dovecot, as well, as Cyrus supports JMAP, while Dovecot doesn’t, and it might be nice to have that for an overhaul of Usermin.
Anyway, it’s very likely we’ll have a new mail stack in time for Virtualmin 9 in early 2027, and folks can probably try it as we develop it, though I wouldn’t recommend a switch on production systems until it’s stable. Again, very complicated, lots of moving parts and dependencies.