> I'm not saying "don't filter." I'm saying "Filter based on the results of > several tests, rather than just one." By doing so, you are guarantee fewer > false positives. And, if you want, you can find out exactly how many false > positives there are.
Isn't the only way to determine if there are false positives to accept and review each email?
You are correct. You can only accurately determine how many false positives there are by accepting the mail.
As was mentioned before this is a huge waste of resources IMHO, though I agree that it is probably the right approach for some.
Correct on both counts. Many IMail users do have enough bandwidth, CPU, and other resources to handle the spam load. But those that don't can use a tool to reject the E-mail. However, I would *strongly* urge them to use a multi-test system for rejecting the E-mail. I'd much prefer someone reject E-mail than use a single-test system.
We have clients who have been to the point of swearing off email due to the volume of spam which remains an issue if they still have to review emails marked as spam and doesn't solve their dilemma very well.
FWIW, I don't recommend reviewing mail that gets caught as spam (whether it is rejected or deleted (in which case you can't view it), quarantined, etc.). It's just too much work.
But it's okay with me if others handle it that way. I guess I don't understand what
the big deal is if somebody takes a different approach.
I think that's because you seem to be confusing several things. I'm saying "Please do not mark E-mail as spam [reject, quarantine, whatever] if it fails only a single spam test" (that's what http://www.declude.com/plea.htm is all about).
You can use a multi-test system and still reject the E-mail. And you can use a multi-test system and not do body filtering. Len confused things a bit when he started discussing Declude vs. IMGate, but that's a separate discussion. The important part is making sure that you don't block mail based on a single test (with the rare exception of tests should never catch mail from a legitimate mailserver, such as a "MAIL FROM" domain that doesn't exist).
Most of us use criteria that no mail server anywhere should fail.
That's very good.
There is, however, a growing trend moving away from that -- basically saying that legitimate mailers need to constantly make changes to undocumented problems (I'll bet there is no book on running a mailserver that says you shouldn't use an ISP that doesn't offer vanity reverse DNS, for example). Today, the Issue du Jour is vanity reverse DNS (since without it, you can't accurately tell if someone is using a static vs. dynamic IP). Tomorrow, it may be something else. For example, one that would affect most people on this list is if the hard core anti-spammers say "Gee, virtually all compromised machines and open proxies sending spam are running Windows, and the majority of mailservers run Unix, so we're going to block all Windows servers that connect to us." It certainly seems extreme, but a year ago requiring vanity reverse DNS would have seemed very extreme (the first reported case of requiring vanity reverse DNS was in May, 2003).
If an email gets rejected from our server it should get rejected. I don't mean that in a BOFH kind of way I mean that the email is either spam or there are serious mis-configuration issues on the other end.
And that's fine -- *if* you know what you are doing (which you may well). A lot of people, though, are rejecting E-mail based on a single test that will not only have false positives from mailservers that are seriously misconfigured, but also will also have false positives from mailservers that aren't seriously misconfigured.
-Scott
---
Declude JunkMail: The advanced anti-spam solution for IMail mailservers.
Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection.
Find out what you have been missing: Ask for a free 30-day evaluation.
--- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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/
