Another attempt, another issue

[hairy-dog]

I'm trying again, but still hitting snags. I think the port 587 bypass solved the 'no PTR' issue, but one client has reported issues sending email, which I have been able to replicate by using my mobile phone to send email (and failing).

My outgoing email is rejected, and the logwatch report says
--- Admin Policy Blocking ---
Blocked Host
31.94.32.149 1 times

in the Exim4 rejectlog, the entry is

2025-08-21 17:30:08 H=[31.94.32.149] I=[192.168.1.201]:587 rejected connection in "connect" ACL: Connect IP blacklisted at zen.dq.spamhaus.net.

Given that this is a perfectly normal dynamic IP address issued by a mobile network, I really don't want to block that sort of address from sending email using port 587.

Where is the setting that controls the spamhaus databases that are checked?

I have removed the zen.spamhaus.net file from the /srv/recipientaddress.com/config/blacklists directory. Is there somewhere else I should change it?

Can we bypass this check for connecting on port 587 as well as bypassing the ptr check? Would that be a better solution?

[pcollinson]

Sorry for the delay in replying, I've been somewhat busy.

First, the reason I started to put testing in the 'Connect ACL' was because I was deluged with people trying to brute force attack account and passwords. At this point in the mail sequence, all exim4 can see is the incoming IP address and the interface information like the IP and port number.

The per server files, like the one supplied by the zen.spamhaus.net file, operate much later in the SMTP sequence, actually when most of the information about the connection is known. When these tests are evaluated and people have logged in successfully, the dnsbl tests are skipped anyway, so putting them back will be OK.

Putting a test into the Connect ACL means that people who I don't know and are trying to get user ids and passwords are stopped without being given any knowledge about the validity of their attempts.

Removing it means that these people will attempt to login, and are turned away when the login fails. If they are legit, then their login will succeed and all the various security tests in the Connect ACL will be ignored.

Suggestion 1

So my first suggestion to fix your problem allows connections coming in with 587 to miss out on all the further tests in the Connect ACL, and relies on later tests made with more knowledge of the connection.

Create a file called 21-accept-587 containing:

# Always accept port 587
  accept condition = ${if eq{$interface_port} {587} }

Then copy this into /etc/exim4/sympl-local.d/10-acl/10-acl-check-connect. This places it before all the checks that are placed in the Connect ACL. You may need to sudo to do the cp and all the other commands below. Then rebuild and relaunch exim4:

cd /etc/exim4
make

I've tested this, exim4 is happy with it.

If a connection comes in on port 587, all further inbound checks in connect will be skipped. This may be fine for 'good' people using 587, but will not be for the bad guys. So I suggest that you re-instate the zen.spamhaus.net file so the bad guys will be sent away.

Suggestion 2

If you want to remove the DNSBL checks from the Connect ACL for all ports and leave the other checks in, you can remove the file that makes this happen. This will apply all the other checks.

    cd  /etc/exim4/sympl-local.d/10-acl/10-acl-check-connect
    rm 25-dnsbl-reject
    cd /etc/exim4 make

There may be a different number at the start of this file. Notice that it's 25--- so the new file above happens before it.

I recommend that you also re-instate the zen.spamhaus.net file .

Hope this assists.

[hairy-dog]

Thanks. That does help, though for now I have hacked it into running by putting the same condition
condition = ${if !eq{${received_port}}{587}}`
that you suggested for the RDNS check, into the two spamhaus sections.
That leaves the other checks running, which seems to be a workable compromise for now.
I've put the zen.spamhaus.net files back, as removing them didn't help anyway.
There has been a staggering increase in attempted logins in recent weeks. These checks seem to have dramatically reduced them.
It's not really a matter of avoiding stressing the server, but one of not making the logwatch reports get too huge to check over. A log that isn't looked at is a waste of disc space!