headers
Jon Rowlan | 3 May 2008 10:56
Favicon

MIMEDefang and SpamAssassin forking threads

Hi All,

I am using MD and trying to use SA for spam management.

There appears to be a problem, under Debian at least, where a file
opened during SA is being closed by another thread of the MD
multiplexor.

My log shows :

May  2 20:45:17 britney mimedefang-multiplexor[19378]: Slave 0 stderr:
print() on closed filehandle LTMP at
/usr/share/perl5/Mail/SpamAssassin/Locker/UnixNFSSafe.pm line 146.

May  2 20:45:17 britney mimedefang-multiplexor[19378]: Slave 0 stderr:
stat() on closed filehandle LTMP at
/usr/share/perl5/Mail/SpamAssassin/Locker/UnixNFSSafe.pm line 148.

May  2 20:45:17 britney mimedefang-multiplexor[19378]: Slave 0 stderr:
locker: safe_unlock: failed to create lock tmpfile
/var/spool/MIMEDefang/.spamassassin/auto-whitelist.lock.britney.sads.com
.19378 at /usr/share/perl5/Mail/SpamAssassin/Locker/UnixNFSSafe.pm line
149.

This was reported over a year ago by a Debian developer to the authors
of SA (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398831) and
it seems that they do not consider this a bug as they do not support
multi threaded use of their software.
(see https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5333)
(Continue reading)

Permalink | Reply | 9 comments |
headers
David F. Skoll | 3 May 2008 15:04
Favicon

Re: MIMEDefang and SpamAssassin forking threads

Jon Rowlan wrote:

> There appears to be a problem, under Debian at least, where a file
> opened during SA is being closed by another thread of the MD
> multiplexor.

The multiplexor is not multi-threaded.  The entire point of the
multiplexor is to convert the multi-threaded Sendmail Milter library
into a bunch of single-threaded Perl processes.  So the error lies
somewhere in your filter or in SpamAssassin.

Regards,

David.
Permalink | Reply | 0 comments |
headers
David F. Skoll | 3 May 2008 15:06
Favicon

Re: MIMEDefang and SpamAssassin forking threads

Ah, OK, I see what's happening (after looking at the Debian
bug reports.)

There are two fixes:

1) Don't use embedded Perl.  That way, $$ gets set properly.

2) Upgrade to version 2.64 of MIMEDefang, which sets $$ properly even
if you use embedded Perl.

Regards,

David.
Permalink | Reply | 6 comments |
headers
Martin Blapp | 4 May 2008 12:49
Picon
Favicon

Still getting _SUMMARY_ instead of a report in 1 of 1000 cases


Hi,

One year ago I've reported that one of thousend scanned
mails doesn't get e subsitituted _SUMMARY_ report. Size
doesn't matter: it happens with large and small mails.
Unfortunatly we still get those errors even witgh recent
software versions.

We use SpamAssassin version 3.2.4, running on Perl version 5.8.8
with mimedefang 2.64 embedded.

Instead we see for example:

X-UCSC-EDU-SpamReport: _SUMMARY_

Google tells me that I'm not the only one
seeing this problem. And all those examples out
in the net seem to use Mimedefang.

You can test if you get such cases with this code snippet:

($hits, $req, $names, $report) = spam_assassin_check();
if ($report =~ /_SUMMARY_/) {
 	md_syslog('err', "$QueueID: tempfail, SA internal ERROR");
}

Any ideas anyone ?

--
(Continue reading)

Permalink | Reply | 2 comments |
headers
Martin Blapp | 5 May 2008 00:04
Picon
Favicon

Re: Still getting _SUMMARY_ instead of a report in 1 of 1000 cases


Hi,

I'm trying now to repeat the failing spamassassin check, with
debug statements enabled:

$SASpamTester->{debug} = 'all';
Mail::SpamAssassin::Logger::add_facilities($SASpamTester->{debug});
($hits, $req, $names, $report) = spam_assassin_check();
if ($report =~ /_SUMMARY_/) {
 	md_syslog('err', "$QueueID: tempfail, SA internal ERROR");
 	exit;
}

I could not find a way to disable debugging again, so the only way
seems to call exit to kill the worker.

--
Martin

Martin Blapp, <mb <at> imp.ch> <mbr <at> FreeBSD.org>
------------------------------------------------------------------
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: <finger -l mbr <at> freebsd.org>
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
------------------------------------------------------------------
Permalink | Reply | 1 comment |
headers
Andrzej Marecki | 5 May 2008 09:47
Picon

Sendmail 8.14.3 vs. mimedefang

Sendmail 8.14.3 has just been released. This version just fixes a few bugs 
including this one: "the libmilter state engine did not deal correctly with 
milters that requested the omission of protocol steps during the negotiation 
callback".

I don't know if *this* is the reason or not but whatever the true reason is, 
libmilter.a of ver. 8.14.3 breaks mimedefang-2.64; when mimedefang that has 
been compiled with new libmilter.a is started, a massage:

/usr/local/bin/mimedefang: smfi_register failed

appears and the mimedefang daemons do not start.

A simple workaround I adopted is that I reverted to previous version of 
mimedefang binaries, i.e. those compiled with libmilter.a of Sendmail 8.14.2.
It works fine with Sendmail 8.14.3. However, given that, obviously, mimedefang
should be compiled with libmilter.a of that version of Sendmail mimedefang
actually works with, I suspect mimedefang needs a fix.

Am I right, David?

--
Andrzej

--

-- 
-----------------------------------------------------------------------------  
Andrzej Marecki                | 
Torun Centre for Astronomy     |   e-mail: amr <at> astro.uni.torun.pl
N. Copernicus University       |   WWW:    http://www.astro.uni.torun.pl
ul. Gagarina 11                |   tel: +48 56 6113032
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jon Rowlan | 5 May 2008 11:23
Favicon

RE: MIMEDefang and SpamAssassin forking threads

Thanks David, I will give that a try but I will have to wait until the
weekend as that will need a kernel upgrade.

Cheers,

jON

-----Original Message-----
From: mimedefang-bounces <at> lists.roaringpenguin.com
[mailto:mimedefang-bounces <at> lists.roaringpenguin.com] On Behalf Of David
F. Skoll
Sent: 03 May 2008 14:06
To: mimedefang <at> lists.roaringpenguin.com
Subject: Re: [Mimedefang] MIMEDefang and SpamAssassin forking threads

Ah, OK, I see what's happening (after looking at the Debian
bug reports.)

There are two fixes:

1) Don't use embedded Perl.  That way, $$ gets set properly.

2) Upgrade to version 2.64 of MIMEDefang, which sets $$ properly even
if you use embedded Perl.

Regards,

David.

_______________________________________________
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jon Rowlan | 5 May 2008 11:23
Favicon

mimedefang and simple spamassassin test

I have been trying for the last couple of days to get a simple SA test
working and it appears to be ignoring my rule.

First off I put the rule into \etc\spamassassin\local.cf but then
tracing through the MD code, it looks like the
\etc\mail\sa-mimedefang.cf file takes over.

I put the test in that file also.

The test is ...

header BAD_TEST             Subject =~ /spamtest01/i
score BAD_TEST              5.00

but I do not seem to be able to trigger this to be trapped as spam???

Does anyone have any ideas on how I can get this to work please?

Thanks,

jON
Permalink | Reply | 17 comments |
headers
Ron Wilhoite | 5 May 2008 12:35
Favicon

Re: mimedefang and simple spamassassin test

On 05/05/2008 05:23 AM Jon Rowlan wrote:
> I have been trying for the last couple of days to get a simple SA test
> working and it appears to be ignoring my rule.
> 
> First off I put the rule into \etc\spamassassin\local.cf but then
> tracing through the MD code, it looks like the
> \etc\mail\sa-mimedefang.cf file takes over.
> 
> I put the test in that file also.
> 
> The test is ...
> 
> header BAD_TEST             Subject =~ /spamtest01/i
> score BAD_TEST              5.00
> 
> but I do not seem to be able to trigger this to be trapped as spam???
> 
> Does anyone have any ideas on how I can get this to work please?
> 
> Thanks,
> 
> jON
> 

I have local.cf as a symlink to sa-mimedefang.cf. I don't remember doing 
that, but I'm sure I had a good reason (documentation, suggestion on 
this list).

At the risk of stating the obvious, you also need to force MIMEDefang to 
reread your rules via "md-mx-ctrl reread" or similar means.
(Continue reading)

Permalink | Reply | 2 comments |
headers
David F. Skoll | 5 May 2008 13:42
Favicon

Re: Sendmail 8.14.3 vs. mimedefang

Andrzej Marecki wrote:
> I suspect mimedefang needs a fix.

> Am I right, David?

It's too early to tell, but I am doubtful.  My guess is that you compiled
MIMEDefang against the new libraries, but against the old header files
so the SMFI_VERSION macro does not match.  Please investigate if this is
the case.  Compiling against the new libraries and the new header files
should work if the Sendmail release notes are accurate.

(You may need to do a complete "make distclean" to do a clean build.)

Regards,

David.
Permalink | Reply | 1 comment |

Gmane