Rspamd 2.0 Released For Advancing Free Software Spam Filtering

[phoronix]

Phoronix: Rspamd 2.0 Released For Advancing Free Software Spam Filtering

Rspamd 2.0 has been released as the newest version of this leading open-source spam filtering software and it's coming with plenty of changes...

http://www.phoronix.com/scan.php?page=news_item&px=Rspamd-2.0-Released

[tildearrow]

Rspamd 2.0 drops its external libevent usage to its own bundled libev implementation,

Good to hear. libevent has an unstable API.

[elatllat]

But how does it compare to the false classification rate of gmail? Can't we just ban all email not using OpenPGP/DKIM/DNSSEC/SPF/etc like how google forced https on everyone by down ranking http only sites.

[timofonic]

KANN library has been last updated over 9 months ago. In the days of GPUs, FPGA and custom silicon for neural networks, this library is CPU-only and I wonder why. Are they sure this is a good replacement? Are they forking KANN and make it use non-CPU hardware too? They already did minor changes in June and July, as you can see here.

Why not TensorFlow? It can use the GPU, for example.

[ssokolow]

But how does it compare to the false classification rate of gmail? Can't we just ban all email not using OpenPGP/DKIM/DNSSEC/SPF/etc like how google forced https on everyone by down ranking http only sites.

I've been meaning to set up something a little more elegant for years but I'm still having trouble finding the time:

1. Give every sender their own e-mail alias to send to. Treat them as revokable API keys. (This part, I already do using SpamGourmet and/or manually managed aliases on ssokolow.com)
2. Use a custom milter to bounce messages where the sender on the incoming message doesn't match the sender the e-mail address was given to.
3. In the bounce message, include instructions for requesting that your anomalous message get let through anyway. (ie. a CAPTCHA.)
4. Require unsolicited messages from strangers to be submitted through an HTML form that does some more traditional spam checks. (At the moment, I'm doing fine just forbidding things like HTML/bbcode link tags, the same URL appearing more than once, and e-mail addresses outside the "your e-mail address" field. If someone needs to tell me someone else's e-mail address, they can wait for me to reply and then send it in their second message, which will be a normal e-mail reply.)
5. Use the custom milter to rewrite outgoing messages so that the mail client doesn't need to be aware of the fancy system and sending someone an e-mail will automatically establish a From address for them to reply to.
6. Write a simple browser extension to add a "Create e-mail address" entry to the context menu for HTML form fields, which also establishes the new alias in a special mode which will cause it to lock its allowed sender to whichever domain it receives the first e-mail from.
7. As a last resort, have a GMail-esque self-expiring spam bin for each alias that can be browsed for situations such as "site sends e-mail verification e-mails and other communications from different domains."

SPF to ensure sender domains are reliable plus this kind of "whitelist system with a viable UX" approach is my "What now?" answer to the arms race that has developed around Bayesian classification since Paul Graham championed it over hand-written rules in the early 2000s.