On the other hand, with this attitude, it will be impossible to stop viruses in the future.>From my point of view, a false positive is a false positive is a false positive. I just need to make sure that a message has to fail more than the BADHEADERS test to get rejected.
The problem is that detecting malformed E-mail is a very important part of the process in stopping spam and viruses, as many spamware programs use broken headers (or let the spammers create their own headers), and viruses will take advantage of known vulnerabilities.
Having an occasional spam come through so you can get legitimate E-mail from broken mailers may be acceptable. But what happens when you have to choose between accepting legitimate mail from broken mailers or protecting yourself against viruses? There are a number of recently discovered vulnerabilities that some legitimate mailers are using (unintentionally, of course), that *must* be blocked (without blocking them, future viruses will be allowed to bypass virus scanners on the mailserver).
It's also very important to remember that lots of this legitimate broken E-mail gets lost, anyways. Many mailservers will block such E-mail. And in many cases, the mail gets lost in inboxes.
It's a choice of dealing with it now or dealing with it later. Waiting means that you'll receive more spam now, and you'll probably have to get hit with a virus outbreak before dealing with the problem, which can be very costly.
Of course, the choice is completely up to you, and only you can know your unique situation well enough to determine whether or not to allow such E-mail through.
We are always willing to deal with legitimate companies who have products that are sending out broken E-mail (either failing the BADHEADERS test in Declude JunkMail, or getting caught as vulnerabilities with Declude Virus). In the majority of cases, though, upgrading to the latest version of the software used to send the mail is all that is required (and if someone is sending broken mail and isn't willing to upgrade, they have to accept the consequences).> The only legitimate mail that the BADHEADERS test catches is mail that has > broken headers (which may never reach you anyways). Whenever legitimate > E-mail fails the BADHEADERS test, I strongly recommend fixing the > problem. In most cases, blocking based on the BADHEADERS test alone is > very useful.So how would you recommend fixing the problem?
Correct (or at least according to http://www.rfc-ignorant.org , which runs the test).> >NOABUSE IIIIIIIIIIIIIIII > >NOPOSTMASTER IIIIIIIIIIIIII > > Note that these catch all E-mail from @yahoo.com, @hotmail.com, and some > other major domains, which accounts for their high false positives. And the reason that they catch that stuff is because Yahoo.com and Hotmail.com don't support the e-mail addresses abuse@<domain.com> and postmaster@<domain.com>?
Exactly. The legitimate E-mail that fails the SPAMHEADERS test is typically E-mail sent from poorly designed webservers (often ones where "The Boss" decides it will be better for a web designer to write a mail client than to buy one -- the same type of "The Boss" that says "Gee, why bother fix that security hole if nobody has broken into it yet?"). The legitimate mail sent from mailservers that have no reverse DNS entry are typically don't have decent infrastructure in place (or use an ISP who is clueless), which means that it is very likely they aren't running a firewall, and are more likely to have compromised servers that will send out spam.> >REVDNS IIIIIIIII > >SPAMHEADERS IIIIIIIIIIII > > ... and these will always have high false positives, but are very good at > detecting systems that are likely to send out spam (IE it may be sending > legitimate mail today, but is likely to send spam tomorrow). Is that because they would be used as mail relays?
Of course, there is a lot of legitimate mail that fails those two tests. I wouldn't recommend blocking E-mail that fails the REVDNS or SPAMHEADERS tests (as I do recommend with the BADHEADERS test), but the REVDNS and SPAMHEADERS tests typically work quite well with the weighting system.
A weight of 0 will occur if the E-mail doesn't fail any spam tests (or otherwise ends up with a weight of 0, which could happen if there were negative weights).What does it mean when there is no weight at the end of the X-SPAM-TESTS-FAILED line?
I had read this paragraph (and the corresponding paragraph for $default$.junkmail) and to be honest a general paragraph about the purpose of the file wasn't as helpful to me as a line by line breakdown of each entry in the file would've been.
That's something that we are looking into.
Thanks for pointing that out -- I believe it was originally in the manual. I'll have to check to see why it isn't there.I had started at the top of GLOBAL.CFG and would read down one line at a time. If got to something I didn't understand I would do a CTRL-F and try to search for it on the Declude.JunkMail Manual, http://www.declude.com/JunkMail/manual.htm, and I didn't get very far before I got to "LOGLEVEL", the 13th line down. When I searched for it I found 2 references for it in description's of how to do other things but nothing else. What I was expecting to find was an interation of all the different possible settings for LOGLEVEL, e.g. LOW MID HIGH (I still don't even know for sure if that's all of them!), and what specifically is added and/or substracted from the log when you set LOGLEVEL to each one of those settings.
The suggestion about using the WEIGHT10/WEIGHT20 tests is in the original E-mail we send out, and in the "Basic Configuration" section --- but it sounds like it would be better to have a new section of the manual that covers sample configurations.So most people, unless they are power users, leave the default tests that are configured in GLOBAL.CFG as they are and they just work within the bound of those tests. That makes sense to me. It would be nice if your documentation had a basic, mini, how-to-get-started that they would be refered to immediately after the installation steps were complete.
-Scott
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
