Content

Introductory

When conducting electronic correspondence, mail servers strive to filter out unsolicited mail (spam) as efficiently as possible. From time to time it happens that these spam filtering services get blocked by letters that do not contain anything that would justify this. Therefore, it may happen with us that we cannot send an email to a recipient, or that we cannot receive mail from others on our own server. In this description, we will investigate one of the more common server-side "554 5.7.1 Service unavailable; Client host blocked using zen.spamhaus.org; Error: open resolver;" type error.

The symptom

LAMP or for example ISPConfigEmails sent to email addresses operating on our server bounce back to the sender, so, for example, test emails sent by ourselves also bounce back to us. In this case, we can see one of the following error messages:

Bounced mail for Gmail account

If a letter is sent from a Gmail email address to our account in question, the sender will receive a message like this from our server (of course, the HTML letter template itself with the small icon is already compiled by Gmail based on the error message):

554 5.7.1 Service unavailable; Client host [209.85.128.44] blocked using zen.spamhaus.org; Error: open resolver; https://www.spamhaus.org/returnc/pub/172.68.225.58

Bounced mail for other accounts

And if they try to send a letter not from a Gmail address to one of the mailboxes operated on our server, but from another account (in this example, from another simple self-hosted address), then the sender receives a message like this in the bounced mail:

This is the mail system at host szerver.linuxportal.info.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<címzett email címe>: host mail.cimzett_mailszervere.hu[xxx.xxx.xxx.xxx] said: 554
    5.7.1 Service unavailable; Client host [yyy.yyy.yyy.yyy] blocked using
    zen.spamhaus.org; Error: open resolver;
    https://www.spamhaus.org/returnc/pub/zzz.zzz.zzz.zzz (in reply to RCPT TO
    command)

Which contains the recipient's email address, mail server IP addresses (ie our server's IP address), the server returned "554.5.7.1 Service unavailable;" error code, IP address of the sender, etc.

So if our server returns a similar letter to the sender, which contains the error code "554.5.7.1", then we are in the right place, we will immediately look at the cause and solution of the error.

The reason of the error

The error is caused by an uncomplicated, but even more troublesome phenomenon. At first, one would think that the sender's IP address was blacklisted by some spam filtering service (for example, it accidentally caught an "unlucky" dynamic IP address, etc.), which may seem logical, since apparently the sender receives this error message after a bounce in a letter that contains some Spamhaus name...

However, there is a big twist in this error, as the error message is not specifically received by the sender of the letter, but by our mail server. If we look at the time of sending such a letter /var/log/mail.log in pain for example a tail command:

tail -f /var/log/mail.log

Then at the moment of sending the letter - or, from the point of view of our server, receiving the letter - we can see something similar to the following:

Aug  3 10:15:40 mail01 postfix/smtpd[23645]: NOQUEUE: reject: RCPT from sender.example.com[xx.xx.xx.xx]: 554 5.7.1 Service unavailable; Client host [xx.xx.xx.xx] blocked using zen.spamhaus.org; Error: open resolver; https://www.spamhaus.org/returnc/pub/162.158.148.77; from=<sender@example.com> to=<recipient@example.com> proto=ESMTP helo=<icinga2.infiniroot.net>

The meaning of the error message is as follows:

The "open resolver" error indicates that our mail server is an open DNS uses a server for name resolution. An open resolver is a DNS server that allows DNS requests sent by third parties to be forwarded to other servers, thus such DNS servers increase the security risk of networks because these servers can more easily be used to redirect DNS traffic , to send spam mails, etc.

Spamhaus.org is one of the most popular DNSBL (DNS-based BlackList) organizations, whose service includes all IP addresses that were once blocked by the Spamhaus system because they were connected to some spam sending service. IP addresses are then automatically blacklisted if spam activity is detected in relation to them.

When a mail server receives a mail, it first checks the IP address of the sender of the mail to check its authenticity, whether it is on these spam lists, etc. Accordingly, when a mail arrives at our mail server, it sends a query to this Spamhaus.org organization to query the spam involvement of the sender's IP address. However, since our server uses an open DNS service, Spamhaus a denied by our server delivery of spam information, so our mail server receives this error message. After that, our mail server classifies this received information (error message) as invalid, so it bounces the message back to the sender, forwarding it with the error message received by Spamhaus, because it did not receive a satisfactory response from Spamhaus regarding the requested IP address, so it cannot judge , whether the sender's IP address was involved in any previous spam activity.

So, in essence, this error message is not received by the sender of the letter, but by our mail server, which our server then considers to be an error and refuses to deliver the letter and throws the letter back to the sender, who also receives this error message.

In our case, in this case the Postfix (Mail Transfer Agent) The configuration of our mail sending and forwarding server includes the Spamhaus.org service as a spam control implementation, so the mails get stuck at Postfix in this case, since Postfix in this case is configured to receive incoming mail, and only various mail filters forwards the mails to our POP3/IMAP server - if it has not found anything suspicious in them.

Possible solutions

There are several possible solutions to this problem, here are some of them:

We avoid using open DNS servers

We must use an open DNS server if we do not operate the DNS service on our own server, but, for example, the name servers on the domain name we left it set at the registrar, and on the registrar's interface we set the DNS zone for our domain name, from which we redirect our www and other subdomains separately with "A" records, and the mail server with "MX" records. In such cases, correspondence takes place on our own server, but name resolution is provided by the public DNS server offered by the registrar.

The advantage of an open DNS server:

The advantage of this is that we do not have to fiddle with the primary and secondary name servers, but the service provider provides them for free.

Disadvantages of an open DNS server:

Since a lot of people besides us use these DNS servers, based on the law of large numbers, someone's mail can quickly be blocked by a Spamhaus spam filter service, and then everyone gets the same error when the IP address is blocked. Here, therefore, there is a certain "common horse..." effect. Here, it is enough if someone has a website that is poorly protected and, for example, spam is being removed through one of their contact forms. But it is enough if, for example, someone has a poorly assembled one PHP mail goes out with an incorrect header, and in this case the IP address of the DNS server is blacklisted, and mail reception stops for everyone who has it configured similarly. In the worst case, if we want to send it to others, even the spam filter service used on the other side can block our emails.

What is the solution to this?

Let's use our own DNS server on our own server! Of course, in the case of a LAMP server, this is more complicated to configure manually, so if you don't want to fiddle with something like that, then let's jump to the next possible solution.

However, if, for example, we have an ISPConfig server configuration where everything was set during installation, in this case we can learn from the following tutorials how to use our own name server and how to access a secondary name server:

• How to set up a secondary name server if you only have one IP address
• How to build and provision our ISPConfig3 server ... - Create a DNS zone and set records

In this case, everything takes place on our own server, including correspondence and name resolution, as well as our domain name SOA record we will have it too. I use this method as well, I haven't had any problems with it.

Disable the Spamhaus.org spam filtering service (not recommended)

Another possible solution, which I am reluctant to recommend, but if we can't solve it in any other way, is to disable the Spamhaus spam filtering service in Postfix. If we choose this, we will no longer have spam filtering, so our server will be more exposed to the risk of attacks by spammers. So we should really only do this if the above solution is not a feasible way for us. Remember, our server is constantly exposed to various attacks, of which the SMTP server is the most common type of attack!

For that, let's open it rootas a /etc/postfix/main.cf file:

nano /etc/postfix/main.cf

Then find the following line:

smtpd_client_restrictions = check_client_access proxy:mysql:/etc/postfix/mysql-virtual_client.cf, permit_inet_interfaces, permit_mynetworks, permit_sasl_authenticated, reject_rbl_client zen.spamhaus.org, reject_unauth_pipelining , permit

This is a simple value given as a comma-separated enumeration. Remove the part highlighted in red from this list, then save it. Here, make sure to include a comma with the highlighted part, so you don't leave a syntax error in the file.

Then restart postfix:

systemctl restart postfix

Spamhaus data retrieval service with MTA

If there is no way we can resolve not to use public name servers, then Spamhaus also offers a data request service: "Data Query Service using an MTA".

The essence of this is that with the help of the MTA (Mail Transfer Agent) operating on our server, such as Postfix, we can set up a free query service that also works when using public DNS servers. Although this service works with limited functionality, it still provides the basic Spamhaus spam filtering service.

To be honest, I haven't tried this yet, since I'm using the first solution, so I just ran through its documentation, which can be found here:

• docs.spamhaus.com/datasets/docs/source/40-real-world-usage/MTAs/000-intro.html

Thus, if you cannot avoid using an open DNS server and are in the mood to experiment, this solution may also be suitable for you.

Conclusion

These would be "554 5.7.1 Service unavailable; Client host blocked using zen.spamhaus.org; Error: open resolver;" type of error, should we encounter the exact same problem. All in all, it is advisable to avoid using public DNS servers, and instead try to ensure that all services work on our own server, so that our exposure to errors resulting from external factors, such as in the case of a DNS server shared by many, will be minimal. The IP address of our own server always remains unique, as only we use it, which means that it cannot be added to the list of any spam filter service, as long as we pay attention to the optimal and safe operation of our services.