How does one deal with a mail server being blacklisted due to being on a RANGE of IPs?

I checked blasklists andour IP is on Uceprotectl2 and Uceprotectl3 due to poor reputation.

UCEPROTECT is a shakedown scheme. Instead of blacklisting single IPs or subnets, they blacklist entire ASNs. In Linode's case, that's probably hundreds of thousands of IP addresses worldwide. As such, Linode refuses to pay the ransom. Linode's ASN is on/off UCEPROTECT periodically (right now it's on).

If email to your customers/subscribers is going into spam, it's probably not due to UCEPROTECT…more likely its some more-local setting on the part of your customers/subscribers. If your IP was truly blacklisted, the customers'/subscribers' mail server would just bounce your messages or send them to a black hole.

You don't mention it, but have you implemented SPF, DKIM and DMARC on your server? Doing that will probably help solve your problem a lot more than worrying about UCEPROTECT…

-- sw

We use smtp.com to relay mail through due to the Microsoft blocking issue at linode. They’ve setup some return path setting for the SPF so that’s working.

We don’t use dkim or dmarc and never had an issue.

We host many customers domains on our mail server.

Strange thing is I send a test email to https://www.mailgenius.com/ and my own email does not report the server being in the blacklist, but when a customer who is reporting spam issues sends an email it says the mail server is on the blacklist. But we both use the same server. The blacklist was my only explanation why his goes into spam but mine are not.

Strange thing is I send a test email to https://www.mailgenius.com/ and my own email does not report the server being in the blacklist, but when a customer who is reporting spam issues sends an email it says the mail server is on the blacklist. But we both use the same server.

Lots of server operators (could be most server operators) eschew use of UCEPROTECT. They don't exactly have honorable motives and/or clean hands.

The blacklist was my only explanation why his goes into spam but mine are not.

This could be the result of a local filtering rule your customer has implemented in his MUA.

-- sw

I have the same issue. And yes, it appears that the entire ASN is blacklisted or "with low reputation".

The annoying part is that GMail now is refusing most of my server's emails, despite having configured SPF, DKIM and DMARC, in addition to PTR and other DNS records to validate the emails' source.

Checking the blacklisted websites for removal worked for me in the past, but not anymore: my current IP isn't blacklisted, but GMail still refuses to accept any emails from my server.

I am having real bad time with spam….

Firstly last year Microsoft blocked Linode.com for over a month. So I sent through smpt.com.

Once Microsoft fixed the issue, I changed back to our mail server and now Gmail is blocking it all. So I have changed back to smtp.com again.

But I am also receiving issues from people when using smtp.com, possibly related to SPF or DKIM not being correct.

BUT the only reason I can think of Gmail blocking us, is because the servers are on uceprotect.

Does anyone know if any email server check against uceprotect, because it just seems like its a ransom for Linode to pay, it does not look professional at all, and it would be unbelievably bad if Gmail and others check against uceprotect.

But I cant see any other reason why Gmail would block emails from my server. Its several Linode servers. All of them are on uceprotect. They're not actually on uceprotect themselves, but Linodes IP ranges.

BUT the only reason I can think of Gmail blocking us, is because the servers are on uceprotect.

I really, seriously doubt that Google uses UCEPROTECT… There's no incentive for them to do that. They can invent a way better, more nuanced system of their own and operate it themselves for next to nothing. Why would they pay a penny-ante operator like UCEPROTECT (with a widely-known reputation for extortion) if they don't have to? It doesn't make business sense and wouldn't be a very good look for them.

In fact, I send email to gmail.com accounts every day from my Linode server with no problem. If Google were using UCEPROTECT, my mail would get blocked as well. I'm probably not sending the volume of email that you are but blocklists are really stupid like that…they usually don't take volume into account.

But I am also receiving issues from people when using smtp.com, possibly related to SPF or DKIM not being correct.

You should probably fix these things before leaping to the conclusion that Google is using UCEPROTECT. gmail.com is pretty anal when it comes to these…especially SPF…and Google often institutes policy changes (like increasing their amount of anal retentiveness about things) without wide notice.

My email server (postfix) also uses IPv6 and smtps whenever it can.

Does anyone know if any email server check against uceprotect

You'll have to ask UCEPROTECT about this. I'm sure they'll happily answer your inquiry for the appropriate amount of cash or bitcoin.

-- sw

You should probably fix these things

The issue is that I have no configuration issues: PTR, SPF, DKIM, DMARC… You name it, I did it. And quite well.
I'm using SMTPS, valid SSL, and so…
Plus, sometimes my emails go through, normally, and I see, when I click on "Show Original" from GMail that the SPF, DKIM and DMARC passed!

@paulmarc --

I don't know what to tell you…

If Gmail was consulting UCEPROTECT, all my emails to all the Gmail accounts I correspond with regularly (including my own) would bounce as well. I haven't had a single one do that…in many years…

My suggestion is to look for another cause…possibly an overly-broad local filter rule configured by the recipient?

-- sw

My suggestion is to look for another cause…possibly an overly-broad local filter rule configured by the recipient?

I don't know for sure, but I don't think so: I'm testing with a "no-filter" recipient.
The emails get flagged randomly as SPAM. Some get through to the mailbox, and others in the same thread go to the SPAM folder.

If it's a configuration, let's fix it (what is it?) or if it's something else, let's hear it.

It's confusing and annoying.

I guess the best course of action is another channel to the recipient, asking to make sure the email doesn't land in their SPAM folder and gets ignored.

OK, update: I noticed that my mail server is sometimes using the IPv6 IP, and I recently changed the AAAA records (and thus the server was missing its IP).
I fixed the DNS record, and the issue seems to be fixed, with GMail.

But I don't know if:

1. That was the issue (because before DNS was correct and the issue was there);
2. Maybe I flagged my emails as "HAM" (Not SPAM) so often so GMail now considers them "OK"?

In all cases, hotmail still flags them as SPAM :(

OK, update: I noticed that my mail server is sometimes using the IPv6 IP,

What's wrong with your mail server using IPv6?

and I recently changed the AAAA records (and thus the server was missing its IP).

IMHO, you should have AAAA records for

mail -> IPv6
mail -> IPv4

and configure the mail server to use IPv4 only… In postfix that's accomplished with:

#inet_protocols = ipv6 # v6 only
#inet_protocols = ipv4 # v4 only
inet_protocols = all   # both v4 & v6

Maybe I flagged my emails as "HAM" (Not SPAM) so often so GMail now considers them "OK"?

Boy! Howdy! I'd love to know how you did this!

In all cases, hotmail still flags them as SPAM :(

This has little, if anything, to do with you. M$ does what M$ does and you have no control over it…they won't even tell you why they do what they do. Search around in this forum…you'll see lots of threads about mail being rejected because either their "AI" had a brain fart or their idiot admins didn't know what they were doing and blacklisted every IP network known to man (except M$s of course).

M$ routinely flags networks (a.b.c.d/nn) as spammers…not nodes (a.b.c.d). I would assume they do the same thing with individual messages originating from "suspect" networks/nodes. A peek at the headers of a message marked as spam by Hotmail may give you a clue as to why… Have your recipient(s) forward those back to you. However, like I said, the decision by Hotmail to classify a particular message as span probably is local (to Hotmail) and has nothing to do with you (unless you don't have any of SPF, DKIM or DMARC set up).

However, M$ does not use UCEPROTECT. They have their own, "smarter" RBLs…

-- sw