David, you could certainly maintain the benefits of have a first and second level spam-filtering system, but still make it a bit more reliable and accurate buy implementing something like SpamAssassin on your Postfix gateways, since like Declude JunkMail, it also operates on a fully weighted basis.
We actually run two RedHat/Postfix gateways in front of our IMail servers that do both first level spam filtering and virus scanning. We have implemented Amavis-New, and deliver all mail to Amavis via a Postfix content-filter. Amavis then invokes F-Prot and ClamAV to virus scan the messages, then if clean, invokes SpamAssassin, which we have also test the messages against several RBLs/RHSBLs and against pattern-matching databases like Razor2, DCC, and Pyzor. Then based on the total message weight accumulated from all of these tests, a decision is made to either hold the message for possible review, or pass it onto IMail, were we then test with Declude. Since we have SA add a weight header to the message, Declude can track and add this to its overall message weight from it's combined tests (which also includes content and pattern matching filters like Sniffer, Alligate, and SpamChk). With systems and application like these freely available to anyone running a Postfix gateway, I would have to agree with Scott that it seems somewhat irresponsible to ever block mail based on any one single spam criteria. I think if you are going to get into the business of blocking spam, then get into it wholeheartedly and do it right. Otherwise I think you are providing a disservice to your customers and users, and the Internet community in general. Just my two cents... Bill ----- Original Message ----- From: "David Sullivan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, August 16, 2003 9:19 AM Subject: Re[2]: [IMail Forum] Anyone have any experiences with Postini ? > There are a couple of items I think should be distinguished that may > affect everyone's point of view. > > First, I believe there is a big distinction between a Service Provider's needs versus a > Corporate type organization's needs. The service provider is not the > final consumer of the email service therefore needs to give more > controls to the end user who is the customer. In a corporate > environment the company IS the final consumer paying for email service > and can make more 'corporate' decisions about the entire domain. > > For example, a company can say "My users will not be allowed to > receive mail from any mail server listed in ORDB (substitute any test > here) because I won't communicate with open relays." In this case the > company can reject any inbound connection from a domain failing ORDB. > It's their decision, case closed. > > On the other hand, if a service provider makes that decision he/she may lose business because > certain users DO want to receive mail from ORDB listed servers. > Therefore, the need for multiple test failures and per user settings becomes more important. > > The second distinction that should be made is volume. Most Imail > server installs are sitting around with plenty of extra capacity to do > alot of content scanning and run 20 different tests on each message. > In a high volume environment though, Imail is just not cost effective > to handle the whole job by itself. It needs a something in front of > it to clean things up a bit first. > > We run Imail/Declude/F-Prot/Sniffer/IMGate(3x). Our primary IMGate's > are set at relatively low strength. They serve as kind of the > 'gatekeeper' to the main Imail based scanners. They perform a few > selected single test failures and make sure connecting mail servers are non-abusive and > 'playing by the rules' so Imail doesn't have to deal with that. They > also reject all mail to invalid addresses. This item is critical for > a higher volume Imail system. Our IMGate's regularly reject over > 100,000 messages a day to invalid addresses (and that's before they > adapt to abusing IPs and block them at the network level). One > customer with a small domain (25 users) had a brute force attack the > other day with attempted delivery to over 11,600 address in a 2 hour period from > 4,000 separate IPs (mostly zombied home computers on subscriber > blocks). IMGate never broke a sweat. > > Our lower priority IMGate MX's though are set a very high strength > with a lot of single failure rejection. 99.6% (yes, we did measure > it) of the traffic we see at our backup MXs is spam. By holding all > this crap off Imail, it keeps Imail an economically viable solution. > Have we missed a few FPs in there? I'm sure we have...BUT the > cost/benefit is well worth it. > > So...I think that's what this whole discussion comes down to...cost > and benefit. Multiple test rejection is great, but as volumes grow you > just can't rely on it solely unless your willing to accept the exponentially increasing costs. > At some point, you've got to start adding some single failures in. > > Again, IMHO the best combination is a carefully balanced mix between > single failure rejection AND weighting. > > -- > Best regards, > David mailto:[EMAIL PROTECTED] > > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html > List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
