>Sorry Scott, you lost me on that one...
That's OK, you're not the first I've lost. :)
>SPAMCOP2 is not a defined test, so how is that going to work?
By defining it. The way that Declude is set up, there are no hard-coded
tests (just hard-coded test types, like the "ip4r" test type that most of
the DNS-based spam databases use). For example, when we found out about
the SPAMCOP test, we didn't make any changes to Declude, we just added the
SPAMCOP lines in the config files to define the test, and the actions to
use for it.
>RSP> For example, where you now have:
>
>RSP> SPAMCOP ip4r...
This is the definition for the SPAMCOP test (there's more to it; it's
"SPAMCOP ip4r bl.spamcop.net 127.0.0.2 x x 10 0"). That lets Declude know
what the SPAMCOP test is and how Declude should handle the test.
>RSP> in your global.cfg file, you can add another entry that is identical
>except
>RSP> with a different name, so you would have:
>
>RSP> SPAMCOP ip4r...
>RSP> SPAMCOP2 ip4r...
This would define a new test, called SPAMCOP2. The line will actually be
"SPAMCOP2 ip4r bl.spamcop.net 127.0.0.2 x x 10 0". This just defines a
test named SPAMCOP2, that works identically to the SPAMCOP test.
>RSP> Then, in your $default$.JunkMail file, you could have:
>
>RSP> SPAMCOP WARN
>RSP> SPAMCOP HOLD
>
>RSP> Then, both actions will be used.
In this case, I made a mistake; it should be:
SPAMCOP WARN
SPAMCOP2 HOLD
When the SPAMCOP test fails, the WARN action will be used. When the
SPAMCOP2 test fails (which will fail if the SPAMCOP test fails, since they
are identical tests with different names), the HOLD action will be used.
-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". You can E-mail
[EMAIL PROTECTED] for assistance. You can visit our web
site at http://www.declude.com .
