Should rspamd integrate with third-party anti-spam systems?

[bobobo1618]

I'm currently running Postfix etc. with rspamd.

Is the anti-spam capability within mox already on par with third-party systems like rspamd or would mox benefit from integration? Is that something that's likely to happen or something that would be accepted in a PR?

[mjl-]

I haven't had a need for additional/external spam filtering. My previous setup was postfix with some strict settings and a DNSBL, but without additional spam filtering. So switching to mox was a big improvement for me. Now typically a handful spam messages get through per week, which I'm happy to mark as junk (training the filters). I did import all my spam/ham messages from my previous setup, so I did start with helpful history (though newly delivered messages are more helpful because mox can use their dmarc/dkim/spf-based signals when classifying, those cannot typically be imported).

I had a quick look at the rspamd website again (I never used it). It certainly supports more mechanisms than mox, so an integration could be useful.

I think an integration would best be done through support for milters. Other filters would benefit as well. I suspect mox will need milter support sooner or later. But it could be an impactful change to the smtpserver: I think it involves maintaining connections to milters, executing the protocol, checking for timeouts, handling their instructions, handling errors, etc. Though it's not clear to me exactly how milters work: I did a quick search and couldn't immediately find an clear/authoritative description of the protocol.

Mechanisms mox implements to prevent spam from arriving in your mailbox, while allowing legitimate messages in:

• SMTP/connection/message checks, such as valid reverse DNS for connecting IP, SPF/DKIM/DMARC
• Reputation checks based on junk/non-junk classifications you made (they are per account): IP-based (exact IP, small subnet, larger subnet), based on dmarc-like verified "message From domain" or "message From organizational domain" (e.g. sub.example.com and example.com), based on dkim/spf verified domains (e.g. some mailer service or mailing list; a message can have multiple verified dkim domains), content-based with a bayesian classifier.
• Incoming messages from addresses or domains of addresses you have sent messages to in the past are let in. Helps with first-time repliers.
• Delaying first-time senders (a lighter variant of greylisting).
• Rate limiting of incoming messages.
• DNS blocklist, as a last resort, if there isn't enough reputation signal yet (first-time senders).

If mox accepts a message, it will be delivered as non-spam message. If a message is classified as spam, it is rejected. So senders don't need to get email-sender-anxiety when sending to mox. As a mox user you can see rejected messages in the special Rejects mailbox, so you don't have to get email-receiver-anxiety. By moving a rejected message out of the rejects mailbox its will give off positive non-spam signals during future deliveries by that sender, so future messages will be accepted.

I can think of some additional checks people may want to do on their messages that mox doesn't support (and I don't think I need personally):

• check with an URL blocklist (this would be for first-time senders only, to limit leaking info, and to prevent dependency on centralized services).
• antivirus (I suspect larger companies would want this)
• custom matching rules, e.g. forbidden strings in headers/messages/senders (perhaps support for Sieve could take care of this)
• country/asn/geoip-based rules

A few of the above should be easy to implement (URL blocklists, custom matching rules, perhaps country/asn/geoip-based tools as well). Checks that are generally applicable/helpful and don't require integration with additional tools should probably be build into mox directly. One of the goals of mox is to make it very easy and low-maintenance to run a mail server. Integrating with additional tools makes setup and maintenance more complicated, so we should only make users do that if really needed.

So far I haven't had any reports about misclassifications, either too many spams let in, or too many legitimate messages rejected. But I would be very interested in hearing about those. In my setup, spam is most often blocked by the "reverse DNS" check (probably spammers using hacked machines to send email) and IP-based reputation check (spammers on a subnet that they keep using and from which I've marked messages as junk), followed by the bayesian content-based filter, and finally a few by the DNS blocklist. I think especially the bayesian content-based filter in mox could use some improvements, making it conclusive more often.

Anyway, I'm curious if there are checks you would like to use that mox doesn't support now. And finally to answer the question: I suspect there will be support sooner or later (assuming milter-based integration), and a PR would certainly be welcome. If you're interested in working on this, I'm available to discuss ideas/approaches/internals/code. (:

[bobobo1618]

My issue is that I have an old gmail address forwarding to my mox server. The gmail account sees a lot of spam and since I don't want Google filtering it (then it wouldn't make it to my server at all), I do it myself.

I've given mox all my old spam to use for classification but I've still got stuff making it through and I prefer my spam filters to be essentially perfect because that's what I've become accustomed to elsewhere, and it makes email notifications valuable.

I really do appreciate the simplicity of using mox though. It being a single Go binary that even comes with most of the necessary config and documentation to get started built-in is pretty awesome and it'd be great if it could stay that way.

Regarding the milter protocol, there's a Go library for it that includes documentation of the protocol here (godoc). I could try to jam it into smtpserver but I'm not great at writing Go (doesn't mean I'm not willing to try, just not that I like my chances of getting a PR accepted :) ).

[mjl-]

I think adding milter support indeed won't be the easiest change to make. The library you referenced looks useful. It also includes txt files with a basic explanation of the milter protocol (I suspect this is all documentation available).
I put "milter support" on the roadmap, but it's near the bottom...