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

I checked my server IP using this tool:

http://www.mxtoolbox.com/SuperTool.aspx

It's come up on the ivmSIP/24 list.

What can I do to get my IP removed from this list? I have SPF records set to allow this IP to send mail on behalf of the domain.

Solution 1:

Try visiting their lookup and removal request page:

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

Solution 2:

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

Solution 3:

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.