On Tue, 22 Feb 2005, Andy Jezierski wrote:
> Kelson <[EMAIL PROTECTED]> wrote on 02/22/2005 11:30:46 AM:
>
> > Jay Levitt wrote:
> > > I have SA 3.01 running under mimedefang 2.43 with sendmail 8.13.1. At
> > > some point, SA seems to stop doing lookups on the DNSBLs; spam gets
> > > through that is listed in multiple BLs; if I check manually with
> > > spamassassin -t, it detects the BL entry, even if I run it moments
> after
> > > the spam was received.
[snip..]
> > Make sure MIMEDefang hasn't created a new /etc/mail/sa-mimedefang.cf on
> > an upgrade.
> >
> > That happened to my server a while back -- We were just using
> > /etc/mail/spamassassin/local.cf, and upgraded MD, and MD saw there was
> > no sa-mimedefang.cf, so it created it with the defaults -- and the
> > defaults disable DNSBLs.
>
> Could this be the same problem as the discussion in the "Spammer
> Anti-SURBL tactic" thread?
No, the problem that I saw was caused by the contents of the message.
it didn't matter how I fed it to SA, SURBL did not 'fire' on the spammer
"payload" URL, eventho the site was in several lists.
When I first saw the spam I was puzzled and ran it thru SA with full
debugging to see what was going on.
( spamassassin -D rulesrun=255 < message.txt )
I saw lots of SURBL tests on the "decoy" URLs but none of the "payload".
I removed the CR characters from the "payload" URL, retested but still
no hits, removed most of the "decoy" URLs from the message, then a
retest did hit. So it was entirely due to the message content
exploiting two weaknesses in SA.
PS: if you do a full debug SA run, it's best to redirect the output to
a file for reading, it produces thousands of lines of output. ;)
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
