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 lik
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,
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/sit
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
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 su
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:
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
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. O
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 dire
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 a
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 fin
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
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
> >
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 wo
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 embedd
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 mimedefan
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_
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 "$SA
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 t
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 be
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,
--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). Unfort
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 se
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.ex
--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 wa
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
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 thi
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
28 matches
Mail list logo
