On Wed, May 24, 2006 at 01:48:25AM +0200, Mark Martinec wrote:
> Rob,
>
> Your request makes sense, sounds like a reasonable feature request,
> if it turns out that a simple modification to @av_scanners wouldn't
> suffice.
>
Cool, thanks.
> > ['ClamAV-clamd',
> > \&ask_daemon, ["CONTSCAN {}\n", "/var/run/clamav/clamd"],
> > qr/(\bOK|\.Phishing\.\S+ FOUND)$/, qr/(?!\.Phishing\.)(.*) FOUND$/,
> > qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],
>
> Seems like a good approach. You should test it, but looks alright.
Thanks.
> Btw, have you tried asking ClamAV folks to make an option to ignore
> phishing test, or if it is possible to just remove them from a database?
>
As Noel mentioned, the upcoming 0.9x release of ClamAV will have a
"--no-phishing" option, but that is just one special case and just one of
our scanners. As I said, IMO decisions based on virus name properly belong
in amavisd.
> As far as I understand it, you don't need a policy bank, just
> replace a global setting in @av_scanners.
But I don't want it to be global. Just some patterns for some users.
For just the case of phishing, it might make more sense for the handful of
users who want them to pass through 'clamscan --no-phishing' in a policy
bank rather than messing with the clamd entry. Better would be something
like:
@virus_name_by_recipient_maps = ({ # a by-recipient hash lookup table,
## per-recipient personal tables
'[EMAIL PROTECTED]' => [{qr'Phishing' => 0, # ClamAV
qr'Phish-BankFraud' => 0}], # uvscan
'[EMAIL PROTECTED]' => [{qr'Joke' => 0}], # gets the joke
## site-wide settings for virus names ('.' matches any name)
'.' => [{ # a hash-type lookup table
'.' => 1, #everything else is a virus if the scanner says so
}],
);
Or maybe that would be better inside-out: for a virus name pattern, look
up recipient addresses with 1/0 values.
@virus_name_by_recipient_maps = ({
qr'Phishing' => [{ # ClamAV's name
'[EMAIL PROTECTED]' => 0,
'[EMAIL PROTECTED]' => 0,
'.' => 1,}],
qr'Phish-BankFraud' => [{ # uvscan
'[EMAIL PROTECTED]' => 0,
'.' => 1}],
qr'Joke' => 0, #our users get the joke
qr'EICAR' => 0, # we want to mark but pass this.
qr'.' => 1, #everything else really is a virus
});
> > Am I right in thinking that to use option 1 with Postfix, I'd need proper
> > multi-instance and feed mail to amavisd via transport maps rather than
> > content_filter to correctly handle multi-recipient mail? And would that
> > break XFORWARD (TFM suggests it won't)?
>
> Even if you use policy banks, there is rarely a need to use dual-instance
> setup (one may want it for clarity, but that's up to personal taste).
> Usually just an alternative -o content_filter setting on a specific
> smtpd service suffices, or a FILTER on a restriction, or just the fact that
> a client IP address belongs to mynetworks or not. But like said, you don't
> need policy banks for your goal, unless you want to treat e.g. outgoing mail
> differently.
So, restated as a per-user policy, the question stands :-). I was leaning
towards multi-instance as a cleaner option anyway, and I think per-user
transports into amavisd is probably the way to go.
cheers
rob
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
