[License-review] New settings for license-review

[Rick Moen]

Quoting Stefano Zacchiroli (zack at opensource.org):

> We do have SPAM filtering before mailman, based on spamassassin. And
> that already filters tons of SPAM. But that's not enough and up to now a
> considerable amount of (volunteer) moderation time was being spent
> clearing periodically the mod-q. I'm convinced, as you are, that better
> spamassassin tuning can improve things, but we've no spare energies to
> implement it.  Instead of keep on spending time babysitting the mod-q we
> went for a different trade-off, which we believe is a better trade-off
> given the current available people power.

I totally understand and am not being critical.

If you-plural ever have the cycles to try it, the Exim4 + Eximconfig
kit really is good, in part because it does _not_ rely primarily on
SpamAssassin (which in its daemonised system-wide form runs as 'spamd').
In the kit, most of the heavy spam-rejection lifting is done by Exim
ACLs, thus relying on very small, fast compiled C code, in contrast to
the commendably flexible but slow and massive spamd (Perl).  Just
counting the ACLs to autoreject arriving spam that grossly violates SMTP
RFCs (the callback verification checks) reduces spam to a trickle.
spamd gets consulted to measure spamicity _before_ the MTA says '250
Accept' (not just merely before Mailman), in line with the aim to do
essentially all testing during SMTP time.

I don't even (yet) use EximConfig's greylisting option[1], but very
little gets through.

I'm sorry to say I'm not personally available to shoulder that task for
you, because I've already gotten so backlogged on volunteer commitments
that my own puppetised rebuild is a couple of years overdue, and I need
to catch up.

Anyway, thank you for your work for OSI and for Debian.

[1] I was being conservative at the time, and was leery of letting my
MTA be dependent on a SQL database being functional.