From: david
In a situation where single point failure tests are being administered at the corporate level (not at the ISP) then IMGate and similar solutions may appear to work well because the admin (presumably) is looking after the concerns of his *customers* i.e. internal users. They have been empowered to do so by their employers to act in good faith and with the companies and it's employees interest at heart.
I think that is where you will see the big difference in useres of single test blocking. Most admins do attempt to serve the interests of their employers. Internal IT departments generally then favor the lowest FP plan - the end recipient of the email is an employee of the same company they work for. Those running large ISP's, however, the end consumer is not an internal employee. The companies interests are to make money for stockholders and that demands a balancing of minimizing captial and ongoing expenses versus lost business due to efforts made to best utilize the resources available (ie, customer that leave due to missing important emails). Of course, with the right marketing spin, you can sell the blocking of "a few" legit emails along with all the "bad" stuff people don't want to get. The problem arises in the inability to tell how much "good" email is lost.
Not to single you out, but I've seen this comment a few times from different people in this thread and I keep wondering why the assumption is that if you are rejecting email for your customers (whether you are a service provider or a company) you can't tell them some information about the rejects. I use Postfix for my filtering and have a script (courtesy of someone on the postfix-users list) that goes through the mail log and extracts the From: for each To: where there was a reject and gives a nice little summary. Even has a command line option to automatically email that summary to the To: address with their summary.
For example, blocking all attachments in the name of blocking viruses (there are other solutions possible, some of which would all all attachments to be received). Next, block all html and scripts, again, since a virus could come in that way. Soon, we'll all be back to the same text messaging that we started with.
why just rely on one test rather than a multiple test that provide better confidence?
I agree, except for the attempts to use our domain name or ip in the HELO or confirmed spammers (confirmed by US) that are known problems.
Go one further step back to the ISP level any test system that rejects is simply crazy because you can never be sure you're not rejecting FP's.
What an ISP can be positive is spam is even less than their end user. For example, just because WE don't want to get mail from @leftbehindprophecy, doesn't mean someone else doesn't.
You're in a position to determine what should
happen to a customers email. You have the power to excercise that control and it's all very clever stuff but do you have the right to do so?
Of course, I'm sure their TOS says they do. Legally. Somehwere, in perhaps a lot of very ambiguous/weasel words. Ethically is another matter. Even those who pay extra for such blocking, however, should have the true effects clearly spelled out to them (for example: we block all class C's from other ISP's that don't help block spam and countries that have spam issues, as well as any company using cable of dsl connections, so your customers at those ISP's won't be able to email you).
This is the key--tell people what you are doing and how you filter. They are entrusting the filtering to you (whether you is an ISP or a company IT dept.) so your customers deserve to know what exactly is going on behind the scenes. This is sound advice regardless of your filtering strategy.
Also, let your customers know that email doesn't offer guaranteed delivery. Period. Yes, it works well most of the time but so does the power grid ;-)
-- Chris Scott Host Orlando, Inc. http://www.hostorlando.com/
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/
