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/
