No Mike we haven't. As I've mentioned earlier in this thread the only thing we are doing is checking for the existence of an rDNS record. TheChallenger is reporting that they are now receiving all of their email. The reason it stopped is due to Advascan changing the IP of their mail server and neglecting to set rDNS up correctly (which they have now done if I'm reading things correctly). We're not checking that the reverse matches the forward at the moment.

Edit: It's worth me mentioning that we are deferring the stuff without rDNS with a 4xx server error. What this means is that the sending MTA should try and attempt delivery again. TheChallenger, this also means that you should see some of the email since Thursday start filtering in assuming Advascan's servers are set up to do this.

Bob, earlier on you said that:



So how come all the mail only started arriving when they changed the ip to [217.72.243.40] so that rDNS and and forwrad DNS match, and that is the only change. How was it set up incorrectly before? What was stopping it then that makes it OK now since new emails sent through Advascan are now hardly delayed at all?

I read that they had changed the IP of their mail server and neglected to set up rDNS in a timely fashion. Looks like I was mistaken

Are you saying that the two IP addresses (both 217.72.243.40 & 217.72.243.41) have always had rDNS entries? (or at least since Wednesday of last week?).

Edit: OK been doing some more digging today and it looks like we may have an issue. This is likely to be why the Advascan emails were getting rejected.

We have a fix but in the mean time we've rolled back the ACL changes to prevent any further email from getting delayed.

I'll update Service Status shortly and will continue to keep you posted.

Yep, that's right,

Bob, thanks for doing the digging, I have always trusted Advascan, they have a very good group of techies there (even wrote own antivirus stuff) keep digging, if you need a spade we'll lend you one

I'm not suggesting that Advascan are being anything other than entirely honest but it is obviously possible for DNS to get tweaked as/when desired although changes may not propagate in anything remotely close to a timely manner. It is also possible for multiple nameservers to provide different results if there is finger trouble involved or for 'old' data to get cached somewhere along the way.  The problem in these sort of cases is that AFAIK there is no way to be absolutely sure that the DNS records haven't been modified during the period between when PN checked and found some 'error' and when someone else checked again after finding out there was a problem with receiving mail. I know for a fact in some cases that I've seen DNS changes made even though the other party is trying to tell me that they haven't touched anything and whatever the problem is, it's all down to PN ! I think it's almost inevitable that PN and the other party will always be pointing the finger at each other when there are problems with mail rejection for alleged DNS issues or someone will quietly make a few changes on the sly and hope no one else notices.

Having said that, it appears there is some confirmed PN problem with the latest checks and it's all been taken out again. Just out of morbid curiosity, what was the problem BTW ?

... wanders off singing "You put your DNS checks in. You take your DNS checks out. In, out, in, out, shake it all about"  

The problem was I stopped receiving all my email (it is all filtered by Advascan first) I forward (redirect) it out of PN and Adva forward it back in to different mailbox e.g username_scanned.

The challenge of IP's and rDNS is all documented above rDNS did respond, a forward DNS on the hostname gave a different IP (which is perfectly legitimate response ) a lot of ISP's do this, typically the forward DNS takes you to a website see above.
It's sorted for now.....

Thanks for including the pie chart.... but isn't that 1/5 BlackHole traffic?

Any estimates for random addresses landing in default 'catch-all' boxes?

That question was aimed in the PN direction rather yours, I should have made it a bit clearer so my apologies for that.

I was just wondering what the actual problem with the PN ACL was because simply testing for sender IP rDNS and accepting the transfer if found but rejecting it if missing doesn't sound like it should have caused any strange issues at all.  Any more info available Bob ?  Unless someone had a bit of 'ooops' moment and there is consequently a *very* embarrassed softy trying to hide under a desk somewhere in which case a simple will suffice !

Basically we looked at Exim just limiting the ACL checks to the rDNS checks. This was done on the back of the problem I raised following our discussions over on PUG.

A solution was suggested but it still did the forward and reverse matching. We reviewed this again and made some changes to the implementation that we believed stopped this from happening.

To cut a long story short, even with the changes in place, Exim still wanted to do the forward and reverse thing. The solution that was rolled out this morning doesn't rely entirely on Exim (we don't think this is possible now) and instead calls on an external process to do the host lookup.

Hopefully we've cracked it but please let us know if you spot anything awry. The new implementation passed a number of test conditions in the staging environment so hopefully all should be well.

Wouldn't it be a good idea to simply take an internal log of emails which would be potentially rejected by this process so that a back-end comparison could be made with the spam-checker?

Or perhaps the subject line could be marked in some way so that people would see which emails would be potentially rejected - for a week or two?

Email is PlusNet's bête noire - just an alpha test is probably insufficient.

Hope all goes well...