Talk:Comparison of DNS blacklists

Latest comment: 2 years ago by Allyn in topic Noting issues with UCEPROTECT

NPOV dispute - Observe Caution edit

The tone of this section is clearly not neutral. While observing caution is a commendable quality, I don't think it has any place in this comparison article. There is already a DNSBL#Criticisms section which deals with issues people may have with the way DNSBLs operate. Specifically, I take issue with statements such as "...blacklists were established by angry victims..." and "...take everything with a grain of salt". I believe the entire section could be removed, as the DNSBL page already deals with these issues appropriately. Samuli64 (talk) 06:03, 10 August 2012 (UTC)Reply


The above is correct. The tone and wording is belligerent at best. Worse, the "references" are utter garbage.

  1. 13 is relevant to the claim, but is a forum posting.
  2. 14 and #15 are listed as proof of the author's claim that a defunct database that returns a fail to all requests is somehow 'damaging' to a server. Both links reference the company's statements about how/why the database is returning "blacklist all," but do not support the claim of damaging servers.

The section could stay, but should be a NPOV of (perhaps) suggested best-practices, rather than a weasel-worded diatribe.

Expanding the list edit

Does anyone have any specific suggestions for expanding this list? Doesn't look that bad to me, and I couldn't find any mention of it at the 'articles for expansion' page. Wesley 19:05, 23 April 2007 (UTC)Reply

I think the tag is OK. If someone knows a list (not his/her own, WP:COI) adding them to the list would be nice. Erik Warmelink 14:04, 3 June 2007 (UTC)Reply
The ISP homemail.com.au a.k.a grapevine.com.au apparently uses "the respected blackholes.wirehub.net RBL check server". I can find very few references to them on Google, and none on Wikipedia. Quite secretive, maybe they want to avoid Denial Of Service attacks by spammers? Anyone know more about them? —Preceding unsigned comment added by LimitedNews (talkcontribs) 01:19, 18 June 2008 (UTC)Reply

Consider adding MSRBL, if it is still alive. See also, the MSRBL blog — Preceding unsigned comment added by 81.100.41.202 (talk) 16:40, 7 November 2017 (UTC)Reply

Also, there are a few more DNS lists to consider on the INPS black list performance comparison site.

stats.dnsbl.com edit

The operator of that site seems to be quite forgiving for sloppy mailers (from How the data is compiled):

  • This include may include some amount of backscatter. As best I can, I have set up filtering rules to eliminate backscatter and outscatter. However, there are so many different kinds that it’s difficult to programmatically prevent them from slipping into the spam feed.

    In my opinion, backscatter is spam, it is unsolicited bulk e-mail.
  • Some mail is double opt-in (confirmed opt-in), and some is not.

    A mail source sending to N addresses which opted-in themselves and many more addresses which were "opted-in" by others (even if harvested by the sender), will still be considered ham.
  • Senders that misuse addresses are removed from this feed and lose their “ham” status. However, since I did legitimately give them an address, I don’t usually redirect them into the “spam” feed.

    After unsubscribing, it would be spam (especially when considering the previous point).

All that said, the worst part is that the site doesn't consider one-to-few e-mail at all. It only considers marketing lists and no one-to-few e-mail at all. Erik Warmelink 14:04, 3 June 2007 (UTC)Reply

Only the ham data is suspect edit

It should be noted that the only issue with stats.dnsbl.com's data is the ham count. I think the site is still one of the most valuable ones out there because it very clearly and concisely displays a listing of spam-catching accuracy by percentage. Stats.dnsbl.com introduced me to psbl.surriel.com and for that I am extremely happy. Using psbl + spamhaus + spamcop has made me a very happy camper, even though psbl is the lightest-weight of the lot (I report to spamcop, so it picks up more for me than for read-only users). I only know of one other reference (SDSC) that has this kind of data, and it's not as presentable (no percentages, presented in three tables, and the total counts include ham). Adam KatzΔtalk 21:50, 6 February 2009 (UTC)Reply

dsbl.org edit

It looks like dsbl isn't going to come back so perhaps should be removed from the list - they state:

DSBL is GONE and highly unlikely to return. Please remove it from your mail server configuration.

Commercial Lists? edit

Should commercial block lists be added directly into the current table, or separated onto a separate table/page? Mtcooper (talk) 12:19, 24 November 2008 (UTC)Reply

Best Settings? edit

Has anyone found any particular combination of SPAM checks to be particularly effective? —Preceding unsigned comment added by 209.12.74.218 (talk) 20:10, 25 March 2010 (UTC)Reply

See above comment by Adam_Katz. I concur - though I just use spamhaus then PSBL 136.186.72.46 (talk) 01:39, 1 June 2010 (UTC)Reply

Whitelists? edit

This desperately needs a whitelist table as well.

People using these things may not be aware that they can use other DNS whitelists to help avoid some of the collateral-damage and other "mail loss side effects" by augmenting their protection with whitelists. 120.151.160.158 (talk) 13:36, 29 April 2012 (UTC)Reply

ORBITrbl offline/defunct edit

ORBITrbl has been discontinued, so it should be removed from the list of RBLs. As of (approximatly) 2014-11-17 14:20 UTC all RBL queries to ORBITrbl return a negative result (indicating "service unavailable"). I believe this is so that anyone attempting to use ORBITrbl will turn it off (lest their incoming mail be effectively blocked).

Source: My mail logs and Blog post by Mark E. Jeftovic <markjr () easydns com>

Collateral Damage and SORBS edit

Noted that someone marked every zone in SORBS as collateral damage.. this would be deliberate disinformation based on other listings not being collateral damage.

The Proxy and Relay zones are and always were purely tested and confirmed - there was and is no collateral damage.

The SORBS spamzones with the exception of 'escalations' is purely spamtrap (whether the SORBS Admins' inboxes or spamtraps provided) driven.

The only SORBS zone that includes deliberate collateral damage is the 'escalations' zone and any aggregate zone that contains it.

If the consensus is any zone that that keeps listings until delist requests occur, then you *must* apply the same policy to all the other DNSbls - including Spamhaus otherwise you are very much pushing a POV and false/misleading information.

The above information has been correct for SORBS since late 2010, so there is no excuses for the deliberate misinformation. The SORBS 'express-delisting fine' was removed from the SORBS systems at the same time.

-- Information in this section provided in Feb 2016 by Michelle Sullivan of SORBS. — Preceding unsigned comment added by 213.165.190.213 (talk) 00:01, 29 February 2016 (UTC)Reply

External links modified edit

Hello fellow Wikipedians,

I have just modified 6 external links on Comparison of DNS blacklists. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 16:19, 11 August 2017 (UTC)Reply

Noting issues with UCEPROTECT edit

Folks:

I don't yet dare touch the article here yet, but I would like to open a discussion on this here talk page regarding suggesting somehow noting in the listing that there may have been issues with UCEPROTECT may be a blacklist scam who puts entire netblocks onto it's RBS lists, if if spam is coming from only one IP in that netblock. They then charging money (with no due diligence) to remove individual IP addresses from a blocked netblock. This is a link to an article on Securityboulevard: https://securityboulevard.com/2021/02/uceprotect-when-rbls-go-bad/ I have a personal experience (although I understand that we cannot use personal experiences in Wikipedia, but the entire IP netblock of VPS provider Linode is being blocked by UCEPROTECT even though only a few of the individual servers' IP addresses may be spam. Here is a discussion on GitHub: https://github.com/jgamblin/isthisipbad/issues/22

And I don't know if IETF email archives are considered a source, but here is an email conversation involving the founder of UCEPROTECT and the IETF (Internet Engineering Task Force) https://mailarchive.ietf.org/arch/msg/asrg/aMzK5StZaPvampQtU5iu0fO-ojM/

Respectfully yours,
Mark Allyn
Bellingham, Washington
Allyn (talk) 16:47, 2 April 2021 (UTC)Reply

I agree, RBLs that violate RFC 6471 regarding payment for removal should not be promoted here alongside legitimate RBLs. It is like listing advanced fee scam operations in a list of investment firms. There is a fundamental difference between a legitimate RBL and one that seeks to extort money from people for happening to be on the same ISP as a spammer.

Therefore, negative-connotation DNSBLs MUST not charge fees or

require donations for delisting or "faster handling", and it is RECOMMENDED that such DNSBLs that do charge fees or require donations

not be used.

Gigs (talk) 21:38, 5 April 2021 (UTC)Reply

How does one nominate an entire entry in the list to be deleted? Or do I just add a sentence that these people are demanding payment for removal, which is a violation for RFC 6471? Allyn (talk) 08:50, 6 April 2021 (UTC)Reply

UceProtect has existed for 20 years, and while controversial, it is certainly neither illegal nor fraudulent nor do they extort people. The always repeated lie, that one has to pay to be removed doesn‘t make it the truth. See http://www.uceprotect.net/en/index.php

Some people tell lies and myths about us. Most of them run into trouble with us, because they were, or still are, learning resistant. The most frequently told lie is that a listee will not be removed until they make a payment. The truth is: Every IP listed will expire 7 days after the LAST abuse is detected, and FREE of charge.

The optional immediate removal is not available at all in the following cases:

1. If the owner of the IP or the ISP has declared to dislike this option.
2. If abuse has been seen from IPs listed in Level 1 or the backscatterer blacklist within the last 3 hours.
3. If a network area is listed in Level 2 and the listing limit has been exceeded by a factor of 10 or higher.
4. If an AS is listed in Level 3 and it is in the top 5 of the Level 3 charts.
5. If the listings in Level 2 or 3 are still increasing.

Only if these 5 criteria do not apply, there is a payment option available for any listee that does not want to wait 7 days but needs to be de-listed immediately.

If they were a pay to be removed list, anyone would have the payment option then.
UrsMair (talk) 12:42, 19 April 2021 (UTC)Reply

There is also 20 years of easily-located evidence of uceprotect's reckless or uninformed behavior. The "spammer" and "botnet operator" arguments are also tired. I think uceprotect should litigate their case with IETF (see source in article) and a vast number of other sites on the internet and correct those records first before exploiting Wikipedia.
EmpiricalSemaphore (talk) 13:50, 21 April 2021 (UTC)Reply

-
It appears that we need moderation and a lock on this article to protect it from exploitation by uceprotect or other misguided actors. How would we go about requesting this?
EmpiricalSemaphore (talk) 15:36, 22 April 2021 (UTC)Reply

I also note the "Some people tell lies and myths about us. Most of them run into trouble with us,...". That "us" looks like a Conflict of Interest. Feline Hymnic (talk) 20:24, 28 April 2021 (UTC)Reply
All of Ursmair's post above is copied from the UCEPROTECT site. --- Possibly (talk) 01:06, 11 May 2021 (UTC)Reply


---

The discussion about UCEPROTECT here is not factual but clearly too emotional. The original entry already says that you can optionally unlist for a fee, so that should be enough of a warning.


However, if the majority of administrators are of the opinion that the original entry must be changed, then I would like to suggest removing UCEPROTECT completely from the list of DNS blacklists instead of changing it.
A few reasons:

1. As long as they can be found in the comparison of the blacklists, visitors will inevitably also be lured to UCEPROTECT's website, and could fall victim to their propaganda.

2. An encyclopedia should be factual and not emotional. Personal but legally questionable and unproven claims such as suspect, fraud, scam and ransom payments damage Wikipedia's credibility at best.

3. Wordings like "Using these RBL providers will likely result in clogging up ISP support channels while negatively impacting legitimate business customers." can very easily be recognized as untrue, because there is no collateral damage in their level 1.

4. The reference to: "unstable behavior in public forums or operations or both" certainly does not prevent anyone from using UCEPROTECT or another DNSBL. Otherwise nobody would use any blacklist today. Examples would be Spamhaus and the nic.at case and also the public pissing match between Steve Linford and Michelle Sullivan.

Just my 2 cents. --- Martin.gaben (talk) 20:15, 11 May 2021 (UTC)Reply

---

For full disclosure purposes, I am not an employee of Linode or any other VPS providor.

I am a customer of Linode, however, I am not performing email services on any of my Linode VSP servers, so issues regarding UCEPROTECT do not affect me as a Linode customer. My servers are only for web services and Jamulus music jamming servers.

I only initiated this discussion because of what I ave read on the Linode customer forums while looking for answers to an un-related question.

I Love you all

Mark Allyn

Bellingham, Washington Allyn (talk) 20:48, 15 June 2021 (UTC)Reply

External links in article edit

I propose that we remove the external links that appear in the first two columns, per WP:EXTERNALLINKS. I am not sure why they are there in the first place. If necessary, they could be converted to references.--- Possibly (talk) 01:03, 11 May 2021 (UTC)Reply

Procedures edit

@EmpiricalSemaphore: I saw the discussion at ANI and understand the pain involved but the recent edits need work if you want something of their flavor to be retained. First, text like "Attention: please note..." is not suitable for an encyclopedic article at Wikipedia per WP:NOTHOWTO and common sense (what other articles sound like blogs?). If there were a reliable source with a specific message, an attributed comment might be included that conveys much the same meaning. However that might be difficult because "reliable sources" (see the previous link) on this topic would be hard to find. Second, similar reasoning applies to the "Notes" and "Suspect RBL Providers" sections. In principle, you could ask for assistance at WT:WikiProject Computing or WT:WikiProject Internet but not many people participate. I'll ping some editors I know of: @Kbrose, Kvng, and Zac67: Any ideas about more suitable wording? Specifically, how can this article alert readers about the perils of some RBL services? How would such an alert help? Should RFC 6471 be used? Johnuniq (talk) 01:08, 11 May 2021 (UTC)Reply

  • Thank you. Red tape is something I'm used to but Wikipedia is new. Low participation in Wikipedia is noted but understandable at scale. I fully welcome and encourage any and all advice or critiques. Not much interest in long-term editing but I would gladly bring this page to encyclopedic consistency. All recommendations welcome! RFC 6471: yes, especially section 2.2.5, "Conflict of Interest". Any pointers? Thank you again for your visibility and assistance - it is greatly appreciated! EmpiricalSemaphore
Hmm. I have read the comments at ANI. WP should not be in the business of quality assurance, approval, or derogation of commercial outfits. Typically lists like this contain entries for which WP already has an article, making them "notable". Otherwise it is just original research, or are all of these contained in some external list that can be referenced? I have only touched some of the most outstanding irritants in the article, but usually don't get involved much in these kinds of list/comparison articles. I am wondering whether the article should exist at all. kbrose (talk) 12:59, 11 May 2021 (UTC)Reply
Same from me. If this can't be set in the right direction, deletion is a reasonable option. It definitely wouldn't hurt to post something at the Wikiprojects; that's what they're for. ~Kvng (talk) 13:28, 11 May 2021 (UTC)Reply