Incoming emails blocked by RBL (Spamhaus) on

Hi, first off, thanks for getting this project together, been meaning to get my own Nextcloud instance together but time/money lacking, so this is great!

Ok so I was testing the email and sent a teat mail to my address from my own email server and it bounced:

<>: host[] said: 554 5.7.1 Service
    unavailable; Client host [] blocked using; (in reply to RCPT TO

So, OK you are using DNSBL/RBLs to attempt to limit spam. Trouble is the likes of Spamhaus/SORBS/RATSDyna basically block all dynamic IP ranges (i.e home internet connections) and there is not really anything anyone can do about it (apart from not send email from any banned IP range) and they also block IP ranges form VPS servers as lots of spam comes from hacked servers.

That’s pretty sucky as it “tars with the same brush” all users good/bad or otherwise due to the nefarious actions of the few…

I found on my personal email server that using RBLs resulted in blocked emails sent from Google servers to my mail server which was bad news when you miss an important email!

Reading around discussion forums on the subject it seems that using blocklists isn’t really the best solution to managing spam and also has negative impact on service. Of the major email service providers, I have only found Microsoft ( and Apple ( blocking emails due to DNSBL listing (boo-hoo! :stuck_out_tongue_closed_eyes:)

Since disabling RBL in my server, spam hasn’t significantly increased as the Spamassassin seems to be doing a pretty good job.

So basically my request is to re-consider your use of RBLs in order that emails form non-mainstream providers don’t get bounced.

And if we can use as MTA for our own domains, that might rock to the extreme! (especially as you have Rainloop by default (we’ll ignore the GPG limitations for now!)) :+1:

Yes indeed it is something we have been discussing some time ago already, but since we haven’t gotten any complaint (until now) it wasn’t on our priority list. Maybe it’s time to reconsider.

Prior to doing that we need to make sure our spamassasin is very well taught and we’ll need to put some extra monitoring on possible spam activity at least in the beginning to make sure we haven’t open flood-gates.
We have filled up tasks on our board until the end of the year so in case we don’t have spare time before, it will be put as a task in january.

I made an issue on our board (when the time comes it will be elevated to a Task)

Thanks for the quick response, this is not urgent for me, what impact this has on your current users is for you to find out. I only discovered the problem on my own server when I realised an expected email hadn’t arrived (non Google @ domain email but Google managed domain) by grepping the logs and noticing Google emails being blocked by the RBL.

Obviously blanket banning of Google sent emails is going to cause issues, and not all were being blocked.

Probably worth a quick check on your mailog to see if genuine mail is being blocked.

I was able to send from GMail without issue although Rainloop reports a red exclamation mark beside sender address due to:

Authentication-Results:; dkim=fail
	reason="verification failed; unprotected key" header.b=ll7FErkO;
	dkim-adsp=none (unprotected policy); dkim-atps=neutral

I don’t imagine Google has mal configured DKIM mail servers…but this is another minor issue…

I’m having the same issue. My IP got listed in Spamhaus PBL records because i use sendmail to send RSS feeds to my own email address, using rss2email.
I could configure rss2email to use the SMTP server to send emails but this would a) be slower and b) hammer the server when sending out ~100 RSS feeds as emails.
So, using sendmail seems like a reasonable approach but it’s identified as unauthenticated email, hence being on the PBL blacklist and being blocked by Disroot.

I’m watching issue #1201 and hope for a solution.

<>: host[] said: 554 5.7.1 Service
    unavailable; Client host [] blocked using; (in reply to RCPT TO

The Spamhaus Policy Block List (“PBL”) is an international anti-spam system maintained by The Spamhaus Project in conjunction with Internet Service Providers and is used by Internet networks to enforce inbound email policies. The PBL database lists end-user IP address ranges which should not be delivering unauthenticated email to any mail server except those provided for specifically for that customer’s use. The PBL lists only IP addresses (not domains or email addresses).

The first thing to know is: THE PBL IS NOT A BLACKLIST. You are not listed for spamming or for anything you have done. The PBL is simply a list of all of the world’s dynamic IP space, i.e: IP ranges normally assigned by ISPs to broadband customers routers/modems (DSL, DHCP, PPP, cable, dialup). It is perfectly normal for these IP addresses to be listed on the PBL. In fact all dynamic IP addresses in the world should be on the PBL. Even static IPs which do not send mail should be listed in the PBL.

PBL listings do not prevent you sending email unless your email program is not authenticating properly when it connects to your ISP or to your company’s mail server. This can happen if you have changed something in your email program’s settings, forgotten to turn on ‘SMTP Authentication’ or if you have switched ‘SMTP Authentication’ off by mistake.

If you are using a normal email program such as Outlook, Entourage, Thunderbird or Apple Mail and you are being blocked by a Spamhaus PBL listing when you try to send email, the reason is simply that YOU NEED TO TURN ON ‘SMTP AUTHENTICATION’ in your email program’s account settings. That will immediately solve the problem for you. See: How do I turn on SMTP Authentication?

Server admins who need help with SMTP AUTH can find lots of information for most servers such as Sendmail, Postfix, Exim, Qmail, Exchange, etc.

Disabling spamhaus would open flood gates of incoming spam we dont want to do. We have enough work fighting off outgoing spam (public service attracts lots of scum). The amount of spam that bounces off our server thanks to spamhaus its quite significant these days, and we seem to not have many false positives.

You can always either link your own domain to disroot email or drop as a line on support_|at| to get whitelisted.

(I’ve added this comment to the issue on taiga)

I absolutely agree with that reasoning because I also hate spam and want to kill it with fire.
I don’t own a domain but the whitelist option sounds good to me.

Anyway, it will depend on this support question, otherwise I’ll have to stay with a Roundcube account just for the RSS feeds and use Disroot for regular email.