Have you condisered the $run ?
${run{<command> <args>}{<string1>}{<string2>}}
The command and its arguments are first expanded separately, and then the
command is run in a separate process, but under the same uid and gid. As
in
other command executions from Exim, a shell is not used by default. If
you
want a shell, you must explicitly code it. If the command succeeds (gives
a
zero return code) <string1> is expanded and replaces the entire item;
during this expansion, the standard output from the command is in the
variable $value. If the command fails, <string2>, if present, is
expanded.
If it is absent, the result is empty. Alternatively, <string2> can be the
word 'fail' (not in braces) to force expansion failure if the command
does
not succeed. If both strings are omitted, the result is the standard
output
on success, and nothing on failure.
You can call this from an ACL and check the results. You could have 1 that
adds a "this person did a bad thing" and a second that checks to see "how
many bad things has this person done"
This expansion item can be used in ACL's & Routers etc.
-Andy-
-----Original Message-----
From: Wouter Verhelst [
mailto:w@uter.be]
Sent: 21 March 2007 20:15
To: John Hall
Cc: exim-users@???
Subject: Re: [exim] Running some code rather than having exim log stuff
On Wed, Mar 21, 2007 at 03:12:53PM +0000, John Hall wrote:
> On 21/03/07, Wouter Verhelst <w@???> wrote:
>
> > Sure enough, this is a spammer (the "gb30472" local part has never
> > existed at my domain; it's part of a mutt message-ID that is listed
> > on lists.debian.org). When this happens (a host disconnecting
> > without properly saying goodbye after giving an invalid local part),
> > I'd like to add them to a database so that I can use that as a data
> > point in further connection attempts; if they do a sufficient amount
> > of "bad things", I'll assume they're spammers and will block them.
>
> Wouter,
>
> I do something similar, but I have a separate process that tails the
> exim log file and maintains the database. Once a host has done a
> sufficient number of bad things it adds the IP to a list in a file
> which is referenced in the ACLs.
Yeah, I considered that too; but it's a bit more complex (requires me to
parse data in the mainlog file, chop it into useful bits, and throw that
into a database, rather than just incrementing an acl variable and running
some code when it reaches a certain value). Also, parsing a log file makes
it harder to drop a connection from my end if I consider them to be "bad"
during the connection (the unexpected disconnection would be just one data
point; there are more that I want to look for).
That's why I was hoping this'd be possible from the ACL itself. If it isn't,
I guess I'll have to bite the bullet.
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
