Re: [exim] Callout lockfile not writable

Inizio della pagina
Delete this message
Reply to this message
Autore: Morten W. Petersen
Data:  
To: exim-users
CC: Vinay Kumar, Vinay S Shastry, Ajay
Oggetto: Re: [exim] Callout lockfile not writable
Hi again,

I'll try a different tack here. Is it possible with Exim to hook it up
to some external
process or socket which can do the callout check?

I'm thinking of having some python-based daemon or script running which
can check the
recipient against an SQL database..

-Morten

Morten W. Petersen skrev:
> Hi,
>
> we have an Exim server configured to forward emails to another
> mail system (as a spam filtering system with Maia Mailguard (Amavis
> and Spamassassin)).
>
> We have a pretty standard Debian configuration setup for Exim,
> with the following alterations (These are most of the alterations
> we have):
>
> router/01_amavis:
>
> callout:
>         debug_print = "Initiating recipient callout to my mail host..."
>         driver = manualroute
>         verify_only
>         transport = recipient_callout
>         route_list = * mail.mailgateway.no byname
>         host_find_failed = defer

>
> amavis:
>         driver = manualroute
>         # Don't run (condition=0) if received from port 10025
>         # as message has already passed through amavis
>         condition = "${if eq {$interface_port}{10025} {0}{1}}"
>         transport = amavis
>         route_list = "* localhost byname"
>         self = send
>         no_more

>
> [EOF]
>
> acl/30_exim4-config_check_rcpt:
>
> [... lots of config ... ]
>
>   accept
>     domains = +relay_to_domains
>     endpass
>     message = unknown user
>     verify = recipient/callout=10s

>
>
> # At this point, the address has passed all the checks that have been
> # configured, so we accept it unconditionally.
>
> accept
>
> [EOF]
>
> In the Exim mainlog we can see these:
>
> 2009-08-06 11:08:23 Failed to get write lock for
> /var/spool/exim4/db/callout.lockfile: timed out
>
> On a regular basis, sometimes 10-15 seconds apart.
>
> And lsof reveals this:
>
> quicksilver:/var/spool# lsof|grep lockfile
> exim4 6659 Debian-exim 5uW REG 8,1 0 180348
> /var/spool/exim4/db/callout.lockfile
> exim4 7018 Debian-exim 4u REG 8,1 0 180348
> /var/spool/exim4/db/callout.lockfile
> exim4 7019 Debian-exim 4u REG 8,1 0 180348
> /var/spool/exim4/db/callout.lockfile
>
> When we ran lsof earlier, a lot more processes were also "attached" to
> the lockfile,
> but only one has the W (write lock for the entire file).
>
> This is a testing environment with very few emails going through
> (although spammers
> have already managed to figure out it deals with mail..)
>
> Any ideas?
>
> TIA,
>
> Morten
>
>



--
Morten W. Petersen
Manager
Nidelven IT Ltd

Phone: +47 45 44 00 69
Email: morten@???