Unknown command '^W' in RESULTS file

Hello,

I have been using MIMEDefang the past 3 years without
problem. Now I
setup LDAP and I have lots of this messages in my logfiles I
have tried
compiling sendmail/libmilter with/without LDAP.... It seems
that 
MIMEDefang learns that exists an LDAP server using
ldap.domain as 
hostname (I have a DNS alias), when I delete that DNS record
the error 
disappears. Where is the problem? Why?
...
Mar  7 01:39:29 mercurio mimedefang[23955]: l274d3Y4024399:
Unknown
command '^W' in RESULTS file
Mar  7 01:39:29 mercurio mimedefang[23955]: l274d3Y4024399:
RESULTS file
did not finish with 'F' line: Tempfailing
Mar  7 01:39:29 mercurio mimedefang[23955]: l274d3Y4024399:
Filter time
is 10108ms
Mar  7 01:39:29 mercurio sendmail[24399]: l274d3Y4024399:
Milter: data,
reject=451 4.3.2 Please try again later
...
Mar  7 01:39:30 mercurio mimedefang.pl[23996]: nss_ldap:
reconnecting to
LDAP server...
Mar  7 01:39:30 mercurio mimedefang.pl[23996]: nss_ldap:
reconnected to
LDAP server after 1 attempt(s)

I have space
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda1             110G   96G   15G  87% /
none                  128M  4.0K  128M   1% /tmp
none                  512M   19M  494M   4%
/var/spool/MIMEDefang

I have inodes
Filesystem            Inodes   IUsed   IFree IUse% Mounted
on
/dev/hda1                  0       0       0    -  /
none                  220897       9  220888    1% /tmp
none                  220897    2434  218463    2%
/var/spool/MIMEDefang

and I have memory
              total       used       free     shared   
buffers     cached
Mem:       3725376    2427652    1297724          0    
364796    1218124
-/+ buffers/cache:     844732    2880644
Swap:      2096472          0    2096472

I am running the last version of Sendmail (8.14.0), of
MIMEDefang (2.61)
and SpamAssasin (3.1.8)

I am running nscd and it is caching

nscd configuration:

               0  server debug level
         25m 11s  server runtime
               0  number of times clients had to wait

passwd cache:

             yes  cache is enabled
            5003  suggested size
          500000  seconds time to live for positive entries
              20  seconds time to live for negative entries
            5073  cache hits on positive entries
              33  cache hits on negative entries
              10  cache misses on positive entries
              10  cache misses on negative entries
              99% cache hit rate
              24  current number of cached values
              24  maximum number of cached values
               1  maximum chain length searched
               0  number of delays on rdlock
               0  number of delays on wrlock
             yes  check /etc/passwd for changes

group cache:

             yes  cache is enabled
            5003  suggested size
          500000  seconds time to live for positive entries
              60  seconds time to live for negative entries
               7  cache hits on positive entries
               0  cache hits on negative entries
               2  cache misses on positive entries
               3  cache misses on negative entries
              58% cache hit rate
               7  current number of cached values
               7  maximum number of cached values
               1  maximum chain length searched
               0  number of delays on rdlock
               0  number of delays on wrlock
             yes  check /etc/group for changes

hosts cache:

             yes  cache is enabled
            5003  suggested size
         1000000  seconds time to live for positive entries
              20  seconds time to live for negative entries
            3851  cache hits on positive entries
              24  cache hits on negative entries
             103  cache misses on positive entries
             131  cache misses on negative entries
              94% cache hit rate
             715  current number of cached values
             719  maximum number of cached values
               4  maximum chain length searched
               0  number of delays on rdlock
               0  number of delays on wrlock
             yes  check /etc/hosts for changes

Eduardo.-

_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in
the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpengu
in.com
MIMEDefang mailing list MIMEDefanglists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mime
defang

Josh Kelley wrote:
> 
> To avoid this problem, we eventually disabled embedded
Perl.  Are you
> running with embedded Perl enabled in Mimedefang?

Yes, I will try without embedded Perl. Are there any
performance 
degradation with this type of operation?

Thnak you,
		Eduardo.-
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in
the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpengu
in.com
MIMEDefang mailing list MIMEDefanglists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mime
defang

On 3/7/07, David F. Skoll <dfsroaringpenguin.com>
wrote:
> I can't see how embedded Perl could cause this.  The
RESULTS file is
> opened in the MIMEDefang slave long after the fork and
all file descriptors
> have been closed.  I could be wrong, but I just don't
see it.

As a hypothetical example, the nss_ldap libraries which are
loaded by
Mimedefang and SpamAssassin would open FD 3 as a connection
to an LDAP
server and leave it open for performance, then Mimedefang
would close
FD 3 when forking and reopen it as an output handle to
RESULTS.  So
the next name lookup call would invoke nss_ldap, which would
write out
LDAP commands to FD 3, and Mimedefang would see the LDAP
data in the
RESULTS file and error out.

I did enough investigating to convince myself that
_something_ like
this was happening, but I never figured out the exact
circumstances.
On my system, at least, it didn't happen very often, and it
was highly
dependent on whether or not nscd was running (maybe because
nscd opens
the LDAP connections if it's running, or maybe because an
open FD to
nscd's socket is also involved).

Without embedded Perl, SpamAssassin doesn't initialize until
after the
fork, so no FDs are opened then forced closed.

Josh Kelley
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in
the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpengu
in.com
MIMEDefang mailing list MIMEDefanglists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mime
defang

On 3/7/07, Eduardo A. Suarez <esuarezfcaglp.fcaglp.unlp.edu.ar> wrote:
> Josh Kelley wrote:
> >
> > To avoid this problem, we eventually disabled
embedded Perl.  Are you
> > running with embedded Perl enabled in Mimedefang?
>
> Yes, I will try without embedded Perl. Are there any
performance
> degradation with this type of operation?

Embedded Perl saves memory, since parts of the Perl
interpreter can be
shared between the slaves, and it can let slaves initialize
a bit
faster (since the parent process only has to initialize
once),
although that should happen rarely enough that it's probably
not too
noticeable.

David F. Skoll has reported that embedded Perl probably may
not
actually help memory that much, since Perl's reference
counting method
of garbage collection ends up touching almost every page of
memory,
requiring each slave to have its own copy of the data
anyway.

Josh Kelley
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in
the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpengu
in.com
MIMEDefang mailing list MIMEDefanglists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mime
defang

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 7 Mar 2007, David F. Skoll wrote:

>> As a hypothetical example, the nss_ldap libraries
which are loaded by
>> Mimedefang and SpamAssassin would open FD 3 as a
connection to an LDAP


> I know there *are* evil Perl modules that open (and
keep open) file
> descriptors just by virtue of being "use"d. 
There are two approaches
> to dealing with them:

I don't know if this is related, but as nss_ldap is
mentioned in 
conjunction of fd-mock-up, there is this bug in
libnss_ldap:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=
154314

Bye,

- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBRe/Lp+gJIbZtwg6XAQJwiwf/aFoxSSREjemeMuG5pvoH9XZ1IL2r
ZT2m
BKd29TtjnPII3CRxp/8SVl7VoHM7w9hI8s6Ge2pevcRJbyIWd8dyBWt7ZPA9
sFLc
hVXvTYoGM9IZFUpibW/SazX3TsQyGwhp8xEyZTO+v4Vhl5rGhwXE6+whsLxK
A45X
+4nFhN66M6Go2ukQS05MZ/jf1xDgUcjJtgyRMg6Dk92zjGDHOf7Jf2bceR/s
Ss3y
ZgPPeVL1+9HnDtx35MaqqqfKwYv//B94CQGZdt47BPY7cfV+HPUs42LCq/fk
lk1b
iyAv6BB2JbvkAeXHRog/55vEo4zIyMC1ofzIttH8TCtgLLvzKz90Yw==
=TBgl
-----END PGP SIGNATURE-----
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in
the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpengu
in.com
MIMEDefang mailing list MIMEDefanglists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mime
defang

On 3/8/07, Steffen Kaiser <skmimedefangsmail.inf.fh-bonn-rhein-sieg.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 7 Mar 2007, David F. Skoll wrote:
>
> >> As a hypothetical example, the nss_ldap
libraries which are loaded by
> >> Mimedefang and SpamAssassin would open FD 3 as
a connection to an LDAP
>
>
> > I know there *are* evil Perl modules that open
(and keep open) file
> > descriptors just by virtue of being
"use"d.  There are two approaches
> > to dealing with them:
>
> I don't know if this is related, but as nss_ldap is
mentioned in
> conjunction of fd-mock-up, there is this bug in
libnss_ldap:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=
154314

That sounds exactly like some of the issues I've been
seeing.  Thanks
for the link; I appreciate it.

And sorry for failing to notice the
initialization-outside-of-filter_initialize issue before;
I've
scrupulously avoided that for my own code, but this was code
I'd
copied from somewhere else, and that plus the fact that the
problems
were apparently caused by libraries called by SpamAssassin,
rather
than SpamAssassin itself, kept me from ever realizing my
mistake.
*sigh*

Josh Kelley
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in
the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpengu
in.com
MIMEDefang mailing list MIMEDefanglists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mime
defang