Re: [exim] More embedded Perl functionality

Top Page
Delete this message
Reply to this message
Author: Tore Anderson
Date:  
To: Peter Savitch
CC: exim-users
Subject: Re: [exim] More embedded Perl functionality
* Tore Anderson

> I'd like to be able to process the whole message
> inside the embedded Perl functions.


* Peter Savitch

> Exiscan + Spamassassin. SpamAssassin is a Perl solution with plug-in
> capabilities:


I'm aware of both, however Exiscan is limited by the fact that it runs
once per message, not once per delivery. This makes user-customizable
filtering impossible to implement in a decent manner, as one email may
have several recipients. So it is as its FAQ says: «You can't have
your cake and eat it too.»

SpamAssassin is Perl, correct, and that's exactly one of the reasons
why having the entire message text within Perl would be cool. You can
then just embed Mail::SpamAssassin directly within Exim, doing away
with any I/O-intensive double delivery kluge (for example an BSMTP pipe
to exim -bS plus transport_filter = spamassassin).

Having the entire message available somehow will also be useful in a
generic manner, whereas Exiscan only does spam and virus filtering.

> Miss again ;-) Pipe transport with Envelope-To header analysis will
> suit because Envelope-To header is added by Exim (and stripped by
> incoming logic to kill forgeries). That is, Envelope-To is a
> *trusted* header indicating *real* SMTP envelope recipient. Another
> lookup-driven verify router for checking over quota mailboxes for
> bounce avoidance. Your pipe exit code will aid Exim with
> success/fail/defer, etc.


I'm not really concerned about the authenticity of the Envelope-To:
header, I generally get that right anyway. And checking for quota
availability I tend to do directly in the RCPT TO ACL.

The reason I would like to see this functionality is merely that when
I already have a Perl interpreter bootstrapped and running within Exim,
it would be nice to avoid having to start another one.

So yes, what I'm asking for is something very similar to the pipe
transport, only that it should call an internal Perl subroutine instead
of an external executable. Return codes and so on could easily be
treated the same.

Kind regards,
--
Tore Anderson