Re: Unknown command '^W' in RESULTS file

Josh Kelley 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
> 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.

Got it.  That's why if you use embedded Perl, you should do
your
initialization in filter_initialize instead of just in the
body
of the filter.  The friendly mimedefang-filter man page
even
warns about this:

  "If you use any code that opens a descriptor (for
example, a
   connection to a database server), you must run that code
inside
   filter_initialize and not directly from the filter,
because the
   multiplexor closes all open descriptors when it activates
a new slave."

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:

1) Use them in an eval {} in filter_initialize

2) Complain bitterly to the module author until s/he fixes
the module.

Regards,

David.
_______________________________________________
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