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,

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.

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.