W B Hacker wrote:
> 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
>
Thanks Bill, we did indeed fix this in a similar way, by using a "warn
set acl_m1" to set a variable with the SQL result, and then to use a
different value if that variable was null (from a bad query).
-Rich
