Press "Enter" to skip to content

Tag: exim

Techy: Removing an rate limit block from Exim

During testing/investigation of an issue, I had to send “bad emails” to my Exim based mail server which after a number of attempts blocked me using the rate limit that had been configured:

451-The server has reached its limit for processing requests from your host.
451 Please try again later.

I didn’t want to wait for over an hour for the block to clear so I had to find out how to clear the block manually. On the mail server, I found the Exim data files in /var/spool/exim/db and using the exim_dumpdb tool to view the “ratelimit” block list:

# exim_dumpdb /var/spool/exim/ ratelimit

and then limiting it to the sending IP address (which I had checked via /var/log/exim_rejectlog ):

# exim_dumpdb /var/spool/exim/ ratelimit | grep 2001:db8:9:a::
28-Oct-2022 16:50:01.247104 rate:      1.877 key: 1h/per_mail/2001:db8:9:a::
28-Oct-2022 16:50:14.986765 rate:      1.937 key: 1h/per_conn//2001:db8:9:a::

Okay, that’s confirmed the block – but now to remove it. To do this, I had to use the “practically no documentation and no ui” tool exim_fixdb :

exim_fixdb /var/spool/exim/ ratelimit

It then just showed a prompt “>” with no instructions. But if the “key” was provided:

# exim_fixdb /var/spool/exim/ ratelimit
Modifying Exim hints database /var/spool/exim//db/ratelimit
> 1h/per_mail/2001:db8:9:a::
28-Oct-2022 16:50:01
0 time stamp: 28-Oct-2022 16:50:01
1 fract. time: .247104
2 sender rate: 1.877

Pressing “d” then deleted that record (and I repeated it for the other entry). Once I had finished, I just used “q” to quit exim_fixdb.

Hope it helps!

Bug Report: [Known Issue] Memset: Inbound port 587 blocked on IPv6

In an effort to prove to myself that I am actually trying to do work this month, I’m making a note of all the bugs in 3rd party software I find.

Today is a bug reported to Memset Ltd (part of iomart Group plc) on the 20th June 2022 under their ticket id 871251564 which caused me to waste a day diagnosing the problem – as I was blaming my server configuration after changing a setting and then verifying it.

The conclusion was that today, 28th June 2022, the server hosting my blog was down for around an hour whilst it was migrated to a new datacenter. I then had to spend the rest of the day confirming settings, resetting the firewall (iomart’s firewall configuration suite is no where as good as Memset’s), checking settings, resetting the IPv6 address on all sites (turns out cPanel hasn’t got a nice way of doing this) and then updating all the SPF mail server records. What fun!