funkychunky, don't worry I'm still here. I've whitelisted the IP in the email you sent me.

Anyway, here goes...


I would like to see us using the dul.dnsbl.sorbs.net and pbl.spamhaus.org (or xen.spamhaus.org) lists. I have suggested this and raised an internal task however as yet neither list has been implemented.


I did announce this to the Usergroup before it happened and the Service Statuses/Blog posts went out here,  here and here. Admittedly though, little time was left for feedback. TBH I didn't expect the number of reports I'm seeing here (especially not the ones that need whitelisting). I think this is down to the blocking based on /subnet/. When the system identifies multiple IPs of a dynamic origin that fall in the same subnet then it blacklists the subnet. We're seeing examples where isolated IPs (mainly from lesser known hosting companies) are planted in the middle of large subnets of dynamic addresses. It's these that need whitelisting. A lot of the other stuff is being rejected for genuine reasons and working to design. We're reviewing what to do with this subnet policy now as we're not happy with where we currently at as we go into the weekend.


Any suggestions as this is quite easy to do?


I wonder if that's because the rDNS of the IP maps back to your www. address and not your mail server?

bpullen@pvs-csctools:~$ host 207.36.208.184
184.208.36.207.in-addr.arpa domain name pointer www.moonpod.com.


I've emailed Netserve and their mailservers should be whitelisted. I've asked them to mail me back with confirmation.

... Phew! 

Thanks Bob, obviously when i got no reply I though nothing was done.   
I will get cleint to test and inform of any other blocks in due course.

 

So what are you going to do about my problem:

I have a server I use to send out emails
It has multiple domains hosted and emails are sent from each domain.
I can't use a smarthost (BT) or any relay mail server
I don't have MX records set-up because the box is not a mail server and I do not want to receive mail for the domains.

This all worked perfectly before your mail changes. It can no longer send emails to my PN email addresses.

Why can't you?

I followed the links in your post but didn't learn what source you are using for the dynamic addresses to reject.

Could you tell us? Is there a mechanism for self removal, other than the PN only manual one?

I think the records are drawn directly from the RIPE database and Plusnet generate the rest of the information.

Well, as I understand it a relay server should have a name. This doesn't have to match the domain of the email addresses.

What would be wrong with relay.petervaughan.net  (or some other)?

I don't have any email addresses which match relay.plus.net

Oh dear..... (if thats true). They are not necessarily accurate.

Peter, I have advised what needs to be done to sort this and you have readily admitted yourself that this is possible on both the BT and the PlusNet line.

As it happens, we have added all the PlusNet IPs to the whitelist but the rejecting we're doing now you will have problems with as more and more mail admins start implementing similar measures.

Regarding where we get the dynamic IPs from, we don't!

That's the whole point of this exercise, we're building a list ourselves which is by far the more favourable option as we then have full control over it. What it does mean though is that it will take some time to bed in and we need to be on top of the white list requests.

The long term benefits of this work are immense even considering the short term pain.

Bob, I agree 100% with doing this, but I also understand the pain its causing the businesses who have clients mailing them to their PlusNet address. What is the solution for these people? (They can't really turn round to their clients and say "I'm not talking to you until your hosts fix their mail server configurations")

Just looking at it from their POV.

How; when you get and IP address that's not in your database how do you determine if its dynamic or not?

Hi everyone, it's my first posting (but not my first read!) on the Community site although anyone who also uses PUG will know who I am from there, for those who don't a quick introduction from me before I go into the Dynamic IP blocking issue.

I've been at PlusNet now for just over 18 months and took over responsibility for the whole team around 6 months ago. Prior to joining PlusNet I worked for BT and was responsible for the design of their Broadband network. I've been working with Broadband technologies since before the launch of ADSL in the UK in 2000, so I've seen most things!

Firstly, let me explain exactly what we've implemented so that everyone understands what we've done and why we've done it.

On Monday this week, we rolled a set of changes to a single machine in our secondary inbound e-mail cluster (MXLast), then on Tuesday we rolled it to the whole of the secondary cluster; finally it was rolled to the primary cluster (MXCore) on Thursday. These included a number of performance improvement changes as well as a change to the way we deal with dynamic IP addresses.

These changes mean that we now scrape the inbound e-mail logs for all messages and check to see if the forward and reverse DNS match and also that the IP address is not in a dynamic range. If the sending machine has a DNS issue or is on a dynamic range we add that range into a database and then blacklist mail coming from that IP or range of IPs.

We are not the first ISP nor do I think we will we be the last who are being forced to implement this type of blacklisting due to the number of bots sending e-mails from infected machines.

As an example of the impact of these changes, we receive 1,600 connection requests per second per inbound e-mail server (there are 22 in total!). Prior to this change we were blocking around 50% of these connections via RBLs and existing checks. Once this rolled out, we were blocking 75% of these connections, of which a tiny proportion are legitimate.

It is the tiny proportion of legitimate ones that are causing the concern for us all at the moment and we are doing our best to make sure that these are sorted out as quickly as possible by whitelisting them on request.

 This is one of the reasons that we chose to implement the blocking ourselves as it means that we have full control over whitelisting the addresses and these are being turned around within 24 hours. If you need to have an address whitelisted, it's simply a case of sending an e-mail to abuse@plus.net with either the e-mail headers of the servers IP address and it will be added.

The abuse mailbox is being monitored and requests are being dealt with over the weekend so there will not be a delay there.

I'm sorry that this has caused more inconvenience than we'd have liked, but I hope that you will agree this is a necessary piece of work to combat the spam problem that is growing bigger all of the time.

If anyone has any questions please feel free to post them and I'll make sure I do my best to answer them.

Phil

Because BT will not allow me to use their mail servers for sending mail for domains they have no knowledge of and in the past it has taken weeks to convince BT to accept 1 domain for another client, let alone 20!

This is not an option for me.

I reiterate that I do believe that Plusnet have taken a necessary step, however I feel that the method used to roll it out was flawed.

With community assistance, this could have been made much simpler.  Phil, your explanation is comprehensive but I personally would have appreciated some advance notice of it.

As has already been noted, both AOL and Hotmail already implemented this some time ago.  If all ISP's implemented this methodn then spam would reduce dramatically.

With email being a particular bone of contention at the moment, it would have been well advised to involve the community in some fashion.  Please, please, please take that under advisement.  It is difficult to be able to advocate your position abd defend it when all the changes are very cloak and dagger.

That being said, I sincerely hope that this is the start of a more resilient and reliable email platform for Plusnet customers to enjoy

B.

Setting a policy for accepting email which can be objectively defined seems like a great step forward. Only accepting connections from bone-fide mail servers should exclude SPAM but for any attack on said servers or their otherwise legitimate users.

This has to be better than the vague and ever shifting content filtering.

The question remains though as to the quality of the implementation of any such policy.



So:

• How do you accurately determine which IP's are dynamic?
  How do you keep up with all the changes. The internet has a lot of address ranges and their allocation and usage is being updated all the while?
  Do you age blocked IP's when 'genuine' DNS problems are addressed?
  Why do you think that your 'go it alone' approach will be more accurate than sharing the load with others such as the Spamhaus PBL?

By comparison the Spamhaus PBL is updated every 15 minutes and offers a self service IP removal tool for those who find their relay’s IP address is included.

Oh, and ahy didn't you make the changes clear before implementation?

Ok, to answer your questions.....


-How do you accurately determine which IP's are dynamic?
-- I will have a look at the Change Control and the code changes and tell you everything that we check as there are a number of things that we look at.

-How do you keep up with all the changes. The internet has a lot of address ranges and their allocation and usage is being updated all the while?
-- We are continually monitoring the logs to look for occurrences of valid e-mail being blacklisted. Also, it is not a common occurrence for a dynamic range to be changed to a static one.

- Do you age blocked IP's when 'genuine' DNS problems are addressed?
-- We will whitelist any IP address if an e-mail is sent to abuse@plus.net even if the IP is in a range found to be dynamic as it is possible that it really is a static and the set-up is not fully compliant. If someone is willing to take the time to e-mail us to be whitelisted, it's unlikely they are a spammer. If they do turn out to be a spammer, we have other safeguards in place to monitor volume of messages from IP addresses etc.

- Why do you think that your 'go it alone' approach will be more accurate than sharing the load with others such as the Spamhaus PBL?
-- For the reason I gave above, by doing it ourselves (which I believe most people do) we have total flexibility to whitelist even though Spamhaus may not as it does not conform their policy.

- Oh, and ahy didn't you make the changes clear before implementation?
-- We did put some comms out http://community.plus.net...g-email-platform-changes/ however on reflection these were far too vague and we should have been more explicit about the changes. This is definitely something I will make sure we do better next time. The reason that we were not more explicit in our comms is that the type of blocking we have implemented was already in place before although to a lesser extend and we did not expect the level of legitimate mail being caught due to dynamic addressing or DNS issues.

Phil