Alessandro Vesely wrote: > mouss wrote: > >> Alessandro Vesely wrote: >> >>> mouss wrote: >>> >>> >>>> 3- never block your own users with methods designed for "inbound" mail. >>>> This includes DNSBLs, spamassassin rules, ... etc. >>>> >>> One exception is when you have methods that can determine that mail >>> is being sent by automated malaware. Viruses, e.g., are dropped from >>> external relays and customers alike. >>> >> well, I really meant "designed for". so this is not an exception, >> because virus filtering is not designed "for inbound" mail. it is >> designed for all mail. I don't mean one should not filter outbound mail. >> but the methods to do so are not the same as those that apply to inbound >> mail. >> > > Anti-virus was an example. Email Service Providers could also use > anti-spam rules to monitor their own subscribers. It's not just software > reuse: not distinguishing between inbound and outbound mail the original > SMTP protocol allows to _design_ filters generically. >
If you try to find a general pattern that blocks all spam but does not block ham, then you'll find it impossible. if instead, you implement specific rules based on the situation, you can do better. mail sent from: - internal networks - generic rDNS hosts - large ISPs - .... - other networks can be checked using different rules. sure, you can use a single filter to do all this, but complexity rarely pays for itself. Instead, divide and conquer. Use the right tool to fight each different enemy. There are also non technical considerations here. I would have no problem rejecting a mail to my boss if the sender is non fqdn. I can however not do so if the mail is coming from an (internal) MUA. In the case of an ISP, legal consideration gets into play. > OTOH, existence of port 587 may indicate there is something wrong with > that approach... It's a divide and conquer thing. why should I design complex things that work in all cases, when I can design small pieces that handle specific problems? forcing users to use 587 with authentication and configuring the MX not to relay can be easily and safely configured. configuring all rules on an MX is error prone, and it takes some effort to make sure it's doing the right thing. > In facts, there are also services designed for monitoring > customers' outbound mail, e.g. some of those provided by ProjectHoneyPot > or CAUCE, that we may consider complementary to DNSBLs, in that sense. > > sure. you can do many things for outbound mail that you cannot do for inbound mail. you can analyze the behaviour of mail (and other traffic) generated by some machine, and this can be used to detect whether it's owned. you cannot do that with external machines, because there are too many zombies out there, and spammers can use one different machine per connection, so no statistical analysis is possible (statistical analysis of content is still possible). some people use no content filter: they only reject mail at smtp time, and they find this sufficient. you cannot do the same for outbound mail. if you do not trust your users, you need to do content analysis. but in most companies, you can just trust your users (except for virus filtering) and only take action if you detect misbehaviour. In short, a reactive approach may be viable in the case of outbound mail, but fails quickly in the case of inbound mail (you can spend days listing zombies, just to get stormed by new ones). I am not saying one should design N different systems. I am just saying that analysis and implementation should not be constrained "arbitrarily". This is no different than writing N different unix programs to do a single task when one could do a lot of things. In theory, all those cp, ls, mv, ln, ... etc could be implemented as a single program (after all, they work on files). would you do that? ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
