UCEPROTECT-NETWORK – another clever RBL..
After some complaints about mailserver blacklistings in the “UCEPROTECT-NETWORK level 1” blacklist I again spent a few minutes of investigating the issue and looking at their website. They seem to have no problem listing ISP mail relays after 1 or 2 misdirected mails from customer IPs and seem to have very “interesting” ideas about how mail should work and how they are going to police the net.. (read more below)
If you try to send an email message to a friend and get it bounced back with the message “IP x.x.x.x is LEVEL 1 listed at UCEPROTECT-NETWORK. See http://www.uceprotect.net/en/rblcheck.php” you will most likely have a quick look at the website. Uh-oh, it tells you that you are a bad spammer, right? Ah no, if it’s your ISPs IP address you should immediately complain to your ISP because (quote) “someone else abused it for spamming or for the spreading viruses / worms in recent days!!! [..] Send a complaint to your service provider and request him/her to stop any kind of abuse inside his/her netblock.”
Right? No – well, complaining is probably okay, but you should keep in mind that getting listed there is very easy even for average ISP customers – and being listed affects all users that try to mail to servers that are using these blacklists, generating complaints..
Citing their website:
Level 1 exclusively lists IP addresses with either wrong or missing or generic reverse DNS (PTR record), or “dialup†connections [typically suggesting a home/other user with a dynamic connection], or computers with exploited / exploitable security holes (e.g. open proxies, open relays, vulnerable webservers, virus infected etc) or which are using abusive techniques (SAV, CR, Backscatter etc) or which are assigned to well-known spammers. [..]
Since the Level 1 blacklist only contains single IP addresses, it is very unlikely to adversely affect innocent internet users when your system uses Level 1 blocking.
Use of the Level 1 blacklist for blocking is therefore recommended for systems where delivery of regular emails is more important than spam defense.
Good, and only affecting real spammers? Well, let’s make a quick check of their level 1 DB (as of April 14th 2007):
Mailserver IPs of AON.at (big Austrian ISP) currently listed: 195.3.96.102 195.3.96.112 195.3.96.113 195.3.96.115 195.3.96.117 195.3.96.119 195.3.96.120 195.3.96.89 195.3.96.91
Mailserver IPs of INODE.at currently listed: 62.99.145.6
Gmail? Listed: 64.233.162.227 66.249.82.226
AOL? Listed: 64.12.137.11 64.12.138.210
Hey, what’s funny about that list: On the FAQ of their commercial spam filtering product they refer to the AOL support pages regarding reverse DNS entries and call them “a large international provider”. They aren’t wrong there, but hey, if it’s a large international provider and even linked from their FAQ – why are they “spammers” according to your list?
Oh, another thing: Both Austrian sponsors and supporting organisations (Steuerkanzlei Umgeher, Foltec Gesmbh) are INODE.at customers. I hope they don’t use their ISPs smarthost and have issues with their RBL blacklisting their own providers’ mailservers? 😉
So, how does one get listed? According to the logfiles I have access to there have been exactly two occurences of “spam mail” to UCEPROTECT-NETWORK servers. One was a mail to an invalid recipient in the muenchen.de domain, where the admins seem to rely on an UCEPROTECT anti spam appliance. The other one was a mail to a spamtrap domain, generated by a customer IP. Maybe a typo, maybe an old address – or a spam mail. But it was a single mail. Now the host is UCEPROTECT-1 listed for a week, great. Oh, and in case I forgot to mention it: Their spamtraps “reject” inbound mails with a 4xx error, so the mail servers will obviously retry later. Does that cound as 1 spam delivery attempt or multiple..?
host postmaster.kicks-ass.org [84.16.233.208]: 450 UCEPROTECT-Policy Server decided: 450 (V3.4-EXPO-0408) Do we have that user or not? Who knows 🙂
Hm, if that’s really the case (and it looks like it is) then a single mail by an annoyed customer to a UCEPROTECT spamtrap address is enough for a listing. Or just send two mails, it doesn’t really matter. Your ISP will be very happy for yet another RBL listing. Just keep sending one or two mails every week – in case the abuse department contacts you just claim that you mistyped the address and will fix it ASAP. The ISP will then either have to wait another 7 days (from your last mail) or pay 50 euro per ip address to UCEPROTECT-NETWORK for removal. Extortion, anyone?
On their website UCEPROTECT-NETWORK has a list of techniques they consider to be abusive such as SRS and Sender Verify.
They state that SRS is useless and helps spammers, so they suggest to block SRS rewritten envelope senders. Even their appliance seems to do so, according to their site.
SRS itself is not flawless, but if it’s implemented correctly (e.g. SPF check before SRS usage) then I hardly see any problem. Quick excursion into the world of SPF and SRS: SPF is basically a TXT record in DNS that defines which IP addresses may send mails with an envelope sender within the respective domain. If the IP delivering the message is not listed in the SPF record (and the domains has a Deny-All SPF policy) then the mail will get rejected. This creates issues for people who like to forward their mail from one ISP to another. Because their ISP’s mail servers are most likely not listed in the sender domains’ SPF record, the mail server of their second ISP will reject the forwarded mail if it’s checking SPF records. Here, SRS comes into play. It’s basically a technique to rewrite the envelope sender to match the mail servers’ own domain, but it should only be used when there are SPF records for the envelope sender domain and those have been checked before.
UCEPROTECT sees a problem there, because according to their website: “SRS is absolutely unnecessary. [..] As a domain owner you can choose whatever you put into your SPF-Records. So if you have the need for your emails to be forwarded by a different service provider or you have the need for emails claiming to be from you to be sent by e.g. Ebay or Paypal, it is not difficult to set an appropriate SPF-Record that allows forwarding by selected relevant hosts or domains.”
So, what UCEPROTECT says is basically: A domain owner is responsible for choosing the right SPF records and has to list all the mail servers that should be allowed to forward mails with envelope senders within his domain and SRS is not necessary at all.
Right, so I as a domain owner should list thousands of mail server ip addresses in my SPF records just because I want to make sure that recipients can receive mails that I send, even if they choose to e.g. forward all of their messages from GMX to GMAIL? I should list all the GMX outbound mailserver IPs in my SPF record? Hey, do you even know how many different IPs and subnets I would have to list there to make this work? And don’t forget, by listing them in my SPF record I basically say that mails sent via these servers are valid and originating from my domain – even though I don’t know 99,9% of the users of these servers. Great security. I really do prefer SRS instead of this nonsense “solution” as suggested by UCEPROTECT.
Sender Callouts/Verify is abusive? According to their web site:
If some idiot was to fake the “From†in a spam to be YOU@YOURDOMAIN.TLD [an email address on your server] and send about 30 million spam emails out like that, what do you think will happen?
Your server will have to deal with several million bounces, but additionally also deal with millions of VERIFIERS.
We don’t think you will find it so cool when you get e.g. 200,000 connection attempts per minute from other servers worldwide, which are “ONLY” probing your email address to see if it is deliverable or not …
This is the logic behind our reasoning, and to us there is no difference between computer systems trying to send email to spamtraps or computer systems that are “only” probing our spamtraps …
Well, too bad that their spam traps can’t seem to distinguish between “real” spam mails (by content analysis) and address probes/sender verify. What about fixing this small issue?
At least I prefer connections of mailservers doing sender verification instead of spam-complaints to the ISP hosting my mail server because of “spam messages” from my domain or complaints to the email addresses listed on my web site because of spam messages originating from “addresses within my domain” (that don’t exist at all anyway).
Sender verifications can easily break your email connection as follows:
Your computer system tries to send an email to ABC@EXAMPLE.TLD
If EXAMPLE.TLD does the same ‘verify’ nonsense as you, they will say:
451 Unverified Sender — try later
But your computer system also does 451UNVERIFIED Sender back to EXAMPLE.TLD
You will end up in a loop where each computer system wants to “VERIFY” the other system first…. until your email expires …
That logically means: You lost the game 🙂
I wonder if they have ever seen an implementation of sender verification in real life, or if they just can’t see a difference between sender verification and other techniques such as greylisting. Most sender verifies use emtpy envelope senders, so a second verification step simply does not happen. And those who don’t hopefully disabled sender verification for their own verification sender addresses. Otherwise the mentioned loops are possible – but I’d guess they are less than common if sender verification is configured correctly.
Ah well, enough written about that blacklist. If you come across it again – think twice before using it. If you’re affected by it (e.g. your ISPs mailrelay is listed) – bad luck. Either complain to your ISP (as they suggest) or complain to the recipient domain by other means than email messages (as those are blocked) regarding their “interesting” anti spam setup and RBL usage.
Oh, and a last thing: Over-usage of punctuation marks (“!!!!”) and smileys everywhere doesn’t really make a RBL site look more trustworthy. But that’s maybe just my own opinion..