E-Mail Rejected by Disroot?

One of my contacts complained his e-mail getting rejected by Disroot. Here’s the error he received:

SMTP error from remote server for RCPT TO command, host: [redacted] (IP_ADDRESS) reason: 554 5.7.1 Service unavailable; Client host [redacted] blocked using bl.spamcop.net; Blocked - see https://www.spamcop.net/bl…

For what reason did his mail get rejected? Any way to manually whitelist him on my end?


@muppeth in XMPP group said that the block targets client (so user) IP. His IP / IP range was abused, hence getting blocked.

@stardust in XMPP group said that it’s hard to say what caused the blocking without seeing full messages with header. And to check that, open the message source and check every IPs.

I followed @stardust step and found the only IPs in message source are those:

* Received: from localhost (localhost [127.0.0.1])

* Received: from knopi.disroot.org ([127.0.0.1])

* Received: from mout-xforward.gmx.net (mout-xforward.gmx.net [82.165.159.41])

Since only one actual IP is in there and it’s mentioning gmx, I believe this is gmx provider’s IP rather than user IP, hence gmx provider as a whole being blocked by Disroot.

@muppeth mentioned that Disroot strips client IPs upon receives, regardless if it’s in or out, hence why one can’t see client IPs in message header.


Here’s a paragraph from SpamCop’s page:

We recommend that when using any spam filtering method, users be given access to the filtered mail - don’t block the mail as documented here, but store it in a separate mailbox. Or tag it and provide users documentation so that they can filter based on the tags in their own MUA. We provide this information only for administrators who cannot use a more subtle approach for whatever reason.

Which means usually it should be sent to junk folder, and/or make it user configurable so one can manually whitelist a sender. But I don’t think I saw anything like that in Disroot webmail.

Thanks for report. Just to repost the conclusion from our chat. You’re right that we should be less restrictive on dleaing with blocked IPs (initially this was put in place when dealing with enormous amount of spam), and give user the possibility to decide what to do with the email. I have created issue on our project board so you can follow the progress of it there.

1 Like