Author: W B Hacker Date: To: exim users Subject: Re: [exim] Spam filtering in external application
lists@??? wrote: > Hi
>
> I want to use spam filtering on my exim 4.69 installation.
> On various sites I found configs for a transport like this:
>
> dspam_spamcheck:
> driver = pipe
> command = "/usr/sbin/exim -oMr spam-scanned -bS"
> transport_filter = "/opt/dspam/bin/dspam --stdout
> --deliver=innocent,spam --user $local_part@$domain"
> use_bsmtp = true
> home_directory = "/tmp"
> current_directory = "/tmp"
> user = nobody
> group = mail
> log_output = true
> return_fail_output = true
> return_path_add = false
> message_prefix =
> message_suffix =
>
>
> With this config a message is given to the external application and the
> output is reinjected into exim with a different protocol (spam-scanned in
> this case).
> In the router section this can be checked with {eq
> {$received_protocol}{spam-scanned}}.
>
> This method works, but I don't like that the message is run twice through
> exim. I get two complete deliveries in the logfiles and I can't match them
> because they have two different message ids. And I think the performance of
> two complete message runs isn't good either.
>
> I tried using the transport_filter directly without this reinjection:
> E.g.
>
> remote_smtp:
> driver = smtp
> transport_filter = "/usr/bin/dspam --stdout --deliver=innocent,spam
> --user global --debug"
>
> Looks like this method works too. Is there a reason why this method is
> inferior to the one above?
> Is this the "right way" to do this or is there a better one?
'Better' for most Exim users is to do all possible vetting, testing, and
filtering with acl's during the live smtp session, (no bounce needed) AND NOT
after the connection has been closed.
As Exim is really, really good at this, most of us who might previously have
used post-session milters, filters, etc with OTHER MTA, consider
router/transport set filtering to be 'too late'.
>
> It is not possible to change the message body in a router and pass the
> modified body on to the next router, right? (like unseen with modifying the
> body)
>
'challenging' exercise, that, and usually more pain than gain.
Instead - have another look at Exim's ability to do all manner of things - plus
invoke external scripts, binaries, and SQL actions - BEFORE getting as far as
routers - eg while the smtp session is still live. ISTR that dspam HAS been so
invoked, and in a manner similar to SpamAssassin's DATA phase integration, and
that the methodology was posted to this list (two years or so ago?).
One can still do a great many clever things in the router/transport chains, but
hopefully will have avoided those - spam filtering especially - that might give
rise to an otherwise-avoidable post-smtp-session bounce.
