More Zen Internet woes...

Two months ago, I reported systemic issues with Zen Internet's IP block management, eventually resolved after a number of days by the creation of missing reverse DNS (rDNS) records.

I've only just discovered that (at least) this subnet of "static" IP addresses, possibly more, has been listed - presumably by Zen Internet - on a real-time block list (RBL) of IP addresses used by Trend Micro customers to prevent spam being received from IP addresses dynamically allocated to dial-up users, i.e. a group of people that has become vanishingly small in recent years, and will disappear completely if the 2025 changeover to 100% IP telephony actually happens.

You just couldn't write this stuff. Zen Internet has been informed, but new customers thinking of hosting MTAs on their "static" IP address might just want to check that it isn't listed on the Trend Micro checker here.

And as the removal of my IP address from the RBL could take up to 48 hours to propagate around the Internet, I can't contact the affected recipient by e-mail until that happens.

Sigh.

Edited by deleted (Tue 12-Jul-22 20:48:12)

My address is also blacklisted - 88.98.87.xxx

In reply to a post by ukwiz:

My address is also blacklisted - 88.98.87.xxx

I should have included mine... 51.155.204.xxx - a completely different IP block, but also wrongly listed as being used by whatever dial-up customers Zen still has...

Double sigh...

82.69.100.xxx is also blacklisted. Zen insist it is because the address doesn't have a reverse dns. Why should it when it is not running any servers

I have had this IP a long time and it does have a rDNS but at least its not every Zen address!

IP: 82.68.x.x
Reputation: Unlisted in the spam sender list
Listed in: None

Mine too.

88.97.10x.xx

Probably includes everybody!

In reply to a post by ukwiz:

82.69.100.xxx is also blacklisted. Zen insist it is because the address doesn't have a reverse dns. Why should it when it is not running any servers

https://mxtoolbox.com/problem/smtp/smtp-reverse-dns-...

What it needs is for Zen to register their static ip addresses.Of course, with Zen that is unlikely to happen.

That’s not really how it works…

There are many MANY RBLs out there. Each of them generate their list based on different things. A lot of them start by looking at the rDNS for an IP. If it appears autogenerated (88-98-240-10.dsl.zen.co.uk for example) then the lists add it to a blacklist. Not because it’s dial-up, but because it’s likely a residential service so unlikely to be running an MTA.

If you want to run an MTA, then Zen provide the tools for you to set an rDNS record that looks more legitimate so can avoid RBLs.

There is nowhere to ‘register’ an IP address as being for a certain use, and there are so many RBLs that it’s not feasible for an ISP to routinely try and ensure that it’s IPs are not listed on them all, especially when for the vast majority of customers it makes little difference. The bulk of customers are not running MTAs.

Any sysadmin worth there salt knows about this, so will ensure this is all in line before moving production service onto a new mail platform.

In addition to this, companies that are still running their own email infrastructure are likely to use a smart host which may also be providing their inbound filtering - Mimecast, Proofpoint etc. and so the reputation of the originating IP isn't important. If you're sending mail directly from a server you run yourself and it's a production system (which it appears to be as this problem is inconveniencing you) then what was your contingency plan for a broadband outage?

In reply to a post by ukwiz:

What it needs is for Zen to register their static ip addresses.Of course, with Zen that is unlikely to happen.

Just to clarify, and this is largely historical, it was actually of significant value for LIRs (local internet registries, i.e. those to whom RIRs - regional Internet registries - have allocated blocks of IP addresses, or "address space") to notify managers of RBLs that specific subnets were used as a "pool" for allocation to dial-up users, or these days, for dynamic allocation on broadband lines provided by ISPs: clearly, spam originating from script kiddies can then be filtered out from incoming mail queues because of the presence of the sending IP address on a reliable RBL.

What needs to be clarified here is that there are many RBLs, some good, some bad, and many of them - like the Trend Micro one to which I refer in the original post - are very specific. As already stated, this one comprises dynamic IP addresses, and there is no "behind-the-scenes magic": LIRs can choose to have IP addresses added to all, some, or none of these RBLs.

In other words, there's no central list of static IP addresses... if there was, it would be a "white list", but the issue here is that at some time in the past, Zen Internet had these IP addresses added to a dial-up IP address block list, not necessarily the Trend Micro one, but it must have been an active choice, one that hasn't been documented or worse, their management process has just failed and they've changed how they use a significant part of their address space without updating any relevant RBLs.

My post a couple of months ago was about a completely different problem, but one that arose for exactly the same reason: Zen don't manage their address space properly. From being something apparently affecting only a small part of their allocated address space, it appears from the various responses above that it's a much bigger problem, one that has been hidden because most users of static IP addresses aren't running their own Message Transport Agents (MTAs).

Having a dynamic IP address is fine if a static IP address isn't needed, not least because there are workarounds (e.g. dynamic IP reporting clients), but anyone handling mail for one or more domains needs a static IP address with a good "reputation", and it's a real pain finding out that your static IP address is on an RBL for no good reason.

PS - No response received from Zen Internet other than the automated acknowledgement of the Support query.

In reply to a post by jpm:

If you're sending mail directly from a server you run yourself and it's a production system (which it appears to be as this problem is inconveniencing you) then what was your contingency plan for a broadband outage?

Mail for or from the more important domains can be routed by Siteground's mail facilities, but TBH this instance only arose because a single recipient - it happens to be Asda, part of Walmart - uses this particular RBL, of which I wasn't even aware until now.

But it shouldn't be necessary to invoke a contingency plan because your ISP is rubbish at network management...

In reply to a post by SteveBen:

If it appears autogenerated (88-98-240-10.dsl.zen.co.uk for example)...

That would be autogenerated for 10.240.98.88 which is within the Class A private address range 10.0.0.0/8, unrouteable on the Internet, or was that deliberate?

Edit: Ah, I see, this is theoretically generated from 88.98.240.10! I'm thinking ARPA TXT DNS records...

Edited by deleted (Wed 13-Jul-22 20:47:29)

In reply to a post by GraceCourt:

Just to clarify, and this is largely historical, it was actually of significant value for LIRs (local internet registries, i.e. those to whom RIRs - regional Internet registries - have allocated blocks of IP addresses, or "address space") to notify managers of RBLs that specific subnets were used as a "pool" for allocation to dial-up users, or these days, for dynamic allocation on broadband lines provided by ISPs: clearly, spam originating from script kiddies can then be filtered out from incoming mail queues because of the presence of the sending IP address on a reliable RBL.

No, that is not how it works. ISPs don't register their addresses with RBLs as dynamic/static/whatever. That is just not a thing,

In reply to a post by GraceCourt:

In other words, there's no central list of static IP addresses... if there was, it would be a "white list", but the issue here is that at some time in the past, Zen Internet had these IP addresses added to a dial-up IP address block list, not necessarily the Trend Micro one, but it must have been an active choice, one that hasn't been documented or worse, their management process has just failed and they've changed how they use a significant part of their address space without updating any relevant RBLs.

Again, not a thing. In fact the subnet you are referring to is 51.155.0.0/16 up until a few years ago belonged to the DWP. (https://petition.parliament.uk/archived/petitions/38744). Do you think Zen added addresses to some magical list of dial-up addresses in 2015 when it appears it purchased them? (https://apps.db.ripe.net/db-web-ui/query?searchtext=51.155.0.0%2F16) Or do you think the DWP were adding addresses to an RBL marking them as dialup?

This is not a thing. RBL maintainers make their own mind up, about what they think is a dynamic residential internet address, and what is not. You can ask them nicely to take an address off their list.

It really sounds like you should not be running your own MTA.

This is off-topic but that petition made me laugh. Not selling something that has value but was allocated at no cost and has no ongoing costs is not a "waste of funds", there's been a massive assumption made that re-addressing internal systems is a zero cost exercise, and freeing up £1bn with the aim of reducing a deficit is like taking a slash into the ocean.

In reply to a post by SteveBen:

No, that is not how it works. ISPs don't register their addresses with RBLs as dynamic/static/whatever. That is just not a thing.

I only commented on dynamically-allocated IP addresses. But LIRs can, and do, choose to provide information about their address space to third parties - including RBL maintainers - in this way, because spam proliferation isn't in anyone's interest except the spammers.

In reply to a post by SteveBen:

Do you think Zen added addresses to some magical list of dial-up addresses in 2015 when it appears it purchased them? (https://apps.db.ripe.net/db-web-ui/query?searchtext=51.155.0.0%2F16) Or do you think the DWP were adding addresses to an RBL marking them as dialup?

No, to both questions.

In reply to a post by SteveBen:

This is not a thing. RBL maintainers make their own mind up, about what they think is a dynamic residential internet address, and what is not. You can ask them nicely to take an address off their list.

Already done before making the post, as implied in it, and message successfully delivered to Asda. Thanks for the history of the IP block, I didn't know that. But I'm trying hard to think how one might successfully set up and maintain an RBL of dynamically-allocated IP addresses without any third party information about these.

In reply to a post by SteveBen:

It really sounds like you should not be running your own MTA.

I've been happily doing so for about fifteen years, but I respect your right to have an opinion about that. However, you might want to think hard about the way you convey your opinions to others, it's a useful skill when you can do that without giving unnecessary offence.

In reply to a post by GraceCourt:

But I'm trying hard to think how one might successfully set up and maintain an RBL of dynamically-allocated IP addresses without any third party information about these.

As already mentioned, checking for rDNS, checking if its an auto-generated rDNS, user reports, etc.

It makes perfect sense that if an IP has no rDNS or an automated one to block e-mail from it, as a legitimate server should have these.

Edited by alexatkin (Tue 19-Jul-22 00:45:11)

In reply to a post by alexatkin:

As already mentioned, checking for rDNS, checking if its an auto-generated rDNS, user reports, etc.

It makes perfect sense that if an IP has no rDNS or an automated one to block e-mail from it, as a legitimate server should have these.

Sure. But this IP address did have a custom rDNS, and I've subscribed to a commercial DNSBL monitoring service for years, quite successfully.
Not the most pragmatic way for Trend Micro to compile a block list to sell commercially to its many customers, such as Walmart (owner of Asda).

Asda is no longer owned my walmart. Its owned by the Issa brothers and TDR Capital

In reply to a post by GraceCourt:

In reply to a post by alexatkin:

As already mentioned, checking for rDNS, checking if its an auto-generated rDNS, user reports, etc.

It makes perfect sense that if an IP has no rDNS or an automated one to block e-mail from it, as a legitimate server should have these.

Sure. But this IP address did have a custom rDNS, and I've subscribed to a commercial DNSBL monitoring service for years, quite successfully.
Not the most pragmatic way for Trend Micro to compile a block list to sell commercially to its many customers, such as Walmart (owner of Asda).

In reply to a post by iannewson:

Asda is no longer owned my walmart. Its owned by the Issa brothers and TDR Capital

Thanks for that... my error arose out of the fact that all of Asda's e-mails to customers are still being sent from the walmart.com domain... the new owners must be paying Walmart to continue to provide that as a service.

Walmart/Asda appear to be using Proofpoint from a cursory glance. What makes you think they are using Trend Micro?

Unless you really know what you are doing you should not be attempting to run an email server from a Zen Internet broadband service under any circumstance. Even if you do know what you are doing then I would not use Zen for such a service. You should be looking at AAISP for something like that. My experience with Zen as a company is that they are not very technical.

If you are running your own system you need to be proactively monitoring deliverability and blocklists etc.

Edited by Pipexer (Wed 20-Jul-22 22:45:16)

Post deleted by GraceCourt

In reply to a post by Pipexer:

Walmart/Asda appear to be using Proofpoint from a cursory glance. What makes you think they are using Trend Micro?

The rejection message specified the RBL in question, one that our monitoring service didn't include, which is at https://www.ers.trendmicro.com/reputations.

In reply to a post by Pipexer:

You should be looking at AAISP for something like that. My experience with Zen as a company is that they are not very technical...

We were with AAISP for many years but lost all connectivity one morning for over an hour, despite being synced with the DSLAM at the local exchange, until we rang them from a mobile. It turned out that they had an administrative query so they had turned off our service (including the VOIP telephone service they were providing us with), then sent us an e-mail about it! For reasons that 99.9% will understand immediately, we didn't get the e-mail until they restored service.

Ironically, the "business continuity service" they offer, which we had considered at length, would also have been turned off with the DSL service - we changed to Zen because we need trust in our service provider and we have none in AAISP for obvious reasons.

Edit: AAISP's "administrative query" was not in any way related to an unpaid invoice or any financial issue. It was a completely unexpected, unnecessary and drastic action in the circumstances.

In reply to a post by Pipexer:

If you are running your own system you need to be proactively monitoring deliverability and blocklists etc.

We do, but only the bigger ones, which didn't include the Trend Micro DUL RBL.

Edited by deleted (Thu 21-Jul-22 13:38:43)

Apologies, wrong thread.

Edited by S2KIP (Thu 11-Aug-22 08:56:00)