[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