[Exim] Exim 4 query: How about doing local_scan() in perl?

トップ ページ
このメッセージを削除
このメッセージに返信
著者: Kevin P. Fleming
日付:  
To: exim-users
題目: [Exim] Exim 4 query: How about doing local_scan() in perl?
I'm thinking about my ideal configuration for Exim 4, as I get ready to
migrate over. I currently use amavis for virus scanning, and would like to
use spamassassin for spam filtering. In addition, I'm considering some type
of scanning process that locates executable attachments and either bounces
the message(s) or removes those attachments.

With the current methods of using these tools, the messages leave Exim and
re-enter, possibly multiple times. It seems to me that it would be more
efficient to use something like Exim 4's local_scan() function to do these
things, however, I don't want to do them in C :-)

I'd like to use perl for these functions, but this leaves me with two
options:

1) implement a standard local_scan file that includes an embedded perl
interpreter, then use external perl scripts to do the work
2) use Exim's built-in embedded perl interpreter, and extend its use to
allow a local_scan function to be called (in addition to using "${perl"
constructs in string expansions)

Option 2 seems far more efficient to me, but there are couple of issues I'd
like to get answers to before I proceed down this road:

- Would Philip be willing to accept patches (tested, of course :-) to add
this functionality to Exim 4? I'm thinking this would be an additional
compile-time option, just like embedding perl is now. The local_scan
function would get passed some perl data structures (using Mail::Internet
and other existing modules) that contain all the message information.
- How often does Exim 4 exec() itself, instead of forking? Each time the
exec() is done, the perl interpreter gets recreated, reinitialized, and more
importantly, loses any "state" information that was present in the "master"
interpreter. With a fork(), the interpreter gets "copied", and still has
that state information. However, if Exim 4 only exec()'s itself at points
_after_ which the local_scan() function could ever be called, this is a
non-issue.

I'm more than willing to build this code, especially if there are others
willing to help test it. My current plan would be for this perl-based
local_scan function to pass the message contents to amavisd (eliminating the
need for the amavisc program), to pass it to spamc (eliminating the need for
the spamc program), and also deconstruct the message to look for executable
attachments (which is duplication of some of what amavisd is already
doing...).