Listed in the Spamhaus Domain Block List (every other day)

Is there any known issue or mistake during installation I may have made with MiaB that might cause it to be added to the Spamhaus Domain Block List every other day?

Every day my Status Checks Change Notice email tells me I have either “:heavy_multiplication_x: This domain is listed in the Spamhaus Domain Block List (code 127.255.255.254), which may prevent recipients from receiving your mail.” or “✓ Domain is not blacklisted by dbl.spamhaus.org.”
No matter what I do seems to stop it. Any time I ever look on SpamHaus, it reports there is nothing wrong with that domain (or any other domain I host on my MiaB servers).

Thanks for any suggestions,
Keith.

I have been in the same IP address space for a very long time. That is, my own fixed IPs.
I have another email server running for the last 20 years; no issues.

According to spamhaus this return code means you are using a public resolver. How did you install Mail-in-a-Box? Are you not using the built-in DNS resolver?

It is on a Ubuntu server in my data rack behind my firewall. IP address for DNS is 9.9.9.9 for all my devices.
I have been getting worried that I have the firewall set up incorrectly because most of my email traffic from my other server shows the firewall as part of the path. Wondering if I need to put more effort into setting up a DMZ instead of what I have.

I thought that when you give the device an virtual IP alias (of the correct IP of course) in pfSense that eliminated the path issues of going through the firewall.

I am open to suggestions as to what I am likely doing wrong…please.

Keith.

Most blocklists like spamhaus function through DNS lookups. However, they usually set a limit to how often a DNS server can query their blocklist. Public servers like 9.9.9.9, go fast over such a limit, which is why it’s better to use your own DNS server. That’s why Mail-in-a-Box includes a recursive DNS server, bind9. My advice is that you use the default installation, and not change this bit.
I have no comment on your firewall, DMZ or virtual IP, because I know too little about that situation to add something.

1 Like

It was actually to support local DNSSEC lookups for DANE for mail delivery. I totally forgot that we need it for this reason too, which is good to know because I’m contemplating removing DNSSEC from future versions (to simplify things).

1 Like

Hi Josh. If you’re deciding if/not to retain DNSSEC, I’d prefer you left it in. It works well and (but who can be sure) I imagine it improves our not-spam score.

Perhaps just add a paragraph to the setup guide. explaining what DNS entries can be omitted, for those making use of someone else’s DNS server.

1 Like

I don’t think that’s true (i.e. I’ve never seen that to be the case as far as I can remember).

Because DNSSEC is barely implemented world-wide (as folks move toward CA-based trust like DNS-over-HTTPS), it seems like there’s almost no security (or other) value to DNSSEC.

1 Like

Thank you so very much! This solved the problem.

1 Like

It depends on the country. DNSSEC World Map
Please keep DNSSEC. 33.74% of DNSSEC are validated in my country and US is similar.

In my experience DNSSEC creates more problems than it solves. Granted 99% of these issues are human caused, but still…

I would support the decision to remove DNSSEC. If your domain is high value enough that DNS would be a vector for attack, you’re not going to be using MiaB in the first place.

This topic was automatically closed 40 days after the last reply. New replies are no longer allowed.