ACL Email Rejection
Hmmmmm, I sure hope that doesn't mean PN have gone back to playing around with the bl**dy silly (IMHO) double rDNS checks again because the only oddity appears to be:
[217.72.243.40] --> "uk.advascan.com" --> [217.72.243.40] which is OK
but
[217.72.243.41] --> "uk.advascan.com" --> [217.72.243.40] which isn't OK
and is just one of many reasons why this kind of check is right old PITA in reality even if it might be technically wrong to have 'dodgy' looking DNS entries like that.
Having 'dodgy' looking DNS does not indicate a spammer it merely indicates either incompetence or a deliberate attempt to refer any attempted incoming connections elsewhere, such as to a website as this appear to be. I have seen way more than a few e-mail sender IPs that resolve to a website or some other more appropriate system which I believe was one reason why I had a fair old number of problems with lost mail when the double rDNS checks were active.
... wanders off to get a Lou Ferrigno haircut (but then again, maybe a wig would be more appropriate !), find a tin of green paint and muttering "don't make me angry, you wouldn't like me when I'm angry"
[217.72.243.40] --> "uk.advascan.com" --> [217.72.243.40] which is OK
but
[217.72.243.41] --> "uk.advascan.com" --> [217.72.243.40] which isn't OK
and is just one of many reasons why this kind of check is right old PITA in reality even if it might be technically wrong to have 'dodgy' looking DNS entries like that.
Having 'dodgy' looking DNS does not indicate a spammer it merely indicates either incompetence or a deliberate attempt to refer any attempted incoming connections elsewhere, such as to a website as this appear to be. I have seen way more than a few e-mail sender IPs that resolve to a website or some other more appropriate system which I believe was one reason why I had a fair old number of problems with lost mail when the double rDNS checks were active.
... wanders off to get a Lou Ferrigno haircut (but then again, maybe a wig would be more appropriate !), find a tin of green paint and muttering "don't make me angry, you wouldn't like me when I'm angry"
Quote from: TheChallenger 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.
Quote from: Bob 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?).
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"
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"
Quote from: TheChallenger
Quote from: mikeb Just out of morbid curiosity, what was the problem BTW ?
The problem was ...
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.
Quote from: Bob
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...
