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)
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
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
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
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.
___
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
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
All,
I've upgraded to Mimedefang 2.51 and Spamassassin 3.02, and SURBL lookup's
stopped working. I read the thread from December and some work arounds
were mentioned, just wondering if anyone has deduced the proper way to
get SURBL going again. I've already copied init.pre to the
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
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
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?
-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.
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
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
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.
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
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:
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
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
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
.
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
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
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
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
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.
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
--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
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
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
--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).
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,
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
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
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
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
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.
Hi,
I've upgraded to MIMEDefang 2.47 I modified mimedefang.pl
And changed $SALocalTestsOnly = 0; and skip_rbl_checks 0
SURBL is still not working, I had 2.45 previously and it worked
Fine. Are there any other changes that need to be made in 2.47?
Thanks
Trevor
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
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
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
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
--
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.
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
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
Hi everyone,
I still don't seem to get SURBL to work the way I want it to. I had MD2.39
with SA2.60. I upgraded to SA2.63 and applied the SpamCopURI module. When
restarting MD, I could see no difference. So, after reading through the mail
archive, I enabled SALocalTestsOnly=0 as suggested. This
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
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
I am encountering a strange problem.
Surbl works when called from spamassassassin as part of spamd but does not
work when challed from mimedefang.
Any idea how to troubleshoot this?
I get hists for surbl on spamc tagged mail but the same mail is not tagged
with mimedefang when it comes on the
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
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
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.
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
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
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
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
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
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
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
-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
59 matches
Mail list logo
