Because of unsolicited promotional email and other forms of network abuse, access to network services—such as mail exchangers—is restricted more and more often. This document suggests a procedural framework for administrators whose networks or servers have been “blacklisted”.
The basics
You cannot bully people into accepting your traffic
The Internet consists of a large number of individual networks. Most of these networks are privately owned. Whenever you are allowed to send traffic to a network someone else pays for, you are being extended hospitality that can be revoked without notice. In most cases, there is no way you can force a remote network to accept email or any other traffic from your site.
(A pointy-haired person once commented, in disbelief: “But that would be anarchy!”—Not far from the head of the nail, although “polyarchy” probably would be an even better description of the distributed nature of Internet governance.)
Issuing demands when blocked is probably the worst thing you can do to your own connectivity. Distributed blacklists are protected through freedom of speech, and their operators are often highly regarded by the Internet community they serve. Also, administrators have a duty to protect their resources, so they are usually very serious about their right to restrict access. Picking a fight with blacklist operators—especially issuing any threat of legal action—over your listing is therefore likely to swiftly place your networks in an indefinite number of static access lists all over the globe (yes, that’s an awful lot of jurisdictions) for a long time.
Natural selection applies to blocklists. If using a list doesn’t produce results, it will die. Conversely, the lists that survive are likely to be both effective and esteemed.
Understanding blocklists
- Local lists are typically static access list files used on one site or within one organization.
- Distributed lists, such as SBL and APEWS, are made available to the general public (most often through the Domain Name System), and are usually dynamically queried by server applications.
If you are dealing with a distributed blacklist, be sure to understand the difference between these roles:
- the list operator who has added you to their list
- the party who is using the list on their networks and/or servers
Adding a network to a distributed list is merely an informational service that by itself does not affect the listee’s traffic. Any decision to actually block or otherwise influence traffic to a site is made by an administrator at that site. In other words, the blacklist operator only runs a list; whether and how to use that list is up to individual network administrators.
Being blocklisted does not necessarily mean that you would, in anyone’s opinion, have committed any kind of offense. As an example, blocklists are often used to deny dial-up and DSL users SMTP access, encouraging these users to send their mail through their providers’ smarthosts instead. Also, some lists define abuse in a debatable fashion, including therein RFC 821 non-delivery messages and other automatic responses (since an erroneous return address would cause these to be sent to an unrelated third party). Still others seek to list all networks assigned to certain countries, so that a provider can enforce a policy of not accepting mail sent from or through those countries.
(Although the terms “block list” and “blacklisting” are established de facto, and therefore also used in this document, they are technically incorrect. Distributed lists may be used also for other purposes than actually blocking traffic; they are often used to merely tag email Subject: lines, and they could theoretically be used even to favour listees.)
Things you can do to help prevent being listed
- Do not allow unsolicited promotional email to be sent from your networks.
- Do not host any kind of “spam support services”, such as
- directly or indirectly “spamvertised” web sites
- “drop boxes” for replies to unsolicited email advertisements
- DNS service for junk mailers
- payment processing services for “spamvertised” products
- junk mail tools, e.g. web pages marketing “millions of email addresses”
- Make sure all your hosts are secure. No “spam bots”, open SMTP relays, open proxy servers, or similar abuse intermediaries may exist.
- Implement abuse and postmaster addresses.
- Make sure adequate contact information (most importantly, organization and person names, email addresses, and telephone and fax numbers) for all your domains and networks can be retrieved using the relevant whois service.
- Publish an adequate, detailed and binding AUP. Focus on preventing abuse from occurring in the first place.
- Should your preventative anti-abuse measures fail: act upon legitimate problem reports, and consider publishing your actions.
- Make sure all your mail exchangers accept empty return path (MAIL From: <>) delivery status notifications.
- Avoid bad neighbourhoods. If your providers are ignorant or downright abuse-friendly, their reputation is likely to “trickle down” to you.
Steps to take if you are listed
As discussed above, never threaten legal action over blocklisting issues.
- Find out how you are being blocked
There is no central Internet blacklist. Pay attention to the error messages you have received. If there are references to a distributed blacklist, note them.
You can also try looking up your domains and networks on major blocklists. Some blocklisting web sites allow you to query many lists at once. Note that you might be on several different lists, maybe even for several different reasons.
Distributed lists can usually be queried using a DNS resolver, by prepending the lookup key (in the case of an IP address, in reverse order) to the zone name. The existence of any A record indicates a positive result. For example, if 192.0.2.2 was listed on relays.dnsbl.example, the query dig 2.2.0.192.relays.dnsbl.example might yield 2.2.0.192.relays.dnsbl.example. 300 IN A 127.0.0.2. In order to differentiate between reasons for listing, 127.0.0.3, 127.0.0.4, and so on, might also be used. An NXDOMAIN reply would instead indicate that 192.0.2.2 was not listed.
If you don’t find yourself listed on any of the distributed lists, you will, for now, have to assume that your traffic is being blocked by a local access list. Most of this document still applies.
- Find out why you are being blocked
Sometimes an error message (or, in the case of distributed lists, a TXT record) will state the reason for the block. Distributed blacklists often run informative web sites providing answers to frequently asked questions. Even if you have been blocked only locally, the organisation blocking your traffic might have a web page explaining their policy, possibly even displaying their current block lists.
If you cannot find any clues as to why you are being blocked, you may have to contact the blocking site at this stage already.
- Remove the problem, if possible
Fixing the problem that has earned you a listing may be as easy as pulling the plug on a junk mail relay, or as complicated as implementing and enforcing new terms of service. Be as thorough as possible; do your best to make sure the problem is really gone and cannot resurface.
In some cases you might conclude that the reason for the listing cannot be removed. For example, you might be unable to relocate to a different country in order to evade a country-based listing. You might find it useful to contact (such as phone or fax) the party who is blocking you, and ask them to “whitelist” you. Think very carefully before attempting to circumvent a listing; if a recipient doesn’t want your traffic, they are likely to also block any alternative routes you might find.
- Request blacklist removal, if appropriate
Many blacklists have automated interfaces, such as web forms, for requesting removal of list entries. Always try to comply with the procedures set out by the list operator. If you need to phrase your request, make it polite. Most blacklist operators are eager to keep their lists up to date, but it’s human to prioritize attractively written requests over hate mail.
Whenever you contact someone—whether in public or in private—over a listing, please be specific. In the eyes of someone who doesn’t know which list and which networks or domains you mean, phrases such as “please remove me” or “why am I blocked?” are meaningless. Something like “the open relay at 192.0.2.2 has now been repaired, please consider removing 2.2.0.192.relays.dnsbl.example” would be much better.
Please note that if your entire provider—or, indeed, one of their providers—is being blocked, removal is likely to require efforts by them. Therefore, in such a case, avoid bothering the list operator; instead direct your efforts at your own provider.
- If unsuccessful, contact the recipient
You might find your removal request denied (in fact, some lists do not allow for removal requests at all). If so, the senders should contact their intended recipients, for example by telephone or fax, to request a so-called whitelisting, in other words an exception that will allow certain mail through irrespective of any blocklist entries. After all, if the recipients do want mail from your users, blocking it makes no sense.
- If you feel that you need professional advice, seek it (added on 30 December 2008)
The editor of this blog may be able to assist other ICT pros individually, on a commercial basis.
- Additionally, you might want to publicly discuss the issue in a suitable medium—such as here (free of charge, of course)! Please leave your comments!
3 Comments
This is a little different. I can access Google from my PC at work, but my husband could not access Google from our iMac OS9 at home. This happened yesterday and I tried to get on goodle last night. The page stalls and does not open. It is our “home” page by the way. Could he have somehow accidently blocked it? Could he have been blocked for some reason? He had been searching for work on line when this happened. Thenks for any info.
Dorothy
Dorothy,
Thanks for your comment.
I can’t remember having heard of Google blocking users from their web site. As I understand it, browsing problems such as the one you describe are usually caused by other reasons, such as problems with the browser, firewall, name server, or Internet connection. Sometimes the error message is useful in finding the problem.
If you would like to try some lower-level troubleshooting, I have some instructions up at http://www.anta.net/misc/telnet-troubleshooting/http.shtml .
Good luck!
Thor Kottelin
On the somewhat related topic of content-based junk mail filtering, I’d like to add that if your *solicited* bulk mail, such as autoreplies or invoices, seems to often hit the filters of various recipients, it would probably be a good idea to test those messages against a local copy of Spamassassin.
A single word can cause a message to look “spammy” enough to hit the bucket. These problems are often easy to fix, but must first be recognized.
Post a Comment