How do I get my server off the ivmSIP/24 blacklist?

This is Rob McEwen, CEO of invaluement. First, while ivmSIP/24 has been around for a few years, we're always making improvements/tweaks... and we've made a number of improvements to the removal request system in just the past few weeks, some of which directly impact the suggestions I'm about to provide. (I'll also address Dmitry's comment later this message)

Here are some suggestions:

(1) If you have an IP or IP range delegated to you that isn't the whole /24 block, make sure that whoever delegated that IP to you goes into their IP whois registrar (arin, etc) and creates a sub-record for you which distinctly shows that you are the owner of that subrange, thus distingishing your ownership from the entire /24 block. While in the past ivmSIP/24 has been "hit & miss" with what I'm about to say... we've very recently become much more consistent in factoring this in so that we can leave the "innocent bystander" ranges untouched, while still blacklisting the egregious spammer's ranges. In fact, thousands of entries in ivmSIP/24 are partial entries for this reason alone, where they do NOT blacklist the entire /24 block. In many cases, we're the ONLY blacklist doing such "surgical strikes", where other blacklists are listing the whole /24 block.

(2) Make sure that your IP address has a "forward-confirmed reverse DNS" (FCrDNS). And make sure that the host name used in the PTR record is NOT some large sequences of items separated by a bunch of hyphens and dots, then ending in your hoster's or datacenter's domain. THAT is considered a "dynamic IP" and is considered substandard. In fact, it is getting to be an industry standard that the rDNS (aka "ptr record") should convey both IDENTITY and REPUTATION... via being something that ends in your organization's own PRIMARY domain name, and without a bunch of hypens/dots before that domain name. For example, "mail.example.com" or "outbound.example.com". If some numbering sequence is needed, make it "101outbound.example.com", or something like that. then make that FCrDNS by having (for example), "outbound.example.com" resolve to your sending IP, and your sending IP resolve to "outbound.example.com". (again, this is an example.. you would need to use YOUR MAIN domain in there).

The "FCrDNS" part is to prove you ARE who you claim to be. A PTR record is easily forged. But getting an "a" record to point back to that IP is virtually impossible to do without having authority.

Then, when this is all put together correctly (as 99% of extremely legit mail senders ALREADY do!!!!)... then this enables our system to better attribute your GOOD reputation (if you have any?) into our automated system's decision to list your IP (or not). This helps in two ways: (A) if a little spam really did slip out of your system, but that wasn't the norm for your IP and you also send LOTS of legit mail.. then this metric (along with MANY others I won't go into)... can often keep your IP off of ivmSIP and ivmSIP/24, even if a little spam slips out of your network, (B) AND... if you share a /24 block with egregious spammers, but your IPs are not sending spam, but you don't have the IP registry records I suggested above... then our automated system will often STILL keep you from being blacklisted (or will quickly auto-delist your IP) ...and just YOUR IPs... if you're doing this step correctly.

And consider this... 99+% of spam does NOT do this correctly. 99+% of legit mail DOES do this correctly. Do you REALLY want to have an attribute in such a state where it matches what 99% of spam does, and mismatches what 99% of legit mail does... and then expect your mail to be taken seriously? Think about that! (for example, the popular anti-spam program called Spam Assassin has a popular plug-in which adds points to the spam score just for this mistake!)

(3) Check Senderbase.org (choose /24 after you submit your IP)... and see what other IPs are on your same /24 block which THEY consider "poor". Then if these are not YOUR IPs... complain to your datacenter and maybe they'll kick off the spammers from that range. (or get someone else to clean up their security mess!).

(4) WARNING: Even AFTER you get off of ivmSIP/24 and all other blacklists found on MX Toolbox (etc.), we have found that many of the largest ISPs have internal blacklist which operate extremely similar to ivmSIP/24 (except often do NOT carve out exception ranges). So we OFTEN get complaints about mail STILL not making it to large ISPs who do not use our data, even if their IPs are not on ivmSIP/24 or any other publicly visible RBLs. ("are you sure this isn't on ivmSIP/24 because even though I don't see it there, google/yahoo/comcast/etc is still blocking us!!!") BOTTOM LINE: the nearby spammers dragging down your IP "neighborhood's" reputation continues to be the MAIN culprit. (again, follow step #3 above)

(5) Recently, we made a change to our system whereby all correctly followed-through removal request positively impact your chance of an automated removal, even if a human being didn't get to your request in a timely fashion. It isn't enough to make it worth a blackhat hoster's time submitting dozens of removal requests... but it often makes the different in speeding up removals in marginal cases. Why not "easy off"? Because at invaluement we specialize in blocking much spam that ALL other blacklists are either not blacklisting or not getting to for a while. Some such lists have had their data "gamed" by spammers working the "easy off" forms. Unfortunately, we do get overrun sometimes with requests. But, as I mentioned, we've recently (as in... in Oct. 2013!!!) make some update to further automate our processes... and we recently received a huge boost in funding that is enabling us to add staff, etc. for keeping up better with those requests which do require more manual processing.

So what went wrong with Dmitry's scathing comment above?

Admittedly, we're not without some fault in that process. But he is also not telling (or even understanding!) the whole situation. (first, I'm assuming this is Dmitry M. from the Ukrane?)

First, Dmitry's request was for ivmSIP, not ivmSIP/24. We have spam on file sent DIRECTLY from Dmitry's IP. in fact, 4 separate samples from 4 different days. If Dmitry has been on top of his mail server (as would be more typical of a legit operation) and had fixed this on day one... then we'd only have evidence of one spam outburst. Then, our automated system would have auto-expired the listing MUCH MUCH MUCH faster. But by allowing this spam problem to drag out, it "convinced" our automated system that he wasn't a one-off accidental security hole... but instead was more likely a deliberate spammer sending spam little-by-little over time. Again, that is NOT what happened. Dmitry didn't intend to spam. But his first removal request coming 10 days AFTER the spam problems started... along with many spam incidents in between, convinced our automated system to not take him that seriously and to draw out the expire time. Again, if he had found/fixed his security problem within a day or two, the listing would have auto-expired LONG before he had made his first removal request!

Secondly, Dmitry is NOT following the 2nd suggestion above about the PTR record. His PTR record is "82-117-235-74.gpon.sta.kh.velton.ua" ...which is about as "dynamic formatted" as one can get, and does NOT convey identity and reputation.

At the time Dmitry submitted his requests, we were in the middle of some of the programming improvements I had mentioned above... AND... spam across-the-board has seen a distinct uptick in recent weeks. Therefore, yes, we DID fail to get to his requests in a timely manner (then they DID finally auto-delist, or get manually removed, some days ago. But during that peak time, his requests were not "prioritized" for the reasons provided.) We're not without some fault in that process, and some recent funding we've acquired is going towards putting more man-hours toward processing such request going forward.

Still, as I mentioned, ALL properly submitted requests, including Dmitry's, do get a positive impact in our "scoring" now due to updates made to our system in Oct 2013. This is already lightening the load for our manual processing, helping us to keep up better with those requests which must be handled manually.

ONE FINAL NOTE: Dmitry's request really was more about ivmSIP, not ivmSIP/24. Regarding ivmSIP/24 requests specifically... one thing that is very difficult with ivmSIP/24 is that we get MASSIVE amounts of delisting requests from very crappy blackhat and dark-grayhat ESPs... who ONLY send advertisements (NOT actual newsletters, e-commerce, etc). They'll swear that their mailout is opt-in... and then we'll see it going to multiple spamtraps. Or they'll admit it was spam and that they booted the customer... then we'll see a similar spams the next week coming from their IPs. Keep in mind that we have to wade through that garbage to get to YOUR request. But if you can make sure that you're doing all the above suggestions.. then if your request, properly submitted at http://dnsbl.invaluement.com/lookup/, isn't answered and you're still blacklisted a couple of days after the submissions... AND your own IPs are NOT showing "poor" in senderbase.org ...then feel free to pick up the phone and call me directly and I'll be happy to help you (assuming you're not a P.O.S. blackhat or grayhat ESP masquerading as a legit sender!) just call +1 478 475 9032 (again, AFTER following all this advice, and if still listed after a couple of days!)

Rob McEwen, CEO, invaluement.com

Try visiting their lookup and removal request page:

https://www.invaluement.com/removal/

Start here: http://dnsbl.invaluement.com/lookup/

Alternatively, start by checking your mail logs and making absolutely sure that you are not sending any spam... and then go to the link above.

We have the same problem as 'cwd'. A whole /24 is blacklisted, even though the range is clearly in operation by several party's. We've try'd delisting though the site, and sent several mail's, but no de-listing or even a reply .. (we sent to several email-adresses, since I guess this one-man operation is useing his own blacklist to silently drop any mail from ip's listed in his own RBL).

The last one was :

From [email protected] Tue Dec 17 21:07:54 2013
Date: Tue, 17 Dec 2013 21:07:54 +0100
From: [email protected]
To: Rob McEwen / Invaluement 
Bcc: [email protected], [email protected],
        [email protected], [email protected]
Subject: incorrect listing in ivmSIP/24 85.17.178.0/24
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
        protocol="application/pgp-signature"; boundary="xJK8B5Wah2CMJs8h"
Content-Disposition: inline

Since we've try'd to delist through the website twice without any result,
I'm sending this mail, as a last resort.

You've listed 85.17.178.0/24 in ivmSIP/24, which is clearly not in use by a single user  

try : 

# perl -MNet::Netmask -e '$b = new Net::Netmask("85.17.178.0/24");foreach ($b->enumerate()) {print $_ . "\n"}'  | xargs -n1 host  |less

And you'll see that 85.17.178.128/26 is in use by us (DDS.nl), a ISP 
(one of the oldest in the Netherlands) 

And the rest by varieus clients of Leaseweb, which is not a bulletproof hoster.

And no, we don't spam, nor do we allow others to spam (nor have
we've ever allow anybody to spam, etc, etc). If there is any 
reason why you think we would be hosting or aiding spammers, we
would really like to know.


Please investigate, and delist.

Kind regards,


=paulv

Paul Vogel
Unix admin 
DDS 

Please note that we are a 'traditional' ISP, not some kind of e-marketing club. The only people sending mail through our systems are our customers, which are all normal end-users, and we have a strict anti-spam policy, which we strictly enforce.

To make matters worse, this person is recommending his customers to put it on frontend's, not as a weighting factor in SpamAssain or in a milter setup where multiple listings are required :

from the "TESTING/USAGE IMPLICATIONS" page :

"For all the many reasons described on this page and on our invaluement Anti-Spam DNSBL page, ivmSIP is best for blocking spam sent to real users instead of spam sent to honeypot traps and/or dictionary attack spams. That means that, if you check sending IPs against DNSBLs before checking to see if the recipient exists, then you should probably put Zen first. But if you are blocking spam based on the recipient not existing before checking the sending IP against DNSBLs, then you should probably put ivmSIP first"

Of course you should never use a trigger-happy 'angry' RBL from a single-person operation that has no working de-listing/review method on a frontend at any time. The problem with a operation like his, is that his sample size is to small .. If you never get email from a small provider, and have some honeypot adresses seeded on the internet then any mail you get from them is most likely spam, which means you have a 100% spam score for a certain range (the same way that any mail I get from a ip in South-Korea is spam, but not any mail sent from South-Korea is spam for anybody).

And last but not least:

This comparison show that the best RBL's have a accuracy that is typical far below 80%, with Zen being the exception at 94%.

www.intra2net.com/en/support/antispam/

Which is also a good reason not to put any RBL on a frontend (except Zen from spamhaus).

FYI

The difficulty with /24 blacklists is NOT mistakenly punishing innocent senders who happen to have IP allocation separate from the spammers, but which shares the same /24 block. And that is precisely why ivmSIP/24 is so new. For this very reason, we were reluctant to get into this /24 business. Until one day, several “light bulbs” went off and we developed several algorithms which enable the generation of an invaluement /24 blacklist which does not list innocent senders using address space adjacent to spammers. (At least, that is the goal. And reports from our subscribers, as well as our own internal testing, confirm overwhelming success!)