My current position is that spam filtering is a whole another problem space so I am not trying to address it now while Maddy is a "single man show".

P.S. As far as I am aware, redis is optional for rspamd. I certainly run it for @hexanet.dev email without having redis installed.

Look into doing greylisting. I do that for my own setup, and I've found it easily cuts down on the spam by at least 50% and that's without even looking at the email.

I’ve used greylisting for the last five years or so. I stopped doing so completely and moved to Fastmail. Greylisting delays, while unnoticeable with the contacts I frequently communicate with, were very annoying with new and one-off contacts, especially all sorts of confirmation emails from bank etc, which would often expire before greylisting allowed them in. Sometimes, emails were sent through cloud mailing systems, so coming from a different host each time they’d hit greylisting again and again and again.

Rspamd falls back to sqlite if you do not have Redis configured

There we go, humanity survived for another insert description of time interval

This is actually how usual Postfix+Dovecot setup works in practice. Dovecot runs an LMTP server which is SMTP with some minor modificaitons. Postfix forwards messages to Dovecot's LMTP.

I believe a server wriiten in a memory safe language greatly reduces the risk of running such setup. To the point where it is an acceptable trade-off to get simpler maintenance.

Depending on how many targeted attacks you get in a day, you may pull apart the monlithic server and run inbound processing, filtering, IMAP access and outbound queueing as separate processes or even on separate systems.

(Probably i should put a better wording on https://foxcpp.dev/maddy/faq/)

Thanks for the tip.

> you may pull apart the monlithic server and run inbound processing, filtering, IMAP access and outbound queueing as separate processes or even on separate systems.

Can this be done without forking source code? E.g. just configuring two instances.

Thanks for the link to FAQ. Actually, simple, no bloat’ little dependency software definitely has some appeal.

Yes, this is possible.

This page shows how to configure maddy to only handle SMTP: https://foxcpp.dev/maddy/tutorials/smtp-only/ You can follow it but swap Dovecot for another maddy instance, configured as shown here: https://foxcpp.dev/maddy/tutorials/imap-only/

This works because maddy implements both client and server for Dovecot's SASL delegation protocol.

Alternatively you can configure pass_table to read from shared SQL database. Hm, maddy-tables(5) man page is not rendered on the website but you can look at sql_query module.

You sir, created in me hope for mail server in Rust. But this is just a Go Lang

If I had an infinite amount if time, I would sure write maddy in Rust. But as practice shows, there are only around 24 hours in a day.

That being said, my project greatly benefits from Go concurrency features and simple I/O primitives. Also there are libraries written by emersion for nearly everything.

Oh when will this Rust hype end, November needs to come already.

Your suggestion is to tie everything to the ownership of alternative root KSK. Meaning that you are explicitly blocking the possibility of multiple CAs for the project.

>if you trust a third party CA they can just sign for anybody without limits

It is possible for a root certificate to have a name constraint making all certificates issued for other e.g. TLDs invalid. Like it is done in dn42 CA.

Yes, that's the nicer solution, and it seems Apple finally got around to adding support for it as well a while back - for a long time they didn't support it, so name constraints broke validation for Safari and Chrome on macOS.

Developer here to answer any questions. Also see https://github.com/foxcpp/maddy/wiki/FAQ.

FAQ says "Implement a meaningful subset of IMAP for access to local storage."

What subset do you implement? Thanks.

Currently it is base IMAP4rev1 specification (RFC 3501) minus /Recent flag plus SASL-IR, APPENDLIMIT, MOVE, CHILDREN, SPECIAL-USE, COMPRESS, UNSELECT and IDLE extensions. Support for CONDSTORE and UIDPLUS extensions is planned.