richs@??? wrote:
> We're using MySQL to enforce load-balancer-compatible sending limits
> using the RCPT and DATA ACL's in Exim 4.69:
>
> acl_check_rcpt:
> drop condition = ${if > {${eval: $rcpt_count + ${lookup mysql{SELECT
> count FROM mailcount_$tod_logfile WHERE ip = '$sender_host_address'}}}}
> {1000} {yes}{no}}
> message = Message would exceed 1000 recipient limit for
> $sender_host_address
>
> acl_check_data:
> warn continue = ${lookup mysql{INSERT INTO mailcount_$tod_logfile (ip,
> count) VALUES('$sender_host_address', $rcpt_count) ON DUPLICATE KEY
> UPDATE count=count+VALUES(count);}}
>
> When MySQL is unavailable, the warn continue statement fails quietly and
> doesn't interrupt delivery. However, since the RCPT ACL uses a drop
> condition, all incoming mail is deferred when MySQL is down:
>
> 30625 lookup deferred: MYSQL connection failed: Can't connect to MySQL
> server on '192.168.X.X' (111)
> 30625 drop: condition test deferred
> 30625 SMTP>> 451 Temporary local problem - please try later
> 30625 LOG: MAIN REJECT
> 30625 H=(t) [127.0.0.1] F=<sender@???> temporarily rejected
> RCPT user@???: MYSQL connection failed: Can't connect to
> MySQL server on '192.168.X.X' (111)
> 30625 LOG: lost_incoming_connection MAIN
> 30625 SMTP command timeout on connection from (host) [SENDER.HOST.IP]
> 30625 SMTP>> 421 servername: SMTP command timeout - closing connection
>
> Is there any way to enable a "defer_ok" or equivalent functionality in
> this case?
>
> Thanks!
>
> Rich Sandberg
> richs@???
>
>
You might consider:
- stuffing a 'safe default' value into an acl variable before calling MySQL
- replacing that value if MySQL is responsive, ELSE NOT
- taking 'verb' acton on the value - which is either the MySQL call
result, OR the [safe | global] default / fallback.
Another way would be to use failure of the earliest SQL call (perhaps an
'are you there?' test) to set a flag that diverts to a complete
alternate set of tests that use defaults rather than the known-to-be
unavailable SQL results.
Either way - the test is not especially convoluted and neither the acl
nor SQL logic need be complex.
NB: With PostgreSQL we have to 'force' a failure to see if it triggers,
as PG otherwise has been run 'out of connections' during the odd DoS
attack, but otherwise has yet to fall down even once.
HTH,
Bill
