All too frequently we get complaints about people not being able to send email through their own mail servers because they are allegedly blocked by the CBL. At other times it will be access to IRC or web sites being blocked by CBL listings. This is not supposed to happen.
This generally means that the administrator of the mail server or other service has either deliberately or mistakenly used the CBL contrary to our terms and conditions. This sort of situation isn't limited to the CBL.
For example, in DNSBLs for Extra Mail Security Security Gadi Evron describes how he found himself unable to send email to his own server due to a blacklist entry despite having authenticated to it.
Technically: he was roaming outside of his local network, and his "smarthost" (more precisely "MSA" - Mail Submission Agent) server refused authenticated connections from him because the IP address he was currently using was blacklisted.
After more investigation he discovered his mail server was misconfigured, he had originally intended it to not listen to blacklists when a connection authenticates.
Instead of fixing it, he goes on to say that he considered this, not a bug, but a feature. In that it helps serve notice to him that he is in an "insecure" area in the Internet, and may encourage other site admins to configure their MSAs that way. Similarly, such articles may lead to other services being configured this way.
There are several important things to be considered relative to configurations choices like this:
Certainly, with spam volumes exceeding 90% of all inbound email in many cases, and the proliferation of fraud through proxied/spambot connections, system administrators are trying to wring the last little bit of effectiveness out of the tools they use. The temptation is strong to do things like this. However, this practise has severe downsides and as can be seen, virtually no benefits whatsoever.
If your email provider (ISP, employer etc) followed the blog's advice with email, what happens?
You're on a business trip. You land in an airport somewhere, you fire up your laptop and connect to the airport lounge's wireless, and pay $6.95 to get connected for 15 minutes before your connecting flight leaves. You want to send an email to your family to tell them you made it, and to your employer containing your presentation slides and other final arrangements for the meeting you will just barely make.
You make your connection, authenticate as you, and your mail reader pops up with "email rejected". Being able to do anything about this is almost impossible.
Important email blocked, money lost, over something you have absolutely no control over and can't do anything about. It was that van full of 419ers that camped out in the arrivals level the day before, or that kid's Netbook two rows over that's downloading things he shouldn't.
Equally unable to do much is the provider of the wireless service. Sure, they could block port 25, but that just means that everyone who doesn't have a port 587 provider is blocked all the time.
Equally unwilling is your provider - that IP tries to send oodles of crap (without authentication), and they want that blocked.
The goal is to let good mail through, and stop bad mail.
The blog's suggestion doesn't stop any additional bad mail, it blocks good mail that it didn't need to.
In other words, the blog article is promulgating advice that can have unforseen negative consequences in almost all circumstances
The correct way to support roaming user email is to use the industry best practises as described in MAAWG - Managing Port 25 and thus implement a MSA on port 587 (as described in RFC2476), implementing SMTPAUTH (as described in RFC2554) that supports TLS (encryption). If the MSA requires all three of these for successful email submission, then it does not have to do any DNSBL lookups.
Strictly speaking, TLS encryption isn't entirely necessary, but if your roaming user is presently "somewhere out on the Internet", it's a bad idea to do authentication in the clear - the user could be revealing their userid and password to criminals sniffing the network.
There is no harm in offering the same roaming service on port 25, noting that connections that authenticate should not be subject to DNSBLs, and that many roamers may find themselves in netblocks that block port 25, so port 587 is their only alternative.
In other words, if you do only one, do port 587. If you do both, educate your users to use the port 587 version, not the port 25.
The only time where subjecting authenticated connections to DNSBLs is appropriate is where all of the roaming users of a given server don't mind their email being blocked at random times and locations. I wouldn't like to be in that situation. I doubt many others would.
Such advice should be considered very carefully, and if you do decide to do it anyway despite the downsides, make certain that you follow all of the DNSBL's usage requirements.
The following specifically refers to the CBL's and Spamhaus' requirements, other DNSBLs may have different policies.
In the CBL's Terms and Conditions item 6 this configuration is specifically prohibited. Other sections prohibit the use of the CBL for non-email services. Further, this prohibition also applies to Spamhaus inclusion in XBL, SBL-XBL and Zen. However, you can still do this (see item 7), but to be in compliance you MUST make sure that your error message does not refer to the CBL or Spamhaus in any way. Your error message must direct users to your support infrastructure (possibly you), and you must be prepared to locally whitelist IPs.
In other words, you must take full responsibility for the block, and deflect the "blame" for unsupported use of the listing away from the CBL (and Spamhaus).
For example, instead of the error saying:
Email blocked by CBL, see http://cbl.abuseat.org/lookup.cgi?ip=<ip address>It should say something like:
Email blocked by local policy, please contact this site's administrator about <ip address>
The CBL will not delist IP addresses that are only an issue because the CBL is being used in a non-standard/unsupported way.