[Mimedefang] Which first: stream_by_x or virus checks?

[Kelson]

Okay, I need a sanity check, here.

We've got a setup where almost everyone has the same filtering 
parameters, but some users have custom thresholds, etc. What we've been 
doing is checking whether the list of recipients includes one of these 
users, and if so, running stream_by_recipient.  This was fairly early in 
filter_begin.

We also run our virus scanning in filter_begin.  Based on the name 
returned by Clamd, we either discard (if it looks like a mass-mailer) or 
reject.  Since adding the SaneSecurity signatures, which uses the Clam 
engine to identify spam, there've been a lot more rejects than there 
used to be.

You can probably see where this is going.

Streaming first, then scanning for viruses, means that a message gets 
resent locally, *then* rejected.  So lost messages pile up in the client 
queue directory, warnings pile up in the logs, and bounce notices get 
generated.

I'm moving the calls to stream_by_recipient *after* the virus scanning 
logic (but still in filter_begin).  The downside is that anything clean 
gets scanned N+1 times instead of N.  It also means that if we ever want 
to enable per-recipient reactions to clamd results, we'll need to move 
it back.  On the plus side, anything that does trigger Clam is only 
scanned once instead of N times, and can be rejected immediately instead 
of clogging the client queue.

Does this seem like a reasonable approach?

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>