On 02/22/2015 10:08 AM, Simon Hobson wrote:
Recipients may not trust the tags, but it *should* stop outbound spam/infected 
mail should your machine (or one of the clients) get compromised. IMO spam and 
malware is not just something to stop coming in, it's something to porevent 
going out - if more networks prevented it going out then there'd be less of a 
problem.

It's not always black and white. I assume you're responsible for the clients you're talking about, i.e. they are your customers or colleagues. While spoon-feeding colleagues or customers may be okay for the sake of security, my clients would certainly raise hell if they would receive errors due to false positives. Most people expect their system to just work -- no matter what.

By the way: I don't even reject virus/spam mail, I just tag them. If a client is dumb enough to open the attachment of a tagged e-mail, so be it.

On my systems I scan *everything*, and I firewall off everything I can - 
including preventing outbound connections to port 25.

I am not in the situation where all my clients sit in a firewalled private network; it's more the free-mail kind of situation. What and when my clients send e-mail is non of my concern, as long as they do it in common dimensions, i.e. in a way that matches a real person.

At work I run mail servers that are used by customers - including as smart 
relays. It's not all that uncommon to find one of the customer compromised and 
sending out thousands (or millions) of spam emails - so my latest server also 
does rate limiting to limit the damage done before it gets spotted and blocked.

Rate limiting is certainly a good idea to mitigate the damage that's being done by a compromised client. Manual intervention might still be necessary, possibly after automated sanctions (e.g. consistently lowering the rate limit for a misbehaving client). However, rejecting outgoing e-mail right away is not an option, which ultimately makes the scanning of these messages redundant.
_______________________________________________
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Reply via email to