Back
therealpaulgg
Mar 11, 2024
5 min read

554 5.7.1 Service unavailable...Error: open resolver; - HUH?

Email server hell...when a spam service provider cuts you off 2 years late

I am now solidly a software engineer in my career, and so I mostly code and develop software. But I do still have a soft spot for IT work, although today it definitely frustrated me beyond belief. I found out years ago that the process of debugging software that some find painful was infinitely more enjoyable for me than wrestling with Linux server configuration (and YAML files. Screw YAML files.).

In my free time I do some freelance work - so a client wanted me to set up a email server for him (data privacy concerns, wanting his own stuff). Totally fine. I had set up email servers a few times before, and while configuring them is a pain, it's not THAT bad. Just a few hours and you've got your own email server up and running just fine.

Sure you might have to deal with the occasional issue of getting blocked or other servers thinking you're spam becuase you come from a certain subnet with lots of annoying bots, but that's usually intermittent and not a big deal (I still need to use a dedicated IP).

What happened today I did NOT ever expect to happen...it was completely ridiculous and unexpected.

What went wrong?

One day, any inbound emails to the email server just suddenly started getting rejected.

<example@example.com>: host mail.example.com[MAIL_SERVER_IP] said:
    554 5.7.1 Service unavailable; Client host [CLIENT_IP] blocked using
    sbl.spamhaus.org; Error: open resolver;
    https://check.spamhaus.org/returnc/pub/CLIENT_IP/ (in reply to RCPT TO
    command)

This was a little weird...so I began looking into it, trying to send and receive emails. Sending them was no problem, but no matter what email client I tried to send these emails were getting blocked.

"AI" Is No Help

As I've been doing a lot of problem solving using ChatGPT lately (code, software engineering, LLM applications), I decided, why not start with ChatGPT, it's probably way smarter than me, right?

It was completely clueless, and was trying to tell me that because it sees sbl.spamhaus.org, my mail server was on a blocklist. This was just simply not the case - and even if it was, it shouldn't be blocking inbound emails to this mailserver.

It seems like your mail server's IP address has been flagged by Spamhaus due to an "open resolver" issue. Open resolvers are DNS servers that are configured to accept queries from any IP address on the internet. This can be problematic because they can be used for DNS amplification attacks, a type of Distributed Denial of Service (DDoS) attack. This makes open resolvers a security concern, and hence, entities

I ask it a couple more queries, but I won't bother including them here as it really just was completely clueless to solving my issue.

Solving the Problem

I eventually go to the check.spamhaus.org page they linked and try to figure out what is going on...They basically just say there's a problem with the email server configuration, and that there is a link to fix the problem (which goes to a 404).

So I'm a bit confused at this point. I skim the page and don't really know what's going on - and just continue to google the issue.

I eventually stumble upon this link, and now that I'm reading it, it makes a lot of sense. But I was extremely confused - I never configured any kind of spam filtering on my email server, and everything was just being blocked.

In simple terms, Spamhaus in 2022 decided to prevent public DNS servers (CloudFlare, Google) from accessing their blocklists. I found a thread of users from this time trying to figure out what the issue was, and the problem was in their Postfix main.cf configuration:

smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination,reject_invalid_hostname,reject_non_fqdn_hostname,reject_non_fqdn_sender,reject_non_fqdn_recipient,reject_unknown_sender_domain, reject_rbl_client sbl.spamhaus.org,reject_rbl_client cbl.abuseat.org check_policy_service unix:private/policyd-spf

The solution they (and I) ended up using was just switching to spamrats instead of spamhaus. So effectively, I stripped out any reject_rbl_client references to spamhaus in the configuration.

Takeaways

Why did this start breaking in 2024? I can only assume that Spamhaus just decided to block whatever DNS server that this email server was using, as of a couple of days ago. Why they are around two years late to the party on this one, I do not know.

The only real takeaway that I have is that I am completely surprised that the default Postfix configuration (a couple years ago) was shipping with spamhaus hardcoded into the smtpd_recipient_restrictions block. As someone who doesn't really do email configuration on a frequent basis, finding this location was not as straightforward as I would have liked, and when I did find it, I was confused on if I should just rip it out or replace it with something else.

I only spent an hour of real work on this problem, but I am just so dumbfounded by this happening that I had to write this post. Maybe this will help someone else, lol.