RE: [Mimedefang] SURBL WOES
> 2) cp or mv the init.pre file that resides in > /usr/local/etc/mail/spamassassin to your /usr/local/etc/mimedefang > directory. > > Using the first tweak allowed SURBL to work again on my > system after an > upgrade had caused them to stop (search the archives from > about November > for details) and I have heard of success with method 2 from > other people. > Sven, This seemed to work. Im not really sure why this version looked as tho it was ignoring the /usr/local/etc/mail/spamassassin/init.pre file. But your standard http://127.0.0.2/ test seems to work now for picking up SURBL tests. I have symlinked it now to that file and all is well Thanks again everyone for all the great suggestions. Kayne ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL WOES
Kayne Kruse presumably uttered the following on 03/03/05 12:35:
Anyone else having problems with MD 2.51 and SA 3.0.2 on perl 5.6.1 on
FreeBSD 4-11-STABLE not seeing SURBL?
I am able to get SURBL checks working in command line test of email. Even
spamassassin -D -C /usr/local/etc/mimedefang/spamassassin/sa-mimedefang.cf -t
< test.txt actually will produce surbl hits. Yet mail running through
mimedefang refuses to honor the SALocalTestsOnly=0 in the filter.
Im just failing to see what is causing the problem. I've just assumed it had
to do with some perl module permissions.
Kayne
There are two ways you can get this to work:
1) Look for the following lines in mimedefang.pl (I included line
numbers from mine to help narrow it down):
6079 $SASpamTester = Mail::SpamAssassin->new({
6080 local_tests_only => $SALocalTestsOnly,
6081 dont_copy_prefs=> 1,
=> 6082 LOCAL_RULES_DIR=> $LOCAL_RULES_DIR,
6083 userprefs_filename => $config});
Rmove the line that reads LOCAL_RULES_DIR as another part of the process
already reads the rulesets or
2) cp or mv the init.pre file that resides in
/usr/local/etc/mail/spamassassin to your /usr/local/etc/mimedefang
directory.
Using the first tweak allowed SURBL to work again on my system after an
upgrade had caused them to stop (search the archives from about November
for details) and I have heard of success with method 2 from other people.
Sven
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL WOES
Kayne Kruse wrote: To actually shed more light, its ONLY SURBL thats not working. The Spamcop, Spamhaus, NJABL, RFC-IGNORANT lookups are taging fine. Is the SURBL plugin loading correctly? Check which init.pre is getting read. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] SURBL WOES
> > Fairly certain, this is freebsd and I am using the FreeBSD > ported version of > mimedefang. It calls from > /usr/local/etc/mimedefang/spamassassin/sa-mimedefang.cf > > Per freebsd docs that is one of the valid paths. > To actually shed more light, its ONLY SURBL thats not working. The Spamcop, Spamhaus, NJABL, RFC-IGNORANT lookups are taging fine. KK ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] SURBL WOES
> Are you sure you're editing the right copy of > sa-mimedefang.cf? Unless > your filter code is explicitly pointing to that location, > it's going to > default to one of the following: > > /etc/mail/sa-mimedefang.cf > /etc/mail/spamasassin/sa-mimedefang.cf > /etc/mail/spamasassin/local.cf > /etc/mail/spamassassin.cf > > See the 'TEST FUNCTIONS' section of 'man mimedefang-filter' for the > nitty-gritty... > Fairly certain, this is freebsd and I am using the FreeBSD ported version of mimedefang. It calls from /usr/local/etc/mimedefang/spamassassin/sa-mimedefang.cf Per freebsd docs that is one of the valid paths. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] SURBL WOES
Are you sure you're editing the right copy of sa-mimedefang.cf? Unless your filter code is explicitly pointing to that location, it's going to default to one of the following: /etc/mail/sa-mimedefang.cf /etc/mail/spamasassin/sa-mimedefang.cf /etc/mail/spamasassin/local.cf /etc/mail/spamassassin.cf See the 'TEST FUNCTIONS' section of 'man mimedefang-filter' for the nitty-gritty... -- Mark Roedel Web Programmer / Analyst LeTourneau University Longview, Texas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kayne Kruse Sent: Thursday, March 03, 2005 11:36 AM To: mimedefang@lists.roaringpenguin.com Subject: [Mimedefang] SURBL WOES Anyone else having problems with MD 2.51 and SA 3.0.2 on perl 5.6.1 on FreeBSD 4-11-STABLE not seeing SURBL? I am able to get SURBL checks working in command line test of email. Even spamassassin -D -C /usr/local/etc/mimedefang/spamassassin/sa-mimedefang.cf -t < test.txt actually will produce surbl hits. Yet mail running through mimedefang refuses to honor the SALocalTestsOnly=0 in the filter. Im just failing to see what is causing the problem. I've just assumed it had to do with some perl module permissions. Kayne ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL
-ray wrote: Also while poking around, some SURBL mails got through cause BAYES_00 gave a negative score. In general do ya'll let BAYES_* rules score negative? Well, that *is* what they're for. Anything under 50% is supposed to be more likely legit than spam, based on mail you've seen before. The Bayes rules are there in part to compensate for things like news articles about deposed African leaders and large sums of money that might otherwise trip spam rules. I've actually increased the magnitude of the scores on the lower-end Bayes rules. (Hmm, "increase your magnitude" sounds like a phrase that'll show up in spam any day now.) If you're geting BAYES_00 on lots of obvious spam, you need to re-train your database or just stop using Bayes. Take a bunch of those messages (as many as possible) that hit SURBL but also hit BAYES_00 and run them through sa-learn --spam. What about the other negative scores? Just set them to zero? There aren't very many left. AFAIK it's Bayes, Habeas, Bonded Sender and ALL_TRUSTED (meaning the message started inside your network and never left). SPF passes are technically negative, but they're scored just enough to track (as they should be) and not to affect the score. If you've got your trust path set up right, ALL_TRUSTED is pretty much safe. If not it can cause problems, but you're better off fixing the trust path than disabling the rule because the trust path is used for other things. As for Bonded Sender and Habeas, forgeries are much harder than they used to be, so it depends on how much you trust their criteria and their verification process. -- Kelson Vibber SpeedGate Communications ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL
On Mon, 28 Feb 2005, -ray wrote:
So just to confirm. For all the rules with 'tflag net' set, i should set
their score to zero in local.cf to avoid editing files in
/usr/share/spamassassin directly. If the score on a network test is already
zero, then spamassassin will just skip it. Correct?
For the archives, i ran this:
cat /usr/share/spamassassin/* | grep '^tflag' | grep net | awk '{print
"score "$2" 0"}' >> /etc/mail/mimedefang/sa-mimedefang.cf
Commented out the SURBL (since i want to use them). Set
SALocalTestsOnly=0 and bam, SURBL tests started working! Hopefully other
other network tests aren't being used or my mailserver won't last
long...haha. In general are all the other network tests DNS based?
Also while poking around, some SURBL mails got through cause BAYES_00 gave
a negative score. In general do ya'll let BAYES_* rules score negative?
What about the other negative scores? Just set them to zero? thanks for
any info...
ray
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Ray DeJean http://www.r-a-y.org
Systems EngineerSoutheastern Louisiana University
IBM Certified Specialist AIX Administration, AIX Support
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL
On Mon, 28 Feb 2005, David F. Skoll wrote: That won't work in SpamAssassin 3.0.x. You have to enable network tests for SURBL. To turn off the ones you don't want, set their scores to 0. So just to confirm. For all the rules with 'tflag net' set, i should set their score to zero in local.cf to avoid editing files in /usr/share/spamassassin directly. If the score on a network test is already zero, then spamassassin will just skip it. Correct? ray -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ray DeJean http://www.r-a-y.org Systems EngineerSoutheastern Louisiana University IBM Certified Specialist AIX Administration, AIX Support =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL
On Mon, 28 Feb 2005, -ray wrote: > I've upgraded to Mimedefang 2.51 and Spamassassin 3.02, and SURBL lookup's > stopped working. SpamAssassin's code to detect whether or not DNS is available is, to be kind, horrible. Put this line: dns_available yes in your config file. > One thing to mention, i have $SaLocalTestsOnly=1. That won't work in SpamAssassin 3.0.x. You have to enable network tests for SURBL. To turn off the ones you don't want, set their scores to 0. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] SURBL lookups no longer happening after upgrade to2.48
On Fri, 2004-12-10 at 15:10 -0600, Mike Carlson wrote: > I am having the same problem with SA 3.01 and MIMEDefang 2.48 on FreeBSD. I > finally did get it working. > > I noticed in /usr/loca/bin/mimedefang.pl that LOCAL_RULES_DIR was defined as: > > hades# grep LOCAL_RULES /usr/local/bin/mimedefang.pl > my $LOCAL_RULES_DIR = "/usr/local/etc/mimedefang/spamassassin"; > LOCAL_RULES_DIR=> $LOCAL_RULES_DIR}); ># LOCAL_RULES_DIR=> $LOCAL_RULES_DIR, > > So I copied init.pre from /usr/local/etc/mail/spamassassin/ to > /usr/local/etc/mimedefang/spamassassin/ > > Now SURBLS are hitting: > > Dec 10 15:02:19 hades sm-mta[346]: iBAL2DTM000346: Milter change: header > X-Spam-Score: from 9.258 to 9.258 (*) > BAD_CREDIT,DCC_CHECK,DIGEST_MULTIPLE,EXCUSE_7,HTML_50_60,HTML_FONT_SIZE_TINY,HTML_FONT_TINY,HTML_IMAGE_ONLY_24,HTML_MESSAGE,HTML_TEXT_AFTER_BODY,HTML_TEXT_AFTER_HTML,MIME_BOUND_NEXTPART,MSGID_FROM_MTA_HEADER,RAZOR2_CF_RANGE_51_100,RAZOR2_CHECK,URIBL_OB_SURBL,URIBL_SBL,URIBL_WS_SURBL > > I was not getting any hits earlier today. Since this seemed to fix it I think > I may just take the init.pre in /usr/local/etc/mimedefang/spamassasin/ and > make it a symbolic link to the one in /usr/local/etc/mail/spamassassin/ > directory. That way I only have to manage one file. > > --Mike > > > > > From: [EMAIL PROTECTED] on behalf of Rob MacGregor > Sent: Fri 12/10/2004 1:47 PM > To: [EMAIL PROTECTED] > Subject: Re: [Mimedefang] SURBL lookups no longer happening after upgrade > to2.48 > > > > Ok, putting the test into local.cf got me the following error: > > ... mimedefang-multiplexor[50777]: Slave 0 stderr: Failed to run > URIBL_SC_SURBL SpamAssassin test, skipping:(Can't locate > object method "check_uridnsbl" via package > "Mail::SpamAssassin::PerMsgStatus" at > /usr/local/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/PerMsgStatus.pm > line 2296. ) > > Which is what happens if the module isn't loaded, so it looks like > something isn't happening with init.pre when called from MD. > > Sticking the loadplugin command into local.cf AND importing all the > UIRBL lines makes it work, but there's obviously something broken :( > This behavior could explain why the order of $config and LOCAL_RULES_DIR seems to make a difference in mimedefang.pl. In the default installation, LOCAL_RULES_DIR is set in the hash when passed to the new constructor, followed by $config (which reads sa-mimedefang.cf). At that point, SA sees the empty LOCAL_RULES_DIR and doesn't know about init.pre. By putting LOCAL_RULES_DIR after $config in the hash, SA sees $config and in order to parse $config loads the init.pre from the default location, then it sees the LOCAL_RULES_DIR. Although hash order should not make a difference, if spamassassin loops through the hash (for $keys .), it may parse them in order causing this behavior. Sven ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] SURBL lookups no longer happening after upgrade to2.48
I am having the same problem with SA 3.01 and MIMEDefang 2.48 on FreeBSD. I finally did get it working. I noticed in /usr/loca/bin/mimedefang.pl that LOCAL_RULES_DIR was defined as: hades# grep LOCAL_RULES /usr/local/bin/mimedefang.pl my $LOCAL_RULES_DIR = "/usr/local/etc/mimedefang/spamassassin"; LOCAL_RULES_DIR=> $LOCAL_RULES_DIR}); # LOCAL_RULES_DIR=> $LOCAL_RULES_DIR, So I copied init.pre from /usr/local/etc/mail/spamassassin/ to /usr/local/etc/mimedefang/spamassassin/ Now SURBLS are hitting: Dec 10 15:02:19 hades sm-mta[346]: iBAL2DTM000346: Milter change: header X-Spam-Score: from 9.258 to 9.258 (*) BAD_CREDIT,DCC_CHECK,DIGEST_MULTIPLE,EXCUSE_7,HTML_50_60,HTML_FONT_SIZE_TINY,HTML_FONT_TINY,HTML_IMAGE_ONLY_24,HTML_MESSAGE,HTML_TEXT_AFTER_BODY,HTML_TEXT_AFTER_HTML,MIME_BOUND_NEXTPART,MSGID_FROM_MTA_HEADER,RAZOR2_CF_RANGE_51_100,RAZOR2_CHECK,URIBL_OB_SURBL,URIBL_SBL,URIBL_WS_SURBL I was not getting any hits earlier today. Since this seemed to fix it I think I may just take the init.pre in /usr/local/etc/mimedefang/spamassasin/ and make it a symbolic link to the one in /usr/local/etc/mail/spamassassin/ directory. That way I only have to manage one file. --Mike From: [EMAIL PROTECTED] on behalf of Rob MacGregor Sent: Fri 12/10/2004 1:47 PM To: [EMAIL PROTECTED] Subject: Re: [Mimedefang] SURBL lookups no longer happening after upgrade to2.48 Ok, putting the test into local.cf got me the following error: ... mimedefang-multiplexor[50777]: Slave 0 stderr: Failed to run URIBL_SC_SURBL SpamAssassin test, skipping:(Can't locate object method "check_uridnsbl" via package "Mail::SpamAssassin::PerMsgStatus" at /usr/local/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/PerMsgStatus.pm line 2296. ) Which is what happens if the module isn't loaded, so it looks like something isn't happening with init.pre when called from MD. Sticking the loadplugin command into local.cf AND importing all the UIRBL lines makes it work, but there's obviously something broken :( -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
On Fri, 10 Dec 2004 14:51:26 -0500, Lew E. Lefton <[EMAIL PROTECTED]> wrote: > > Thanks! That worked for me. I copied the init.pre installed by > spamassassin to /etc/mail/spamassassin and SURBL testpoints are scoring > agin. A similar approach has just worked for me - with FreeBSD it looks like MD looks under /usr/local/etc/mimedefang/spamassassin for it's config. I had a symlink to the SA conf file, but not for init.pre. I've just symlinked the whole directory to the SA one and everything now works. Thanks. -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
On Fri, 10 Dec 2004 14:20:19 -0500 (EST), David F. Skoll <[EMAIL PROTECTED]> wrote: > > Aha! This is what my /etc/mail/spamassassin/init.pre file contains: > > loadplugin Mail::SpamAssassin::Plugin::URIDNSBL Yup, got that. > You have to put the init.pre file in the LOCAL_RULES_DIR directory, > I believe. That's where it is :( An eyeball of the difference between the debug outputs from having that line in the local.cf and the init.pre is that if it's in local.cf the following don't appear: registering glue method for check_uridnsbl (Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x8b855cc)) ... debug: URIDNSBL: domain ... debug: URIDNSBL: query ... -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
Ok, putting the test into local.cf got me the following error: ... mimedefang-multiplexor[50777]: Slave 0 stderr: Failed to run URIBL_SC_SURBL SpamAssassin test, skipping:(Can't locate object method "check_uridnsbl" via package "Mail::SpamAssassin::PerMsgStatus" at /usr/local/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/PerMsgStatus.pm line 2296. ) Which is what happens if the module isn't loaded, so it looks like something isn't happening with init.pre when called from MD. Sticking the loadplugin command into local.cf AND importing all the UIRBL lines makes it work, but there's obviously something broken :( -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
David F. Skoll wrote: On Fri, 10 Dec 2004, Rob MacGregor wrote: This file loads modules for URIDNSBL, hashcash and SPF by default. Putting the same lines in the SA config file doesn't have the same effect - the modules don't seem to be loaded. Aha! This is what my /etc/mail/spamassassin/init.pre file contains: loadplugin Mail::SpamAssassin::Plugin::URIDNSBL You have to put the init.pre file in the LOCAL_RULES_DIR directory, I believe. Thanks! That worked for me. I copied the init.pre installed by spamassassin to /etc/mail/spamassassin and SURBL testpoints are scoring agin. Lew ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
On Fri, 10 Dec 2004 19:15:56 +0100 (CET), Martin Blapp <[EMAIL PROTECTED]> wrote: > > Same here. I had to cut and paste all the SURBL lookups into the > local-sa.cf file to get them working again. SPAMHAUS and other RBL > still work in both situations. Only SURBL stopped working. Some digging suggests it's the lack of loading the URIDNSBL module. With SA 3.0 there's an init.pre file that loads modules for SA. In it there's a line to load the URIDNSBL module. If I comment it out then I get the same result as for MD. This file loads modules for URIDNSBL, hashcash and SPF by default. Putting the same lines in the SA config file doesn't have the same effect - the modules don't seem to be loaded. -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
On Fri, 10 Dec 2004, Rob MacGregor wrote: > This file loads modules for URIDNSBL, hashcash and SPF by default. > Putting the same lines in the SA config file doesn't have the same > effect - the modules don't seem to be loaded. Aha! This is what my /etc/mail/spamassassin/init.pre file contains: loadplugin Mail::SpamAssassin::Plugin::URIDNSBL You have to put the init.pre file in the LOCAL_RULES_DIR directory, I believe. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
David F. Skoll wrote:
On Fri, 10 Dec 2004, Rob MacGregor wrote:
Similarly with MD 2.48 (the latest on FreeBSD ports) and SpamAssassin
3.0.1 under FreeBSD 5.3-STABLE I don't see the SURBL lookups working
when MD is calls SA. When SA is called directly however the lookups
do work.
MD 2.49 and SA 3.0.1 works fine for me, with SURBL.
I have $SALocalTestsOnly = 0; in the filter, and it works like a charm.
Do you have anything odd in sa-mimedefang.cf ?
I am having the same problem with MD 2.49 and SA 3.0.1 on Solaris 9. I
think it must be related to config files but I haven't been able to
pinpoint it. Here are some lines from my configs:
# grep SALocal /etc/mail/mimedefang-filter
$SALocalTestsOnly = 0;
# grep -v ^# /etc/mail/sa-mimedefang.cf | grep -v '^$'
required_hits 5
ok_locales en
rewrite_subject 0
skip_rbl_checks 0
use_bayes 1
bayes_auto_learn 1
bayes_learn_to_journal 1
bayes_path /etc/mail/spamassassin/bayes/bayes
bayes_file_mode 0700
bayes_use_hapaxes 1
bayes_auto_learn_threshold_nonspam0.0
bayes_auto_learn_threshold_spam 8.0
urirhssub URIBL_JP_SURBL multi.surbl.org. A 64
body URIBL_JP_SURBL eval:check_uridnsbl('URIBL_JP_SURBL')
describe URIBL_JP_SURBL Contains a URL listed in the JP SURBL blocklist
tflagsURIBL_JP_SURBL net
score URIBL_JP_SURBL 4.0
When a message with body containing
http://surbl-org-permanent-test-point.com-MUNGED/
(with no "-MUNGED" of course) is piped as follows
cat surbl_test | spamassassin -tD
I get a lot of stuff that includes this:
debug: running body-text per-line regexp tests; score so far=0
debug: running uri tests; score so far=0
debug: registering glue method for check_uridnsbl
(Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x52d71c))
debug: Razor2 is not available
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x52d71c)
implements 'check_tick'
debug: URIDNSBL: domain "surbl-org-permanent-test-point.com" listed
(URIBL_SC_SURBL): 127.0.0.2
debug: URIDNSBL: query for surbl-org-permanent-test-point.com took 1
seconds to look up (multi.surbl.org.:surbl-org-permanent-test-point.com)
debug: URIDNSBL: queries completed: 2 started: 0
debug: URIDNSBL: queries active: at Fri Dec 10 12:42:44 2004
debug: running raw-body-text per-line regexp tests; score so far=0
debug: running full-text regexp tests; score so far=0
debug: Razor2 is not available
debug: Current PATH is:
/bin:/usr/bin:/usr/sbin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/ccs/bin:/usr/openwin/bin:/usr/ucb
debug: Pyzor is not available: pyzor not found
debug: DCCifd is not available: no r/w dccifd socket found.
debug: DCC is not available: no executable dccproc found.
debug: Running tests for priority: 500
debug: RBL: success for 21 of 21 queries
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x52d71c)
implements 'check_post_dnsbl'
debug: running meta tests; score so far=4.271
but when I explicitly use sa-mimedefang.cf
cat surbl_test | spamassassin --config-file=/etc/mail/sa-mimedefang.cf -tD
I get
debug: running body-text per-line regexp tests; score so far=0
debug: running uri tests; score so far=0
debug: registering glue method for check_uridnsbl
(Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0xae5614))
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0xae5614)
implements 'check_tick'
debug: URIDNSBL: query for surbl-org-permanent-test-point.com took 0
seconds to look up (multi.surbl.org.:surbl-org-permanent-test-point.com)
debug: URIDNSBL: queries completed: 2 started: 0
debug: URIDNSBL: queries active: at Fri Dec 10 12:42:25 2004
debug: running raw-body-text per-line regexp tests; score so far=0
debug: running full-text regexp tests; score so far=0
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0xae5614)
implements 'check_post_dnsbl'
debug: auto-learn: currently using scoreset 3, recomputing score based
on scoreset 1.
debug: auto-learn: message score: 0, computed score for autolearn: 0
debug: auto-learn? ham=0, spam=8, body-points=0, head-points=0,
learned-points=0
debug: auto-learn? no: inside auto-learn thresholds, not considered ham
or spam
debug: is spam? score=0 required=5
Any suggestions?
Cheers,
Lew Lefton
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
Hi, > It's the same file as is used when I call SA directly, and the SURBL > lookups work fine there. Other RBL lookups work fine. Same here. I had to cut and paste all the SURBL lookups into the local-sa.cf file to get them working again. SPAMHAUS and other RBL still work in both situations. Only SURBL stopped working. Martin ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
On Fri, 2004-12-10 at 12:17 -0500, David F. Skoll wrote: > On Fri, 10 Dec 2004, Rob MacGregor wrote: > > > Similarly with MD 2.48 (the latest on FreeBSD ports) and SpamAssassin > > 3.0.1 under FreeBSD 5.3-STABLE I don't see the SURBL lookups working > > when MD is calls SA. When SA is called directly however the lookups > > do work. > > MD 2.49 and SA 3.0.1 works fine for me, with SURBL. > I have $SALocalTestsOnly = 0; in the filter, and it works like a charm. > Do you have anything odd in sa-mimedefang.cf ? > > Regards, > > David. my sa-mimedefang.cf contains some whitelist_from_rcvd listings, some all_spam_to listings, use_dcc enabled and use_razor disabled. Fairly stock config. Again, oddly enough, it was the changing of the order (or commenting out the LOCAL_RULES_DIR) in the mimedefang.pl that solved the issue for me, for whatever reason. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
On Fri, 10 Dec 2004 12:17:56 -0500 (EST), David F. Skoll
<[EMAIL PROTECTED]> wrote:
> MD 2.49 and SA 3.0.1 works fine for me, with SURBL.
> I have $SALocalTestsOnly = 0; in the filter, and it works like a charm.
> Do you have anything odd in sa-mimedefang.cf ?
Other than some whitelist/blacklist addresses and some score
alterations, all I have is:
bayes_path /usr/local/etc/mail/spamassassin/bayes/bayes
bayes_auto_learn 1
lock_method flock
ok_locales en
use_terse_report 0
skip_rbl_checks 0
header RCVD_IN_ABUSEATeval:check_rbl('ABUSEAT','cbl.abuseat.org.')
describe RCVD_IN_ABUSEATABUSEAT: sender is listed in Composite
list cbl.abuseat.org
scoreRCVD_IN_ABUSEAT3
tflags RCVD_IN_ABUSEATnet
header FAKE_QMAIL_ID Message-ID =~
/\.[0-9a-z]{0,5}[a-z]{1,5}[0-9a-z]{0,5}\.qmail\@/i
describe FAKE_QMAIL_ID SOBER: Fake QMAIL message ID
scoreFAKE_QMAIL_ID 3
It's the same file as is used when I call SA directly, and the SURBL
lookups work fine there. Other RBL lookups work fine.
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
On Fri, 10 Dec 2004, Rob MacGregor wrote: > Similarly with MD 2.48 (the latest on FreeBSD ports) and SpamAssassin > 3.0.1 under FreeBSD 5.3-STABLE I don't see the SURBL lookups working > when MD is calls SA. When SA is called directly however the lookups > do work. MD 2.49 and SA 3.0.1 works fine for me, with SURBL. I have $SALocalTestsOnly = 0; in the filter, and it works like a charm. Do you have anything odd in sa-mimedefang.cf ? Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
On Fri, 10 Dec 2004 13:59:48 +0100 (CET), Martin Blapp <[EMAIL PROTECTED]> wrote: > > Here we have the same problem. SURBL lookups stopped working after upgrading > to 2.49. Similarly with MD 2.48 (the latest on FreeBSD ports) and SpamAssassin 3.0.1 under FreeBSD 5.3-STABLE I don't see the SURBL lookups working when MD is calls SA. When SA is called directly however the lookups do work. Nothing is logged to indicate any problems. -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
Hi, > > LOCAL_RULES_DIR after all the regular config items in the hash. After > > modifying mimedefang.pl (see attached diff/patch for mimedefang.pl.in) > > to do the same, I find that SURBL lookups work. So it wasn't the > > presence of that argument/key but rather it place in the hash that > > caused SURBL to not work. > > That makes no sense whatsoever; a hash is unordered! So it shouldn't > matter where you put the key. > > (I'm not saying that it didn't fix the problem, but I am saying that it > makes no sense!) Here we have the same problem. SURBL lookups stopped working after upgrading to 2.49. Martin ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
On Thu, 9 Dec 2004, Sven Willenberger wrote: > After examining spamassassin itself, I found that it places > LOCAL_RULES_DIR after all the regular config items in the hash. After > modifying mimedefang.pl (see attached diff/patch for mimedefang.pl.in) > to do the same, I find that SURBL lookups work. So it wasn't the > presence of that argument/key but rather it place in the hash that > caused SURBL to not work. That makes no sense whatsoever; a hash is unordered! So it shouldn't matter where you put the key. (I'm not saying that it didn't fix the problem, but I am saying that it makes no sense!) Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
On Tue, 2004-11-02 at 14:37 -0500, Sven Willenberger wrote:
> On Tue, 2004-11-02 at 12:49 -0500, David F. Skoll wrote:
> > On Tue, 2 Nov 2004, Sven Willenberger wrote:
> >
> > > Actually I don't see anything in the logs to indicate failure of the
> > > SURBL lookups. I have tried using both embedded and not embedded perl to
> > > run MD to no avail. Spamassassin is being called from the default
> > > location in the distributed filter.example.
> >
> > I'm unable to duplicate this. Anyone else? Please include OS
> > and SpamAssassin version.
> >
> > Regards,
>
> I have found the line in mimedefang.pl that was causing my problem:
>
>6079 $SASpamTester = Mail::SpamAssassin->new({
>6080 local_tests_only => $SALocalTestsOnly,
>6081 dont_copy_prefs=> 1,
> => 6082 LOCAL_RULES_DIR=> $LOCAL_RULES_DIR,
>6083 userprefs_filename => $config});
>
> Line 6082 passes LOCAL_RULES_DIR as an argument to the new()
> method/constructor but this does not show up in perldoc Mail::
> SpamAssassin as a valid argument. Commenting out that line (which, by
> the way does not appear in earlier versions of mimedefang) results in
> the SURBL lookups being done again:
>
> X-Spam-Score: 10.209 (**) DCC_CHECK,HTML_20_30,HTML_MESSAGE,
> MANGLED_RATES,MANGLED_SAVELE,MIME_HTML_ONLY,URIBL_WS_SURBL
>
> Also the tcpdump does verify traffic now going to the local caching
> rbldns server.
>
> I checked to see if that line was being added by the FreeBSD ports
> scripts, but upon investigating the source distro's copy of
> mimedefang.pl.in I see that line in there as well.
>
> FreeBSD 5.2.1-p9
> SpamAssassin version 3.0.1
> running on Perl version 5.8.5
>
After examining spamassassin itself, I found that it places
LOCAL_RULES_DIR after all the regular config items in the hash. After
modifying mimedefang.pl (see attached diff/patch for mimedefang.pl.in)
to do the same, I find that SURBL lookups work. So it wasn't the
presence of that argument/key but rather it place in the hash that
caused SURBL to not work. This is on a 5.3-Stable FreeBSD box running SA
3.0.1 and Mimedefang 2.48. (Verified that the order is still the same in
2.49 as well).
Sven
--- mimedefang.pl.in.orig Thu Dec 9 08:49:17 2004
+++ mimedefang.pl.in Thu Dec 9 08:49:50 2004
@@ -6080,6 +6080,6 @@
local_tests_only => $SALocalTestsOnly,
dont_copy_prefs=> 1,
- LOCAL_RULES_DIR=> $LOCAL_RULES_DIR,
- userprefs_filename => $config});
+ userprefs_filename => $config,
+ LOCAL_RULES_DIR=> $LOCAL_RULES_DIR});
pop_status_tag();
}
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
Hi,
> Not directly related to discussion.
>
> I guess that header was added by MIMEDefang? How do you fetch original
> SpamAssassin headers into MIMEDefang? I'd rather have SpamAssassin
> style headers appended (X-Spam-Status, X-Spam-Report, and so on) than
> X-Spam-Score from example mimedefang-filter.
I generate them. I think it would be nice to have something like that in
the example filter but it's not me deciding that. Anyway, here are parts
of our filter ...
#
# keep track of start time
#
my ($done, $start, $TIMEVAL_T);
if (! $skip_checks ) {
require 'sys/syscall.ph';
$TIMEVAL_T = "LL";
$done = $start = pack($TIMEVAL_T, ());
syscall(&SYS_gettimeofday, $start, 0) != -1
or die "gettimeofday: $!";
}
[... Call Spamassassin ]
#
# Fix broken formatting done by spamassassin rules.
#
my $fixed_report = "";
if ($hits >= $report_req) {
$fixed_report = $report;
$fixed_report =~ s/\n+\z//g;# fixes for multiline header
$fixed_report =~ s/\n[\t ]{0,}\n/\n/g; # removes empty lines
$fixed_report =~ s/\n/\n\t/g; # to stop sendmail complaining
}
#
# Use the excellent wrapping function of Text::Wrap.
#
my $firstpart;
my $secondpart;
$Text::Wrap::columns = 60;
$Text::Wrap::huge = 'wrap';
$Text::Wrap::break = '(?<=[\s,])';
if ($names =~ /([0-9A-Z_,]{0,40},)(.*)/ ) {
$firstpart = $1 . "\n\t";
$secondpart = Text::Wrap::wrap('',"\t",$2);
$names = $firstpart . $secondpart;
} else {
$names = Text::Wrap::wrap('',"\t",$names);
}
}
#
# Get the final scan time
#
my ($seconds, $scantime);
syscall( &SYS_gettimeofday, $done, 0) != -1
or die "gettimeofday: $!";
my @start = unpack($TIMEVAL_T, $start);
my @done = unpack($TIMEVAL_T, $done);
# fix microseconds
for ($done[1], $start[1]) {
$_ /= 1_000_000
}
$scantime = sprintf "%.4f", ($done[0] + $done[1] ) - ($start[0] + $start[1]
);
$seconds = "\"" . $scantime . " seconds\"";
}
action_add_header("X-Spam-Report", "$fixed_report");
action_add_header("X-Spam-Status", "No, hits=$hits scantime=$seconds tests=$names");
Martin
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
Sven Willenberger wrote:
On Tue, 2004-11-02 at 12:49 -0500, David F. Skoll wrote:
I have found the line in mimedefang.pl that was causing my problem:
6079 $SASpamTester = Mail::SpamAssassin->new({
6080 local_tests_only => $SALocalTestsOnly,
6081 dont_copy_prefs=> 1,
=> 6082 LOCAL_RULES_DIR=> $LOCAL_RULES_DIR,
6083 userprefs_filename => $config});
Thanks
That has got my SURBLs working again.
--
_/_/_/_/ _/ _/
_/_/ _/ _/ _/
_/_/_/_/ _/
_/_/ _/ _/ _/
_/_/_/_/ _/ _/ _/
Bill Maidment
Maidment Enterprises Pty Ltd
Unless you are named "Alfred E. Newman", you may read only the "odd
numbered words" (every other word beginning with the first) of the
message above. If you have violated that, then you hereby owe the sender
AU$10 for each even numbered word you have read.
Adapted from "Stupid Email Disclaimers" (see
http://www.goldmark.org/jeff/stupid-disclaimers/)
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
Am Mo, den 01.11.2004 schrieb Sven Willenberger um 22:40: > I am using the same filter as in the 2.44 release and have verified > $SALocalTestsOnly = 0; > > in the sa-mimedefang.cf file I have made sure that skip_rbl_checks 0 > Sven Willenberger >From reviewing the mimedefang.pl code where "$SALocalTestsOnly" is handled I have the impression, it can only be set globally. Is that right? I would like to override the default setting of deactivated remote tests by SA, but to omit these tests for some mailinglists. Any suggestion? Alexander -- Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.8-1.521smp Serendipity 20:07:17 up 13 days, 17:46, load average: 0.40, 0.41, 0.36 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
Am Di, den 02.11.2004 schrieb Martin Blapp um 19:20: > Works still here with SpamAssassin 3.01 and Mimedefang 2.48 ... > > Nov 2 16:02:12 mx1 sm-mta[13819]: iA2F1oSl013819: Milter add: header: > X-Spam-Status: Yes, hits=49.893 required=5 scantime="13.5556 seconds" > Martin How do you achieve the "scantime" value? Would you mind to post your filter code for that? Alexander -- Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.8-1.521smp Serendipity 20:05:22 up 13 days, 17:44, load average: 0.16, 0.35, 0.34 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
On Tue, 2004-11-02 at 12:49 -0500, David F. Skoll wrote:
> On Tue, 2 Nov 2004, Sven Willenberger wrote:
>
> > Actually I don't see anything in the logs to indicate failure of the
> > SURBL lookups. I have tried using both embedded and not embedded perl to
> > run MD to no avail. Spamassassin is being called from the default
> > location in the distributed filter.example.
>
> I'm unable to duplicate this. Anyone else? Please include OS
> and SpamAssassin version.
>
> Regards,
I have found the line in mimedefang.pl that was causing my problem:
6079 $SASpamTester = Mail::SpamAssassin->new({
6080 local_tests_only => $SALocalTestsOnly,
6081 dont_copy_prefs=> 1,
=> 6082 LOCAL_RULES_DIR=> $LOCAL_RULES_DIR,
6083 userprefs_filename => $config});
Line 6082 passes LOCAL_RULES_DIR as an argument to the new()
method/constructor but this does not show up in perldoc Mail::
SpamAssassin as a valid argument. Commenting out that line (which, by
the way does not appear in earlier versions of mimedefang) results in
the SURBL lookups being done again:
X-Spam-Score: 10.209 (**) DCC_CHECK,HTML_20_30,HTML_MESSAGE,
MANGLED_RATES,MANGLED_SAVELE,MIME_HTML_ONLY,URIBL_WS_SURBL
Also the tcpdump does verify traffic now going to the local caching
rbldns server.
I checked to see if that line was being added by the FreeBSD ports
scripts, but upon investigating the source distro's copy of
mimedefang.pl.in I see that line in there as well.
FreeBSD 5.2.1-p9
SpamAssassin version 3.0.1
running on Perl version 5.8.5
Sven
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
Martin Blapp wrote: Works still here with SpamAssassin 3.01 and Mimedefang 2.48 ... Nov 2 16:02:12 mx1 sm-mta[13819]: iA2F1oSl013819: Milter add: header: X-Spam-Status: Yes, hits=49.893 required=5 scantime="13.5556 seconds" tests=BAYES_99,DOMAIN_RATIO,HTML_90_100, HTML_FONT_BIG,HTML_IMAGE_ONLY_08,HTML_MESSAGE,\n\tHTML_TITLE_EMPTY,MIME_HTML_ONLY, MSGID_SPAM_CAPS,RBL_COMBO_A_2,RBL_COMBO_B_2,RBL_COMBO_C_2,RBL_COMBO_F_3, RCVD_HELO_IP_MISMATCH,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DSBL,RCVD_IN_SORBS_WEB, RCVD_IN_SWINOG_SPAM,RCVD_IN_XBL,RCVD_NUMERIC_HELO,URIBL_OB_SURBL,URIBL_SBL,URIBL_WS_SURBL Not directly related to discussion. I guess that header was added by MIMEDefang? How do you fetch original SpamAssassin headers into MIMEDefang? I'd rather have SpamAssassin style headers appended (X-Spam-Status, X-Spam-Report, and so on) than X-Spam-Score from example mimedefang-filter. -- Aleksandar Milivojevic <[EMAIL PROTECTED]>Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
--On Tuesday, November 02, 2004 12:49:07 PM -0500 "David F. Skoll" <[EMAIL PROTECTED]> wrote: I'm unable to duplicate this. Anyone else? Please include OS and SpamAssassin version. Now I realized that it works again, but it wasn't for over an hour (maybe connection problems to spamcop). Unfortunately it happend exactly after the update to 2.48 Confirmed working config: OS: Sparc Solaris 9 Perl: This is perl, v5.8.5 built for sun4-solaris SA: Mail-SpamAssassin-3.0.1 MIMEDefang-2.48 (using embedded Perl inerperter) Didi -- --- Didi Rieder [EMAIL PROTECTED] PGPKey ID: 3431D0B0 --- ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
Hi, > I'm unable to duplicate this. Anyone else? Please include OS > and SpamAssassin version. Works still here with SpamAssassin 3.01 and Mimedefang 2.48 ... Nov 2 16:02:12 mx1 sm-mta[13819]: iA2F1oSl013819: Milter add: header: X-Spam-Status: Yes, hits=49.893 required=5 scantime="13.5556 seconds" tests=BAYES_99,DOMAIN_RATIO,HTML_90_100, HTML_FONT_BIG,HTML_IMAGE_ONLY_08,HTML_MESSAGE,\n\tHTML_TITLE_EMPTY,MIME_HTML_ONLY, MSGID_SPAM_CAPS,RBL_COMBO_A_2,RBL_COMBO_B_2,RBL_COMBO_C_2,RBL_COMBO_F_3, RCVD_HELO_IP_MISMATCH,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DSBL,RCVD_IN_SORBS_WEB, RCVD_IN_SWINOG_SPAM,RCVD_IN_XBL,RCVD_NUMERIC_HELO,URIBL_OB_SURBL,URIBL_SBL,URIBL_WS_SURBL Martin ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
On Tue, 2 Nov 2004, Sven Willenberger wrote: > Actually I don't see anything in the logs to indicate failure of the > SURBL lookups. I have tried using both embedded and not embedded perl to > run MD to no avail. Spamassassin is being called from the default > location in the distributed filter.example. I'm unable to duplicate this. Anyone else? Please include OS and SpamAssassin version. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
--On Tuesday, November 02, 2004 09:38:15 AM -0500 Sven Willenberger <[EMAIL PROTECTED]> wrote: On Mon, 2004-11-01 at 17:16 -0500, David F. Skoll wrote: On Mon, 1 Nov 2004, Sven Willenberger wrote: > FreeBSD 5.2.1-Release had been using MD 2.44 with SA 2.64 and later > with 3.0 and successfully was querying the SURBL nameserver (running a > cached copy locally) -- this was visible using tcpdump on the loopback > device listening on the rbldns port. Upgraded to MD 2.48 and no longer > see traffic on this port, nor do I see the results of the SURBL tests > in the spammy mail. Do you see messages like this in your log? WARNING: Something in your Perl filter appears to have opened a file descriptor outside of any function. With embedded Perl, you should move any code that opens a file descriptor into filter_initialize. DON'T BLAME MIMEDEFANG IF YOUR FILTER FAILS IN MYSTERIOUS AND UNPREDICTABLE WAYS. Regards, David. Actually I don't see anything in the logs to indicate failure of the SURBL lookups. I have tried using both embedded and not embedded perl to run MD to no avail. Spamassassin is being called from the default location in the distributed filter.example. same here Didi -- --- Didi Rieder [EMAIL PROTECTED] PGPKey ID: 3431D0B0 --- pgpRik0UXL72u.pgp Description: PGP signature ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
On Mon, 2004-11-01 at 17:16 -0500, David F. Skoll wrote: > On Mon, 1 Nov 2004, Sven Willenberger wrote: > > > FreeBSD 5.2.1-Release had been using MD 2.44 with SA 2.64 and later with > > 3.0 and successfully was querying the SURBL nameserver (running a cached > > copy locally) -- this was visible using tcpdump on the loopback device > > listening on the rbldns port. Upgraded to MD 2.48 and no longer see > > traffic on this port, nor do I see the results of the SURBL tests in the > > spammy mail. > > Do you see messages like this in your log? > >WARNING: Something in your Perl filter appears to have opened a file >descriptor outside of any function. With embedded Perl, you should >move any code that opens a file descriptor into filter_initialize. >DON'T BLAME MIMEDEFANG IF YOUR FILTER FAILS IN MYSTERIOUS AND >UNPREDICTABLE WAYS. > > Regards, > > David. Actually I don't see anything in the logs to indicate failure of the SURBL lookups. I have tried using both embedded and not embedded perl to run MD to no avail. Spamassassin is being called from the default location in the distributed filter.example. Sven (p.s. subscribed to list now) ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
On Mon, 1 Nov 2004, Sven Willenberger wrote: > FreeBSD 5.2.1-Release had been using MD 2.44 with SA 2.64 and later with > 3.0 and successfully was querying the SURBL nameserver (running a cached > copy locally) -- this was visible using tcpdump on the loopback device > listening on the rbldns port. Upgraded to MD 2.48 and no longer see > traffic on this port, nor do I see the results of the SURBL tests in the > spammy mail. Do you see messages like this in your log? WARNING: Something in your Perl filter appears to have opened a file descriptor outside of any function. With embedded Perl, you should move any code that opens a file descriptor into filter_initialize. DON'T BLAME MIMEDEFANG IF YOUR FILTER FAILS IN MYSTERIOUS AND UNPREDICTABLE WAYS. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL effectiveness and domain turnaround time
On 9/8/2004 23:27, David F. Skoll wrote: > in. (Unless you use Microsoft's bloated Sender ID XML garbage that > probably forces you to use TCP for your queries.) I've been following IETF-mxcomp some and AFAIK the MARID working group has struck XML from the standard :) Cheers, ~Jason -- ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL effectiveness and domain turnaround time
13 servers which are 486/50dx2's and 13 thousand node zeon clusters makes a bit of a difference. It's not the number but the size that counts. ;) > sc.surbl.org has 13 name servers, just like the root name servers of > the Internet. You can imagine that if 13 name servers can handle all > the root name server traffic, it's not so bad to have a low TTL. :-) > > Regards, > > David. > > -- ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL effectiveness and domain turnaround time
On Thu, 9 Sep 2004, Jeff Rife wrote: > I'll have to > see if I can set up my cache so that negative responses from specific > domains/servers have a different TTL than "general" ones. This is set in the SOA record of the domain, which for sc.surbl.org is 15 minutes. You can, of course, override this in your BIND configuration, but maybe you shouldn't. > > DNS lookups are pretty cheap -- one UDP packet out and one UDP packet back > > in. > A couple of delays in response can just kill throughput on sendmail, > though. If you handle enough mail for that to be a concern, you're probably eligible for an rsync zone transfer. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL effectiveness and domain turnaround time
On 8 Sep 2004 at 23:27, David F. Skoll wrote: > sc.surbl.org seems to have a 15-minute TTL. And the negative-response > caching TTL is under your control. I guess that was my point. A short TTL does little for IPs/URLs that are in the BL. It just makes sure that a removed entry gets propogated quickly...not usually an issue. On the other hand, it would be logical for the "client" to put negative responses at no less than 1 hour before you query again, at least for "general" queries. I'll have to see if I can set up my cache so that negative responses from specific domains/servers have a different TTL than "general" ones. > DNS lookups are pretty cheap -- one UDP packet out and one UDP packet back > in. A couple of delays in response can just kill throughput on sendmail, though. > sc.surbl.org has 13 name servers, just like the root name servers of > the Internet. You can imagine that if 13 name servers can handle all > the root name server traffic, it's not so bad to have a low TTL. :-) Since the root domains don't change much, they have a larger TTL, I suspect. A quick check shows that it is a little more than 6 hours. Also, they really just pass off TTLs from the subdomains (i.e., whatever is in the SOA for roaringpenguin.com gets propagated to the .com root servers). Unfortunately, though, some brain-dead implementations (*cough* Microsoft *cough*) "lock on" to one DNS server, so having more than one is useless. Once a MS client asks what machine is authoritative for surbl.org, gets the "here's the list" answer, and picks one, it uses that one until the TTL expires, even if it can't contact it anymore. Unless surbl.org uses a load-sharing system that isn't evident to the client, MS clients wouldn't take advantage of multiple servers. -- Jeff Rife| "This? This is ice. This is what happens to SPAM bait: | water when it gets too cold. This? This is [EMAIL PROTECTED] | Kent. This is what happens to people when [EMAIL PROTECTED] | they get too sexually frustrated." | -- Chris Knight, "Real Genius" ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL effectiveness and domain turnaround time
As of 8/20/04, SURBL is using TTLs of 25 minutes from http://www.surbl.org/news.html: 8/20/04: As part of our continuing TTL experiment, we have set the TTLs on all lists to 25 minutes. If the resulting DNS traffic does not change much, then we will leave the slower-changing lists at 25 minutes and change SC back to 10 minutes. Additionally, you can rsync the database and run it locally. Regards, KAM > This is a good thought, but caching of DNS records defeats this. I > know that most BLs have low TTL in the records, but lower than about an > hour would cause a lot of extra network traffic, especially on the "not > found" responses. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL effectiveness and domain turnaround time
On Wed, 8 Sep 2004, Jeff Rife wrote: > This is a good thought, but caching of DNS records defeats this. I > know that most BLs have low TTL in the records, but lower than about an > hour would cause a lot of extra network traffic, especially on the "not > found" responses. sc.surbl.org seems to have a 15-minute TTL. And the negative-response caching TTL is under your control. DNS lookups are pretty cheap -- one UDP packet out and one UDP packet back in. (Unless you use Microsoft's bloated Sender ID XML garbage that probably forces you to use TCP for your queries.) sc.surbl.org has 13 name servers, just like the root name servers of the Internet. You can imagine that if 13 name servers can handle all the root name server traffic, it's not so bad to have a low TTL. :-) Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL effectiveness and domain turnaround time
On 7 Sep 2004 at 20:15, David F. Skoll wrote: > Well, there is an absolute lower limit on the useful lifetime of a > domain. A spammer probably can't throw a domain away in much less > than 4-8 hours, because it takes that long to complete the spam run > and for victims to go check their mail. Although I check my mail > practically continuously when I'm at work, many people only check > their mail a few times a day. If SURBL can react within 15-30 > minutes, it will still remain quite effective. This is a good thought, but caching of DNS records defeats this. I know that most BLs have low TTL in the records, but lower than about an hour would cause a lot of extra network traffic, especially on the "not found" responses. -- Jeff Rife| SPAM bait: | http://www.nabs.net/Cartoons/RhymesWithOrange/BigDogs.gif [EMAIL PROTECTED] | [EMAIL PROTECTED] | ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL
On Tue, 13 Jul 2004, Stefan Schoeman wrote:
> restarting MD, I could see no difference. So, after reading through the mail
> archive, I enabled SALocalTestsOnly=0 as suggested. This lead to SA checks
> within MIMEDefang taking around 5 seconds rather than the usual 0.05 to 0.4
The "local tests only" setting seems to be affected by that "tflags"
tag in your SA config file. If you put in the "tflags net" statement as
directed in the surbl example, then you will have to enable network tests.
But what I did was to leave the tflags tag out and leave $SALocalTestsOnly
set to 1.
> solution, so am I perhaps missing something? Do I need to upgrade to a newer
> version of MIMEDefang, or perhaps recompile it after upgrading SA to 2.63?
No, you shouldn't have to do that. When I was having problems, I
looked for this line in filter_end:
my($hits, $req, $names, $report) = spam_assassin_check();
and put this right below it:
action_add_header("X-UAH-Debug", "hits=$hits names=$names");
to see exactly what SA returned. Also, if you are testing from localhost
or from another host in your domain, be sure that you have not put
something in your filter to skip checks in your local domain (I did, and
it bit me when I was testing).
HTH...
Jim McCullars
University of Alabama in Huntsville
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL question
Jim McCullars said: > Is there a consensus as to which of the SURBL lists should be used for > blocking? I have started refusing (not just adding a score to) email that > shows up on sc.surbl.org, but occasionally spam will get through that > would have been caught by one of the other lists. I am thinking of going > to multi.surbl.org, but does anyone have a feel for whether this might > generate too high a false positive rate? TIA... > Yes. The estimed FP for multi based on GA runs is exponentially higher then just the base surbl list, based on the surbl admin. Perhaps add score based on multi, but don't block. -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] surbl works for spamassassassin and not mimedefang
David F. Skoll said: >> Surbl works when called from spamassassassin as part of spamd but does >> not >> work when challed from mimedefang. > > Make sure $SALocalTestsOnly = 0; is in your filter. duh. Thanks. That solved the problem, for some reason I was having a brain block. Surbl appears to a very effective additional filter, I have moved the value of it up to a whopping 6.0 on my external relay. -- Luke Computer Science System Administrator ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] surbl works for spamassassassin and not mimedefang
On Mon, 17 May 2004, Lucas Albers wrote: > Surbl works when called from spamassassassin as part of spamd but does not > work when challed from mimedefang. Make sure $SALocalTestsOnly = 0; is in your filter. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] surbl
At 01:46 PM 4/13/2004, Lucas Albers wrote: Need to patch SA. I'm leery of modifying my code, and hopefully the package maintainer for my OS will fold in surbl into their package. As I understand it, the next release of SpamAssassin will be able to handle this type of feature without patching. Kelson Vibber SpeedGate Communications ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] surbl
On Tue, 13 Apr 2004, David F. Skoll wrote: >On Tue, 13 Apr 2004, Kelson Vibber wrote: > >> Then SURBL should be fine. It's just a RHSBL, built from domains >> advertised in spam rather than domains that (appear to) send it. A client >> using SURBL just parses URLs out of the message and queries the domain >> names against the SURBL zone. > >It still makes me nervous. An attacker could put hundreds of URLs >in the message, leading to hundreds of SURBL lookups. This kind of >traffic-amplification just screams DoS to me. But then, I tend to >be more paranoid than most. :-) > >I think SURBL should be used for (let's say) the first 20 URLs in a >message, and if there are more than 20 URLs in the message, it should get >a big spam score and further SURBL lookups suppressed. > >Regards, Personally I think any RBL is a DoS waiting to happen. All it takes is them being down/broken/etc and poof your servers are down for a bit with the usual management questions of why did you allow it to happen. The only way I would use an RBL in a large production enviroment is if they had a DB push mechanism where I could sign up for a daily DB4 and source file from either a central site or some osrt of P2P cloud. But I am a grumpy young sysadmin. -- Stephen John Smoogen[EMAIL PROTECTED] Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] surbl
On 13 Apr 2004 at 11:52, Michael Faurot wrote: > In article <[EMAIL PROTECTED]> you wrote: > > > It depends what you mean by "tried this with MIMEDefang". > > Literally that. Is anyone currently using one of the SURBL plugins with > SpamAssassin in a MIMEDefang environment? Yes. It's effectively not much different from a DNSBL check, so all the usual MIMEDefang caveats for enabling those apply. So far it's been extremely effective, triggering on ~60% of caught spam with zero false positives. My understanding is that the SURBL list utilizes data from SpamCop reports, with some checks in place to prevent common false positives. It remains to be seen whether it will remain as effective once the spammers decide to try poisoning the SpamCop system with false reports. Nels Lindquist <*> Information Systems Manager Morningstar Air Express Inc. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] surbl
Need to patch SA. I'm leery of modifying my code, and hopefully the package maintainer for my OS will fold in surbl into their package. I'm interested in using it, but just waiting for a package maintainer to put it in. This should just be a dropin for MIMEDEFANG if SA supports it, as it uses no persistent db or similar. Michael Faurot said: > Literally that. Is anyone currently using one of the SURBL plugins with > SpamAssassin in a MIMEDefang environment? -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] surbl
In article <[EMAIL PROTECTED]> you wrote: >> Literally that. Is anyone currently using one of the SURBL plugins with >> SpamAssassin in a MIMEDefang environment? > Yes. It's effectively not much different from a DNSBL check, so all > the usual MIMEDefang caveats for enabling those apply. Cool. That's exactly what I was wondering. Thanks! ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] surbl
On 2004-04-13 (Tuesday) at 10:28:28 -0600, Nels Lindquist wrote: > On 13 Apr 2004 at 11:52, Michael Faurot wrote: > > > In article <[EMAIL PROTECTED]> you wrote: > > > > > It depends what you mean by "tried this with MIMEDefang". > > > > Literally that. Is anyone currently using one of the SURBL plugins with > > SpamAssassin in a MIMEDefang environment? > > Yes. It's effectively not much different from a DNSBL check, so all > the usual MIMEDefang caveats for enabling those apply. > > So far it's been extremely effective, triggering on ~60% of caught > spam with zero false positives. I'm getting good results too. Very useful at the moment, hopefully it'll stay that way. Being a SpamAssassin test the score can always be tweaked in the future if spammers manage to make it less reliable. Mark. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] surbl
On Tue, 13 Apr 2004, Kelson Vibber wrote: > Then SURBL should be fine. It's just a RHSBL, built from domains > advertised in spam rather than domains that (appear to) send it. A client > using SURBL just parses URLs out of the message and queries the domain > names against the SURBL zone. It still makes me nervous. An attacker could put hundreds of URLs in the message, leading to hundreds of SURBL lookups. This kind of traffic-amplification just screams DoS to me. But then, I tend to be more paranoid than most. :-) I think SURBL should be used for (let's say) the first 20 URLs in a message, and if there are more than 20 URLs in the message, it should get a big spam score and further SURBL lookups suppressed. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] surbl
At 04:48 AM 4/13/2004, David F. Skoll wrote: I think a DB of known spam URL's is safe. Following URL's makes me nervous... Then SURBL should be fine. It's just a RHSBL, built from domains advertised in spam rather than domains that (appear to) send it. A client using SURBL just parses URLs out of the message and queries the domain names against the SURBL zone. Kelson Vibber SpeedGate Communications ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] surbl
In article <[EMAIL PROTECTED]> you wrote: > I think a DB of known spam URL's is safe. That's how I read things for the SURBL plugins. It sounds like it's essentially a DNS based RBL for the URLs found in the body of messages. > Following URL's makes me nervous... I don't believe that's the way SURBL is supposed to work. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] surbl
In article <[EMAIL PROTECTED]> you wrote: > It depends what you mean by "tried this with MIMEDefang". Literally that. Is anyone currently using one of the SURBL plugins with SpamAssassin in a MIMEDefang environment? > In response to your second question, if SpamAssassin supports > something by itself, MIMEDefang calling SpamAssassin will utilize such > a filtering technique. Not necessarily. At least that wasn't the case with MIMEDefang and Spamassassin's auto-whitelist system, initially. I know MD and AWL work together now, but that wasn't always the case. Thus my questions about integration of the SURBL plugin with SpamAssassin in a MIMEDefang environment. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] surbl
On Mon, 12 Apr 2004, Richard Laager wrote: > There's no way a spammer can get around this sort of filtering by > padding a message with extra URIs since in this case a single case of > a URI is enough to trip the test. Following URI's makes me intensely nervous... here are some nasty things a spammer could do: - Have URI's that resolve to unroutable addresses, ensuring lots of slowness and timeouts as the parser tries to follow them. - Exploit bugs in URL followers to potentially reveal sensitive information. Creative combinations of cookies, JavaScript, etc. could work wonders. (Remember, your URL follower has to simulate an actual browser to do its job properly.) - An attacker with knowledge of your internal network could potentially force the URL scanner to follow something that has a side effect. I think a DB of known spam URL's is safe. Following URL's makes me nervous... Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] surbl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > It looks interesting, but I'm wondering if anyone else has tried > this with MIMEDefang? Will it work with MIMEDefang calling > SpamAssassin by way of its modules? It depends what you mean by "tried this with MIMEDefang". So, I'll respond out of order. In response to your second question, if SpamAssassin supports something by itself, MIMEDefang calling SpamAssassin will utilize such a filtering technique. On a related note, this thought of a URI blacklist is an idea I've had (and shared with others) for a while. We'll see the same problem as we did for Bayesian filtering... Spammers will start including bogus URIs to avoid the filtering (or as a joe job). This is not to say it's useless, just as Bayesian filtering is still useful. URI filtering can be quite handy. I recently implemented code that would check a message for URIs and then run those URIs through our pornography filtering database. I called SpamAssassin to do the actual URI parsing and I did the porn checks from within our MIMEDefang filter. In this way, I was able to leverage the SpamAssassin code and avoid reinventing the wheel. Because of the way I coded, we only run full SpamAssassin checks if the customer wants full spam filtering. If the customer only wants porn filtering, we only need to run the URI parsing portion of the SpamAssassin code, greatly saving CPU power. (If the customer wants neither, we do pass the mail through unscanned.) So, it's possible to do URI filtering by itself if desired. There's no way a spammer can get around this sort of filtering by padding a message with extra URIs since in this case a single case of a URI is enough to trip the test. (Contrast this with approaches that would check the percentage of bad URIs. I'm not sure if this SUBL stuff does that or not.) And, the URIs aren't going into a database based off messages, so there is no danger of joe jobs. Richard Laager Wikstrom Telecom Internet -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 Comment: If you don't know what this is, you can safely ignore it. iQA/AwUBQHtdkG31OrleHxvOEQIPkwCg5KDHynym0btADSNuJOIyx/rm+BIAoIbx VKIYVICtf9byij9ye8zQbuMr =T2oO -END PGP SIGNATURE- ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
