continued spam leakage

[Ethan Blanton]

Luke Schierer spake unto us the following wisdom:
> Sorry about the delay here.  We moved on the 1st, and have not yet
> really settled in.  

No problem; hope the move went well!

> Anyway, I have rock sending its mail through amavisd-new (this appears
> to have been partially configured but disabled), and amavis sending
> mail through both clamav and spamassassin.
>
> It puts the "bad" emails in /var/lib/amavis/virusmails which is less
> than useful (I would prefer it create some sort of mail box file or
> maildir directory but whatever.  

So, it's ultimately helpful to run spamprobe and then a rule-based
filter, and if spamprobe didn't mark but the rule-based filter did,
feed the mail back through spamprobe to retrain.  This isn't critical
(anything is better than what we've been having!), but it would be
nice to have it in the ultimate configuration.

> The configuration for this is a little awkward.
> 
> spamassassin's configuration file configures how spamassassin checks
> things. but amavis' configuration files determine whether or not the
> score is sufficient to mark the mail as spam, and if so, if it is
> sufficient to just mark the mail, or also block the sending. 
> 
> This will doubtless need some tweaking.  I have not done this
> configuration on the pubic internet where you get the volume of spam
> (and unique kinds of non-spam) we do in 5 years or so.  
> 
> I will try to be available to help with this tweaking.  

Great.  Hopefully we can get this knocked back down to pre-upgrade
levels, where we leaked only a few mails a month.  That level of
leakage is justified for having open lists, I think, but this recent
behavior is not.

Thanks,
Ethan