Blacklisted PlusNet Subnet 195.166.150.0/24

[#1]

I follow SPF, DKIM and DMARC email policies and check regularly that nobody is blacklisting my IP address. The little server I run here is a very well-behaved internet citizen.

I note today with dismay that during a blacklisting check, PlusNet's 195.166.150.0/24 subnet is currently appearing on a blacklist.

The blacklist in question here: https://www.uceprotect.net/en/rblcheck.php

This blacklist is in use, it shows up on the popular mxreport.com tool - therefore, I think this is an issue PlusNet need to resolve as a matter of urgency. This blacklisting will damage the reputation and/or connectivity of ALL users with servers on this subnet.

I look forward to hearing your response. I will continue to monitor blacklists as a matter of course.

[#2]

That looks like a strange hostname - PN mailhosts (AFAIK) are identified 'mail.plus.net'

[#3]

Think you misunderstand - that's MY hostname, my IP address. Which is why I'd like PlusNet to do something about my subnet being blacklisted.

[#4]

Ooops, sorry.

@bobpullen ?

[#5]

Could well be they've already taken action.

Someone else on my subnet has been a naughty net-citizen - I'd like to know they've been appropriately dealt with, before other servers refuse to talk to mine (!)

[#6]

Risk that needs to be accepted really when relaying mail directly from a consumer ISP's IP ranges

We don't really have much direct control over a list owner arbitarily putting hundreds of our IP addresses on the naughty step, presumably based on spam reports from a few. Also highly unlikley those assigned the offending IP's were doing anything intentional. Much more probable that they were subject to some sort of malware/takeover. 

[#7]

Is this spreading? I have today had one of my outgoing emails rejected by a business Office 365 mail server - first time that has happened.

FROM <My IP address>.plus.com

Reported error:

550 5.7.360 Remote server returned message denied by administrative policy -> 550 Administrative prohibition - envelope blocked - https://community.mimecast.com/docs/DOC-1369#550 [cykcxQ8-OjCTuNuzxZ2sJA.uk166]

Mimecast SMTP Error Codes

"550 Local CT IP Reputation - (reject) Ongoing reputation checks have resulted in the message being rejected due to poor IP reputation. This could occur after a 4xx error."

Perhaps it's time for Plusnet to be more concerned about its reputation?

[#8]

---

@pvmb wrote:

Reported error:

550 5.7.360 Remote server returned message denied by administrative policy -> 550 Administrative prohibition - envelope blocked - https://community.mimecast.com/docs/DOC-1369#550 [cykcxQ8-OjCTuNuzxZ2sJA.uk166]

---

From your linked document (which contains a number of 550 definitions)...

550

Administrative prohibition envelope blocked

The sender's email address or domain has triggered a Blocked Senders Policy or there's a SPF hard rejection.

Can you be sure that the receiving environment is not misapplying SPF rules?  We have seen such before.

[#9]

@pvmb - are you running your own mail server?

[#10]

If that’s the case, then using relay.plus.net as a ‘smart host’ should in theory work around the issue, as far as I’m aware and understand things though. 

[#11]

I'm not running my own email server, it was just an email sent via the Plusnet online email system.

[#12]

The plot thickens:

spf:plusnet.com:<my IP address>

For plusnet.com "No SPF record found"

https://mxtoolbox.com/SuperTool.aspx?action=spf%3aplusnet.com&run=toolpage

"Hostname unable to find a SPF Record

SPF records must be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035]. See RFC7208 for further detail."

"Reported by ns1.force9.net on 3/12/2022 at 7:25:06 AM (UTC -6), just for you"

"ns1.force9.net" Uh?

https://mxtoolbox.com/whatismyip/?justforyou=1

<my IP address>.plus.com

"Blacklist
Problem Icon
Result
You are on 1 blacklist: Spamhaus ZEN"

Ah! So what's that about?

More Information About Spamhaus Zen
Inclusion in the Spamhaus-ZEN Blacklist results from sub-listings in one or more the following Blacklists:

CBL - You have contracted a virus or malware that is operating a botnet, either on your email server on a workstation behind the NAT - Continual delisting requests without eliminating the virus will result in permanent blacklisting

XBL - (Spamhaus Exploits Block List) is a real-time database of IP addresses of hijacked PCs infected by illegal 3rd-party exploits, including open proxies

PBL - Spamhaus PBL is a DNSBL database of end-user IP address ranges that should not be delivering unauthenticated SMTP email to any Internet mail server except those provided for specifically by an ISP for that customer's use
Spamhaus Zen Reports Dynamic Ip Addresses

Spamhaus Zen Requires A Manual Delisting Request
This blacklist does support a manual request to remove or delist your IP Address from their database. Please note that removal requests that are submitted without addressing the core problem will likely result in your IP Address or Domain being relisted in that database, which can cause subsequent problems and extended listing periods without release.

More information about Spamhaus ZEN can be found at their website: http://www.spamhaus.org

Reason for listing - No Details Available

But Spamhaus Zen is reporting "No issues" with plusnet.com, <my IP address>.plusnet.com or <account name>.plusnet.com

The returned email headers (I estimate between 10 and 20 times longer than my email text!) seem to show they object to my Plusnet account name (as in email) as unrecognised.

So, perhaps they are rejecting emails that are simply not known to them and listed - which seems pretty daft as it is a publicly published business enquiry email address!

[#13]

SPF records must be published as a DNS TXT

That does not mean that there MUST be a SPF record, but if one is present it must be published as a DNS TXT record (not the deprecated DNS SPF record).

From RFC7208

Although this feature is desirable in some circumstances,
   it is a major obstacle to reducing Unsolicited Bulk Email (UBE, aka
   spam).  Furthermore, ADMDs (as described in [RFC5598]) are
   understandably concerned about the ease with which other entities can
   make use of their domain names, often with malicious intent.

   This document defines a protocol by which ADMDs can authorize hosts
   to use their domain names in the "MAIL FROM" or "HELO" identities.
   Compliant ADMDs publish Sender Policy Framework (SPF) records in the
   DNS specifying which hosts are permitted to use their names, and
   compliant mail receivers use the published SPF records to test the
   authorization of sending Mail Transfer Agents (MTAs) using a given
   "HELO" or "MAIL FROM" identity during a mail transaction.

   An additional benefit to mail receivers is that after the use of an
   identity is verified, local policy decisions about the mail can be
   made based on the sender's domain, rather than the host's IP address.
   This is advantageous because reputation of domain names is likely to
   be more accurate than reputation of host IP addresses since domains
   are likely to be more stable over a longer period.  Furthermore, if a
   claimed identity fails verification, local policy can take stronger
   action against such email, such as rejecting it.

SPF is desirable, not mandatory and is very dependent to the RECEIVING mail service applying the rules in a complaint manner.  The big question here boils down to "Is the receiving email service correctly handling the absence of a (not mandatory) SPF record correctly?

All that said, you would need to be inspecting youraccount.plus.com for a SPF record or your hosted domain name if you have one.  If you do have a hosted domain name, you can use an undocumented fudge in the DNS configuration options to generate a SPF record...

Additional DNS records (Advanced)

Left field	Type	Pri	Right field
	mx	999999	please-add-spf-records

[#14]

---

@bobpullen wrote:

@pvmb - are you running your own mail server?

---

@pvmb states that they are not.

However @duncanmackay 's OP infers that he is.

[#15]

---

@pvmb wrote:

I'm not running my own email server, it was just an email sent via the Plusnet online email system.

---

Then your problem is unrelated to this thread.

@pvmb wrote:

For plusnet.com "No SPF record found"

Why are you searching SPF records for 'plusnet.com'? Where does plusnet.com come into the equation?

Regardless, I don't believe we publish SPF records for customers' username.plus.com email addresses, in which case there simply can't be a 'SPF hard rejection' as inferred by the rejection message you recieved.

@pvmb wrote:

<my IP address>.plus.com

"Blacklist
Problem Icon
Result
You are on 1 blacklist: Spamhaus ZEN"

Ah! So what's that about?

More Information About Spamhaus Zen
Inclusion in the Spamhaus-ZEN Blacklist results from sub-listings in one or more the following Blacklists:

CBL - You have contracted a virus or malware that is operating a botnet, either on your email server on a workstation behind the NAT - Continual delisting requests without eliminating the virus will result in permanent blacklisting

XBL - (Spamhaus Exploits Block List) is a real-time database of IP addresses of hijacked PCs infected by illegal 3rd-party exploits, including open proxies

PBL - Spamhaus PBL is a DNSBL database of end-user IP address ranges that should not be delivering unauthenticated SMTP email to any Internet mail server except those provided for specifically by an ISP for that customer's use

This is referring to your broadband IP address and has no bearing on email delivery if you are sending messages via the Plusnet Webmail service. I fully expect large parts of our IP space to be on the PBL list for the reasons highlighted above.