ACL Email Rejection

[#1]

Guys,
We've been battling with the inbound mail delivery servers this afternoon and earlier today a priority one problem was raised as a precaution. Whilst this isn't currently customer affecting we're conscious that working into the weekend and left unattended, we could start to see issues.
We do have longer term plans for the management of spam email however as a short term measure we've decided to make an ACL configuration change that will defer (reject) messages from servers that do not have a reverse DNS address configured.
This is in a similar vain to the work that we rolled back recently that was causing all the 550 bounces. That said it's *only* going to reject email based on the one condition that the sending server has no rDNS. The original roll-out involved much more.
In a nutshell I do not see this causing much upheaval at all. Apologies for the short notice however we believe this is necessary to avoid more serious issues occurring over the coming days.
I thought I'd start this thread as I'm sure there will be some customers who have some questions or concerns regarding this work. I'll do my best to answer these.
A copy of the maintenance alert that's about to go out follows:

Quote

Emergency Email Maintenance - Thursday 4th October 6:00pm-7:00pm Maintenance Window:- Thursday 4th October 6:00pm-7:00pm. Services Affected:- Email. Duration of expected customer impact:- Approximately 1 hours. Detailed description of work to be performed:- Connections to our email platform from spam originating from non-reversible DNS addresses, are reaching the stage where left unattended they could cause a service-wide issue. To avoid this happening we will be making some changes to the ACL configuration of our email servers. This work is aimed at deferring email sent to our customers from hosts with missing reverse DNS entries. Our current mail implementation uses something called 'Sender Verify' and will already be blocking many of these messages based on invalid return paths. What we now need to do is address the messages that have been sent from valid return addresses but originated from badly configured mail servers, compromised Windows machines or botnets. This email which almost entirely originates from spam sources constitutes a very large volume of the email handled by our mail servers and it's important we begin to address this problem to preserve the integrity of the mail platform. http://en.wikipedia.org/wiki/Access_control_list http://exim-www.meulie.net/exim-html-3.00/doc/html/oview.html#SEC21 http://en.wikipedia.org/wiki/Reverse_DNS_lookup http://en.wikipedia.org/wiki/Botnet Expected customer impact:- At the moment email from IP addresses with no rDNS entries will be accepted by our email platform and delivered. The main difference following the completion of the work should be a marked decrease in the volume of spam messages accepted and delivered to customers by our email platform. It does mean that in rare instances legitimate email the customer is used to receiving will also be rejected. Probably the most common occurrence of this happens when a server administrator has forgotten to give their server a DNS entry. This means that emails generated by their website or forum for example will not arrive in customers' mailboxes. This can be easily fixed by the owner of the server that generated the email. The following RFC contains details regarding the correct DNS configuration of a server:- http://tools.ietf.org/html/rfc1033 Other Notes:- Some customers will be aware that we recently implemented ACL blocking on our mail platform however took the decision to roll the changes back:- http://usertools.plus.net/status/archive/1190742288.htm It's important to note that this work, whilst similar in nature, is expected to have only a fraction of the impact of the previous roll-out which involved far more validation than a simple rDNS lookup. We saw very few complaints following the previous roll-out that were due to missing rDNS records.

There'll be more information about our long term plans for the platform in due course, so watch this space.

[#2]

Thanks for the advance notice, and the very explanatory service status posting.
A particular problem with the inbound relays recently?  Any idea what it's attributed to?
B.

[#3]

Is this just on the Plusnet Servers? My Domains are with JTN who forward my email.. will the JTN boxes be rejecting non rDNS connections:
[tt]Received: from mail.just-the-name.co.uk (just-the-name.co.uk [213.162.97.161])
by strauss.tty.org.uk (Postfix) with ESMTP id B8E9D5EF2D
for <steve1@xxxxxxxxxxxxx.plus.com>; Thu,  4 Oct 2007 19:22:35 +0100 (BST)
Received: from ms53.hinet.net (unknown [201.216.179.171])
by mail.just-the-name.co.uk (Postfix) with SMTP id A00624066FF
for <steve@xxxxxxxxxxxxx.org.uk>; Thu,  4 Oct 2007 19:18:32 +0100 (BST)[/tt]

[#4]

It's all going to go belly-up again

[#5]

Quote from: axisofevil

It's all going to go belly-up again

Got to admire your optimism!
Seriously though, don't speak too soon as I'm sure this really isn't going to have a lot of negative impact at all.
SteveA, this is just on mx.last.plus.net and mx.core.plus.net so the JTN boxes remain the same.

[#6]

Quote from: Bob

SteveA, this is just on mx.last.plus.net and mx.core.plus.net so the JTN boxes remain the same.

It really would fix ALL my spam problems 
I've been checking my spam headers when I've been sending them to SpamCop and every one of them has come from a compromised PC with no proper rDNS

[#7]

No proper rDNS or no rDNS at all? The changes made to the PN platform are only tackling hosts with completely missing rDNS.

[#8]

Quote from: Bob

No proper rDNS or no rDNS at all? The changes made to the PN platform are only tackling hosts with completely missing rDNS.

I double checked and a significant number of them have no rDNS
Of course accepting mail from rDNS hosts means that you aren't going to stop hinet.net and 163data.com.cn  unless you reject anything with the word dynamic in the rDNS string
Have you looked at the SpamCop Hostname Report?

[#9]

I'll ask around and see how easy it would be to implement something similar on the JTN servers.
Agree with the point about dynamic IP blocking - We're currently working closely alongside 3rd part providers to implement a long term spam solution to tackle this kind of stuff (unfortunately JTN may miss out on this one though too I'm afraid!).

[#10]

Quote from: Bob

Apologies for the short notice however we believe this is necessary to avoid more serious issues occurring over the coming days.

Bob,
So what do you see in the crystal balls at PN for this to be done preemptively?
SW.

[#11]

It causes a wealth of issues when our mail exchangers stop accepting new connections. Email delays being the obvious one but it can also cause messages to be rejected where the receiving server uses sender-verify. It also compounds the problems we get from time to time with the anti-virus and anti-spam processes on the platform. We're erring  on the side of caution as we're aware that spam levels are going to increase in the run up to Christmas and we've seen some unusual patterns across the mail queues since removing the original ACL blocking.
Yesterday there were extended periods of time where our mail servers were not accepting connections. Things aren't 100% ideal now even with the blocking as I'm periodically having problems telnetting to the mail platform

bpullen@pvs-csctools:~$ telnet mx.core.plus.net 25
Trying 84.92.2.1...
telnet: Unable to connect to remote host: Connection timed out

[#12]

I am baffled.
Since a bot infected PC finds it possible to read the address book  to provide a source of destination emails. Can it really be so difficult to be able to read the configuration file of the (almost guaranteed) Microsoft Outlook?
If the clever bot can do that, it will discover the name of the smart host and will use it.
This means that the rDNS lookups are a waste of time.
BTW I've never tried to write one of these bots - but once it is up and running it sounds very difficult to stop it.
Why do PlusNet bother?

[#13]

Quote from: axisofevil

Why do PlusNet bother?

Because the fact remains that customers receive spam from hosts without an rDNS entry. This thread on the Usergroup forums is testament to that.

[#14]

But I sometimes receive spam in months with an "r" in them.
But I don't use this as a basis for recognition of spam.
Just because some spam doesn't have proper rDNS doesn't mean that there are people wanting emails even if the rDNS is flawed.
BTW I have elected to not have my emails spam-checked. Is it possible to make the SMTP servers do a lookup against my account (using the to-address field) to see if I want to accept all email? This would allow those people who see email as a necessity to be insulated against future changes.

[#15]

Quote from: axisofevil

I am baffled. Since a bot infected PC finds it possible to read the address book  to provide a source of destination emails. Can it really be so difficult to be able to read the configuration file of the (almost guaranteed) Microsoft Outlook? If the clever bot can do that, it will discover the name of the smart host and will use it. This means that the rDNS lookups are a waste of time. BTW I've never tried to write one of these bots - but once it is up and running it sounds very difficult to stop it. Why do PlusNet bother?

That is a point I made somewhere else. Blocking spam from machines that have dynamic IPs, flawed or missing rDNS entries or no MX records (only really useful for checking the first upsteam mail server) will only work as long as spammers use their "own" mail server on the compromised PC. As soon as they realise these are being blocked on any large scale they will refactor their code and use the ISPs mail servers for relaying it.
So any changes Plusnet and other ISPs make will give you 6-8 months breathing space