[Mimedefang] Which first: stream_by_x or virus checks?

Jan-Pieter Cornet johnpc at xs4all.nl
Thu Oct 18 04:51:01 EDT 2007


On Wed, Oct 17, 2007 at 05:01:03PM -0700, Kelson wrote:
> 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.

This is backscatter, and because it's mainly due to spam, that is
Very Bad.
 
> 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 

Eh, why? You could simply not scan anything originating from localhost,
which means anything re-injected with stream_by_recipient is not scanned
again. If you don't have anything else generated on localhost (and if
it is a dedicated mail server, I don't see why it should), this is fine.

Hm, you only need a way to pass the scanning result to the re-streamed
message. The only way to do that currently is to modify INPUTMSG and
add a custom header, or patch/copy the stream_by_recipient function.

I'd seriously consider this, as ClamAV is extremely CPU hungry, and
calling it N times on a message instead of once, will be killing for
your mail server if the load increases.

> 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?

In your case, since most recipients have the same filteing, I'd not
use stream_by_recipient at all, and then "manually" generate bounce
messages if it's absolutely necessary (ie: if one recipients wants to
accept the message, but another user wants to reject). And even then,
in case it's spam or a virus, it might be better to discard.

Also, you could add logic in filter_recipient that would tempfail
recipients with conflicting filtering requirements (with a "too many
recipients" error). If necessary only from untrusted sources (such as
those appearing on DNS blacklists, for example).

-- 
Jan-Pieter Cornet <johnpc at xs4all.nl>
!! Disclamer: The addressee of this email is not the intended recipient. !!
!! This is only a test of the echelon and data retention systems. Please !!
!! archive this message indefinitely to allow verification of the logs.  !!



More information about the MIMEDefang mailing list