[GH-ISSUE #1496] Private DNSBL listed in DNSBL check: dnsbl.cyberlogic.net #1176

Open
opened 2026-02-27 11:15:42 +03:00 by kerem · 18 comments
Owner

Originally created by @whyscream on GitHub (May 26, 2018).
Original GitHub issue: https://github.com/modoboa/modoboa/issues/1496

Impacted versions

  • Modoboa: git HEAD
  • Installer used: irrelevant
  • Webserver: irrelevant

Steps to reproduce

Look at email box, see that I have received various emails from the Modoboa MX checks about a DNSBL that is broken, badly maintained , irrelevant, and I never knew existed.

Current behavior

The list of DNSBLs defined at modoboa/admin/constants.py includes "dnsbl.cyberlogic.net", which is currently broken (see: https://www.dnsbl.com/2018/05/status-of-dnsblcyberlogicnet-broken.html). I never heard of this DNSBL, and the author of referenced article hasn't either. Based on his findings I'm assuming that this DNSBL was actually private.

Expected behavior

  1. I would not expect Modoboa to include such obscure DNSBLs by default, just a list of widely accepted and properly supported lists. Please remove the mentioned DNSBL from the modoboa defaults, and any other non-public DNSBLs too. For instance: cyberlogic doesn't have a website listed at https://www.dnsbl.info/dnsbl-details.php?dnsbl=dnsbl.cyberlogic.net, so performing manual lookups, reading about listing policy and/or getting a removal is a pain to say the least.
  2. Proper documentation on how to remove DNSBLs from the list. I now found out (by reading the code) that Modoboa actually has quite nice support for removing/customizing this list. I fixed my issue by adding the following snippet to my settings.py, but this should be available for anyone reading documentation.
# fix broken DNSBLs
from modoboa.admin.constants import DNSBL_PROVIDERS
DNSBL_PROVIDERS.remove("dnsbl.cyberlogic.net")
Originally created by @whyscream on GitHub (May 26, 2018). Original GitHub issue: https://github.com/modoboa/modoboa/issues/1496 # Impacted versions * Modoboa: git HEAD * Installer used: irrelevant * Webserver: irrelevant # Steps to reproduce Look at email box, see that I have received various emails from the Modoboa MX checks about a DNSBL that is broken, badly maintained , irrelevant, and I never knew existed. # Current behavior The list of DNSBLs defined at `modoboa/admin/constants.py` includes `"dnsbl.cyberlogic.net"`, which is currently broken (see: https://www.dnsbl.com/2018/05/status-of-dnsblcyberlogicnet-broken.html). I never heard of this DNSBL, and the author of referenced article hasn't either. Based on his findings I'm assuming that this DNSBL was actually private. # Expected behavior 1) I would not expect Modoboa to include such obscure DNSBLs by default, just a list of widely accepted and properly supported lists. Please remove the mentioned DNSBL from the modoboa defaults, and any other non-public DNSBLs too. For instance: cyberlogic doesn't have a website listed at https://www.dnsbl.info/dnsbl-details.php?dnsbl=dnsbl.cyberlogic.net, so performing manual lookups, reading about listing policy and/or getting a removal is a pain to say the least. 2) Proper documentation on how to remove DNSBLs from the list. I now found out (by reading the code) that Modoboa actually has quite nice support for removing/customizing this list. I fixed my issue by adding the following snippet to my `settings.py`, but this should be available for anyone reading documentation. ```python # fix broken DNSBLs from modoboa.admin.constants import DNSBL_PROVIDERS DNSBL_PROVIDERS.remove("dnsbl.cyberlogic.net") ````
Author
Owner

@oconshaw commented on GitHub (May 27, 2018):

Great find and thanks for posting a fix. I am having the same issue. Can you elaborate a bit more on how to apply the fix you detailed above? Where/how do you add that snippet to your "settings". --Thanks.

<!-- gh-comment-id:392351116 --> @oconshaw commented on GitHub (May 27, 2018): Great find and thanks for posting a fix. I am having the same issue. Can you elaborate a bit more on how to apply the fix you detailed above? Where/how do you add that snippet to your "settings". --Thanks.
Author
Owner

@whyscream commented on GitHub (May 28, 2018):

After installing, the Modoboa installation created a few files. One of them is named settings.py. you can append the lines to that file.

<!-- gh-comment-id:392444331 --> @whyscream commented on GitHub (May 28, 2018): After installing, the Modoboa installation created a few files. One of them is named `settings.py`. you can append the lines to that file.
Author
Owner

@almereyda commented on GitHub (May 29, 2018):

In our instance, provisioned by the modoboa-installer, the file is living in /srv/modoboa/instance/instance/settings.py.

A service uwsgi restart usually helps picking up those changes.

<!-- gh-comment-id:392738281 --> @almereyda commented on GitHub (May 29, 2018): In our instance, provisioned by the `modoboa-installer`, the file is living in `/srv/modoboa/instance/instance/settings.py`. A `service uwsgi restart` usually helps picking up those changes.
Author
Owner

@TacoScheltema commented on GitHub (May 30, 2018):

following up on this; bl.spamcannibal.org recently had it's domain name hijacked and is now serving up advertisements and malicious content. This blacklist should also be removed from modoboa.

<!-- gh-comment-id:393134691 --> @TacoScheltema commented on GitHub (May 30, 2018): following up on this; bl.spamcannibal.org recently had it's domain name hijacked and is now serving up advertisements and malicious content. This blacklist should also be removed from modoboa.
Author
Owner

@tonioo commented on GitHub (May 30, 2018):

You can indeed modify the DNSBL provider list as mentioned in the original description, or you can just add DNSBL_PROVIDERS variable to the config file, without the import statement (in this mode, you can only override the whole list).

Anyway, do you think an online panel to control the provider list would be useful? I could propose it through the sponsoring system.

<!-- gh-comment-id:393146820 --> @tonioo commented on GitHub (May 30, 2018): You can indeed modify the DNSBL provider list as mentioned in the original description, or you can just add ``DNSBL_PROVIDERS`` variable to the config file, without the import statement (in this mode, you can only override the whole list). Anyway, do you think an online panel to control the provider list would be useful? I could propose it through the sponsoring system.
Author
Owner

@TacoScheltema commented on GitHub (May 30, 2018):

@tonioo That would have my vote for sure!

<!-- gh-comment-id:393156237 --> @TacoScheltema commented on GitHub (May 30, 2018): @tonioo That would have my vote for sure!
Author
Owner

@PatTheMav commented on GitHub (Oct 17, 2018):

I'm not too sure, but looks like the same issue with sectoor.de, which according to the same page had been broken since June and is offline anyway: https://www.dnsbl.com/2018/06/status-of-exitnodestordnsblsectoorde.html

<!-- gh-comment-id:430744430 --> @PatTheMav commented on GitHub (Oct 17, 2018): I'm not too sure, but looks like the same issue with sectoor.de, which according to the same page had been broken since June and is offline anyway: https://www.dnsbl.com/2018/06/status-of-exitnodestordnsblsectoorde.html
Author
Owner

@tonioo commented on GitHub (Oct 18, 2018):

@PatTheMav Looks like only exitnodes.tor.dnsbl.sectoor.de is concerned. Modoboa does not use this list by default. Have you encountered issues?

<!-- gh-comment-id:430908811 --> @tonioo commented on GitHub (Oct 18, 2018): @PatTheMav Looks like only exitnodes.tor.dnsbl.sectoor.de is concerned. Modoboa does not use this list by default. Have you encountered issues?
Author
Owner

@PatTheMav commented on GitHub (Oct 18, 2018):

@tonioo Well, the "issue" would be that the IP of my brand new mail server was more or less immediately recognized as "listed" by sectoor.de (probably because they list whole IP ranges) and their website is offline, so there is no way to check or dispute.

In general I'd prefer to have a solid list of vendors be the default (mainly the big names that have earned their trust) and an optional list of the more obscure block list providers (that either go offline all of a sudden, get hacked, etc.).

<!-- gh-comment-id:430939673 --> @PatTheMav commented on GitHub (Oct 18, 2018): @tonioo Well, the "issue" would be that the IP of my brand new mail server was more or less immediately recognized as "listed" by sectoor.de (probably because they list whole IP ranges) and their website is offline, so there is no way to check or dispute. In general I'd prefer to have a solid list of vendors be the default (mainly the big names that have earned their trust) and an optional list of the more obscure block list providers (that either go offline all of a sudden, get hacked, etc.).
Author
Owner

@tonioo commented on GitHub (Oct 18, 2018):

@PatTheMav Good point but I'm really surprised you're the only one to report this issue. The list seems dead since June and I've never encountered any issue on my own server... Anyway, I'll drop the corresponding entries from the default providers.

<!-- gh-comment-id:430972329 --> @tonioo commented on GitHub (Oct 18, 2018): @PatTheMav Good point but I'm really surprised you're the only one to report this issue. The list seems dead since June and I've never encountered any issue on my own server... Anyway, I'll drop the corresponding entries from the default providers.
Author
Owner

@whyscream commented on GitHub (Oct 25, 2018):

I did a quick scan through the list of DNSBL_PROVIDERS in the master branch, but out of the first 10 or so entries, 3 lists are already dead (but cause no problems):

  • bl.deadbeef.com
  • bl.emailbasura.org
  • blackholes.five-ten-sg.com

Also cbl.abuseat.org is listed which is deprecated for a long time (since it's contained in Spamhaus Zen).

The commit that added the current list of domains is over 2 years old. In my opinion this is bitrot waiting to happen. So could we discuss the proposal again to limit the default list to a short list of known and respected big players?

<!-- gh-comment-id:433053835 --> @whyscream commented on GitHub (Oct 25, 2018): I did a quick scan through the list of DNSBL_PROVIDERS in the master branch, but out of the first 10 or so entries, 3 lists are already dead (but cause no problems): - `bl.deadbeef.com` - `bl.emailbasura.org` - `blackholes.five-ten-sg.com` Also `cbl.abuseat.org` is listed which is deprecated for a long time (since it's contained in Spamhaus Zen). The commit that added the current list of domains is over 2 years old. In my opinion this is bitrot waiting to happen. So could we discuss the proposal again to limit the default list to a short list of known and respected big players?
Author
Owner

@tonioo commented on GitHub (Oct 29, 2018):

@whyscream Sure. Do you already have a list in mind?

<!-- gh-comment-id:433906656 --> @tonioo commented on GitHub (Oct 29, 2018): @whyscream Sure. Do you already have a list in mind?
Author
Owner

@whyscream commented on GitHub (Oct 30, 2018):

My stance on DNSBLs is that you should only use those DNSBLs that have a clear listing policy (which is public), and getting removed from that list is also possible when you play by the rules of the DNSBL (meaning that those removal guide lines should also be public), as long as the DNSBL doesn't requires payment to be removed. Parties I trust on these are:

  • Spamhaus (zen.spamhaus.org)
  • Spamcop (bl.spamcop.net)
  • PSBL (psbl.surriel.com)
  • SEM (bl.spameatingmonkey.net)
  • Mailspike (bl.mailspike.net)

Many other DNSBLs fail to document why a server are listed, or how you can get it removed. This means in general that when your server is on such a list, you're not in a position to fix the problem. It has no use for Modoboa users to be notified of such a listing, because they can't overcome the issue anyway.

<!-- gh-comment-id:434136153 --> @whyscream commented on GitHub (Oct 30, 2018): My stance on DNSBLs is that you should only use those DNSBLs that have a clear listing policy (which is public), and getting removed from that list is also possible when you play by the rules of the DNSBL (meaning that those removal guide lines should also be public), as long as the DNSBL doesn't requires payment to be removed. Parties I trust on these are: - Spamhaus (zen.spamhaus.org) - Spamcop (bl.spamcop.net) - PSBL (psbl.surriel.com) - SEM (bl.spameatingmonkey.net) - Mailspike (bl.mailspike.net) Many other DNSBLs fail to document why a server are listed, or how you can get it removed. This means in general that when your server is on such a list, you're not in a position to fix the problem. It has no use for Modoboa users to be notified of such a listing, because they can't overcome the issue anyway.
Author
Owner

@whyscream commented on GitHub (Oct 30, 2018):

BTW it would be nice if proper documentation would eb in place on how to add DNSBLs to your setup that you do care about but is not in the default list. For instance lists that only target a specific country, or spam in a specific language.

<!-- gh-comment-id:434136442 --> @whyscream commented on GitHub (Oct 30, 2018): BTW it would be nice if proper documentation would eb in place on how to add DNSBLs to your setup that you do care about but is not in the default list. For instance lists that only target a specific country, or spam in a specific language.
Author
Owner

@PatTheMav commented on GitHub (Jun 14, 2019):

I noticed the psky.me false positive today as well. At this point I fully agree with @whyscream: By default modoboa should not tap into obscure, anonymous or otherwise sketchy DNSBL services and focus on the well-established providers that have active policies and removal processes.

<!-- gh-comment-id:502147699 --> @PatTheMav commented on GitHub (Jun 14, 2019): I noticed the psky.me false positive today as well. At this point I fully agree with @whyscream: By default modoboa should not tap into obscure, anonymous or otherwise sketchy DNSBL services and focus on the well-established providers that have active policies and removal processes.
Author
Owner

@ghost commented on GitHub (Oct 30, 2019):

bl.emailbasura.org started triggering false positives

<!-- gh-comment-id:548033060 --> @ghost commented on GitHub (Oct 30, 2019): `bl.emailbasura.org` started triggering false positives
Author
Owner

@jquiros2 commented on GitHub (Nov 7, 2019):

bl.emailbasura.org started triggering false positives

Just found this thread after realizeing this too. emailbasura.org looks pretty darn basura itself by the way.

<!-- gh-comment-id:551149223 --> @jquiros2 commented on GitHub (Nov 7, 2019): > `bl.emailbasura.org` started triggering false positives Just found this thread after realizeing this too. emailbasura.org looks pretty darn basura itself by the way.
Author
Owner

@ghost commented on GitHub (Nov 7, 2019):

i found https://poste.io/doc/getting-started (or https://github.com/dirtsimple/poste.io ) to be more actively developed, and less tiresome

<!-- gh-comment-id:551209419 --> @ghost commented on GitHub (Nov 7, 2019): i found https://poste.io/doc/getting-started (or https://github.com/dirtsimple/poste.io ) to be more actively developed, and less tiresome
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/modoboa-modoboa#1176
No description provided.