Bugzilla – Bug 2316
Whitelist options
Last modified: 2019-08-22 14:27:28 EDT
clamav-milter currently allows for specifying a file of addresses to be whitelisted, but the whitelisting of an address turns off all scanning. Due to the inclusion of spam and phishing signatures, and the use of 3rd party signatures, the whitelist feature needs more flexibility. Certain accounts, like abuse@ or postmaster@, will receive spammy/phishy messages that need to make it through but they should still be protected by virus signatures. Current workarounds include running a second clamd and other glue like Mimedefang or Amavis to route the messages accordingly, which is clearly a waste of memory. Another option is to not reject in-stream and use a scoring system like SpamAssassin to process the results. This defeats the purpose of using milter and consumes extra CPU cycles. In my case, the ability to specify a different action for whitelisted addresses would help. The code for clamscan's --official-db-only option may even do the trick. However, a better solution may be to specify which classes of signatures should be used on whitelisted addresses.
Hi Jason, I understand the general lines and reasons for your request. But could you please try to specify with more detalis what the end result should look like? I.e. in terms of (new) configuration options you would like to see... Don't worry about the implementation details, just look at the whole picture. Thanks
Yes, sorry for being a little vague, I guess I wanted to leave all solutions open. In a perfect world, the various signature types would be numbered, 1: virus 2: malware 3: spam 4: phish etc. and a whitelist entry might look like: To:abuse@example.com 1,2 thus allowing an administrator to specify signature usage for a particular address, rather than skip scanning altogether. I expect that would require significant changes to clamd and the signature databases, though. While it may be useful in other ways, I fully understand it may not happen any time soon. Another option would be to change the action taken on whitelisted addresses. This entry might look like: clamav-milter.conf: OnInfected Reject clamav_whitelist: To:abuse@example.com Quarantine Addresses without an action specified can use the traditional "don't scan" method in order to retain backward compatibility. While not quite as useful, it would at least allow an administrator to review the message rather than have it rejected and deal with an unhappy abuse report submitter. Plus, this may be an easy band-aid until a more elegant solution can be worked into the roadmap.
I can understand a target milestone of "unplanned" for changes to the core clam processes/libraries and defer the load onto whatever glue people choose to use for their application. However, in the case of clamav-milter, the glue is being provided and it really needs a way to deal with this situation. The clam product is clearly designed for use on mail servers and all workarounds for this situation require significant additional local resources. At the very least they require a second clamd running with different options, but they also require replacement glue. I'd rather not see it, but is clamav-milter effectively abandoned?
will it not be solved much more simple if clamav-milter supported policy banks ? eq reject all signatures that are signed and quarantine / deliver if its unofficial sigs if the policy banks support is added it opens more possible to custom what should be done pr sigs
(In reply to Benny Pedersen from comment #4) > will it not be solved much more simple if clamav-milter supported policy > banks ? > > eq reject all signatures that are signed > and quarantine / deliver if its unofficial sigs > > if the policy banks support is added it opens more possible to custom what > should be done pr sigs Wow, Benny, you're still around on this project?!? I agree that is a plausible solution if, after nearly 6 years, this is still an operational issue.
For review in conjunction with other milter efforts (6307, 11285, 11777, ...)
2 last bug is private bugs, so cant comment on them here
Can't see #11285.
(In reply to Ged from comment #8) > Can't see #11285. It's private (I think intentionally so), although I have strong doubts that the issue is security related. Will try review w/ the team.
(In reply to Steven Morgan from comment #6) > For review in conjunction with other milter efforts (6307, 11285, 11777, ...) That last one (11777) must be a typo. bb11777 was spam: https://bugzilla.clamav.net/show_bug.cgi?id=11777