We are trying to implement an "attchment filter" rule for ALL incoming emails using existing spamfilter.

What i like to request is a mechanisim to exclude whiteListed users from attachment-filter. in other words... we want spamfilter to enfore attachment filter even for whitelisted-email-addresses.

Is there away we can achive this in current release? or could this be implemented in future release.

You all see how easy it is to spoof a "From" address these days...most viruses do it be default.... and let's say a company has a network wide attchment filter policy.. is itn't it logical to expect that policy apply to all incoming emails regardless???

in currentl spamfilter code...white-listed users cause a leak and viruses do abuse that behaviour and you can figure the rest...

AL

As I see it, the problem with a bypass of the rules is that the rules work best for me when the users don't have to invovle me in the process.  They can white list people in the web interface and then from that point on the emails flow freely to them from the address.

But let us pause to consider why we have spam filters in the first place.  The answer is simple.  We do not trust our using to employ sufficient disgression when in comes to whether or not they show open this email attachment from Sexy-Sue.  So now we are back to how do we control this. 

Well the answer is that the spam filter is intended not as antivirus, but anti-spam.  Our anti virus solution is the best control for viruses. 

Now how can we stop both?  I have a firwall as a first line of defence.  I have blocked most ports on it and have it acting as my "1st" spam filter.  (ie no .zip,.exe.scr etc) can get through it.  Everything else is automatically forwarded to my spam filter server which refines things further.

Another thought I hade was is this is an issue to you, consider having 2 spamfilter servers.  The first could block all bad attachments, but let everything else thourgh.  The second would allow your users to access thier Spam filter boxes.  The only problem I see with this is that if an Email comes in, and passes the first server, but is rejected by the second, does the rejection notice go al the way back to the originator, or would it only go as far as the first spam filter.  Roberto, maybe you can answer this???

John,

Thank you for your thoughts. well. i imaginr, a whitelist could be an entire domain or IP of sender's MX host for that matter... so it is very plausible and easy for virus or spammer to gain privileges by way of a whitelisted creteria.

Say you have a peer organization that fails rdns test or say uses vrison or Shaw internet as ISP and MAPS test is positive and you whitelist sender's domain or IP as last resort. Then you have no spam protection from that source.

My request is allowing a flag in ini file so that regardless of whitelisted criteria, still run filter-attachment as last test... just before delivering email item to mail server.

I didn’t ask for a whitelist for existing whitelist. that would be complex. As a side note. whitelist for a whitelist would be a blacklist??

just having a way to execute an attachment filter for all incoming email. Obviously If email doesn’t have an attachment that filter is not executed anyways so no performance penalty there.

other point is ....Antivirus software does not save you from zero hour or zero day viruses for that matter. Many would recall scenarios from past...One would be asking for it, if one relies simply on antivirus.

When a company has an attachment policy, then company usually doesn't want to allow users to by-pass that rule using say the web interface (even inadvertently). That is not good at all even if we say it's best for user to decide.

Running two spam filters in series makes for unnecessary complexity that I like to avoid. That’s why I requested this feature. Running two spamfilter reduces reliability by half because now you have two things that can break because fail probability increases twice. please do comment it's good to explore that way.

First of all I agree that Antivirus cannot be your only defense against viruses.  Obviosly it can only protect against Known threats and not un known ones.

Secondly I also agree that a file Attachment filter has more to do with security than a way of detecting spam, hence my current fire wall solution. 

Thirdly,  I also agree that adding another spam filter server would create more Maintenance, More Complexity and more potential for failure.

That all said, it still leaves us with the problem of the attachments issue.  Having read your post I am reminded of why I went with the fire wall solution in the first place. 

The Flip side is also true, Having a customizable way of setting certain Whitelisted items override thye blacklist or vise versa can lead to an extremely complicated setup often resulting in holes being created simply because it is impossible to visualize the way things could get through.

Let's keep this discussion going because it will help us find better solutions.

Thanks for your comments... Here is another suggestion or cleaner approach.

Instead of messing around with existing Whitelist/blacklist mechanism, why not have a separate filter (same why as antivirus or SPF) with its own configuration tab.  This new filter would be a global file attachment filter. It will not interact with whitelist/black lists. It executes as last filter before delivering email, and it will have its own configuration text file, which would hold list of files or file extensions that are globally blocked.

If an admin person doesn't activate this filter, then spamfilter remains backward compatible to all earlier versions. If activated, then spamfilter can protect against unknown viruses that exploit ZIP, pif, file types etc...

AL

Most mail servers have their own internal attachment filtering don't they?  Ours does and we definetly use it along with spamfilter.  I've never actually had a need to use spamfilter for attachment filtering as viruses don't always come from the outside.  Some of our clients have sub-contractors coming onto their network with their personal hardware and thus opening a Pandora's box for potential internal threats.

Our solution:  Don't trust anything from anybody.  Our email server uses a custom port for SMTP traffic and we require all of our users to set their SMTP port to our custom port on their mail clients.  Attempting to send anything via the default port 25 hits our spam filter which will reject anything that claims to be coming from one of our hosted domains.  Every once in a while we get a new user that is kind of puzzled over the fact that everything they try to send out gets rejected until we point them to our FAQ for setting up their email client.

Our email server also filters all attachments and rejects anything that is executable...coming or going no matter what the source appears to be or what port it came across.  So anything hitting our MX record from the outside gets filtered as well as anything hitting us internally.

Hope this gives you some ideas on additional methods for defending against the unknown.