On Tue, 2004-11-02 at 08:00 +0100, Tore Anderson wrote:
> * 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.»
One thing I missed from your message was _at what point_ you want to
invoke perl routines / have access to the entire message. Generally, if
you want to run a routine for each recipient (e.g. in a user filter),
you have already accepted the message. Your options for dealing with
spam at this point are non-optimal (send a bounce, discard, freeze for
review, filter into a separate folder..).
A better way is to perform the filtering at SMTP time (i.e. in the Exim
ACL), and reject (550) or greylist (451) suspected spam. And yes, you
are right, this is normally done once per message, instead of once per
recipient. However, you do have some options:
* Force one recipient per message by deferring subsequent
recipients:
>
> 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
>
