Test for Reverse DNS (PTR) = Hostname (A)? RSS Back to forum
@Sam Russo: There is no such feature or option in ORF which checks if the PTR name matches the A record name, because this is not an SMTP RFC standard requirement, and such test would tremendously increase the false positive rate.
@Krisztián Fekete (Vamsoft):
Hi Peter,
Thanks for the reply. I accept that ORF will not do this, it's not in the standands and your claim that false positives would be a problem.
As an aside could you comment why, then, is it commonly recommended that mail admins take the trouble to make A records match PTR records (and EHLO name)? Isn't this considered a proper configuration?
Best,
Sam
@Sam Russo: It is definitely considered the proper configuration to my best knowledge, it just that it isn't wasn't strong enough of a proof for blacklisting an email last time we checked (it is suspicious, though).
Following up, I've done some quick analysis on this technique using our ORF logs and the results are encouraging. I took the messages that Passed in ORF and then analysed the RelatedIP address of each, comparing the RelatedIP->Reverse DNS hostname->Forward DNS IP list for that hostname to see if the original RelatedIP was also in the resulting list of all IPs for that hostname. By far, most passed this forward-confirmed reverse DNS test (about 3400 out of 3500 in my sample). For the 100 or so that did not match I then looked over the list to make a guess at how many were spam (using my experienced but admittedly subjective judgement here). From this, I think a simple external agent for ORF could be made that would make 3 levels of tests, defaulting to pass any mail that matches any rule shown below. For mail that fails all tests, it is likely spam:
a) Forward-confirmed Reverse DNS (ip addr<=>hostname)
b) ReverseDNS hostname domain matches SMTP envelope sender domain
c) Small exception list for anything that fails tests a & b but we know is a good sender (I had one exception in mind for my small sample but it looks manageable and low risk)
It's too soon to say if I'd commit to using this technique but as I wrote, it does look encouraging. I'll run more logs thru to see how it goes and maybe go live one day.
I may be off base here but I think there are references to this technique in the proposed RFC 5451, Section 3. The "iprev" Authentication Method, so perhaps this is something we may see more of.
@Sam Russo: Thank you for sharing your results. It's been a while since we last checked the false positive rate on this, so we will give this a try in a controlled environment -- it is definitely possible the situation have changed and we can get this test implemented without significant false positives. There are a couple of dependencies that need to be sorted out first, but I think we can run a test in the coming weeks.
I definitely intend to be cautious with this approach. It could help me control some particularly aggressive spammers that are very creative with their designs and varying content, they are not on the mainstream RBL's or URIBL's and they use hosters so their IP changes frequently. At the current time my best defense is IP range blocks but that only works for a while and takes a bit of work to stay current and risks blocking other good senders who might use the same hosters.
Thanks again Peter for your feedback and support.
Hi,
I know ORF can check for the existance of a PTR record (Sender IP Reverse Name Validation) but can it also verify that the PTR name matches the A record name?
Example:
mail.example.com resolves to 1.1.1.1
1.1.1.1 resolves to mail.example.com
I'm not sure if such as test would have too many false positives but I know some systems that we send to have such a test as we recently failed over to a spare line where the roundtrip DNS names didn't match and some mail was rejected.
Is such an approach recommended?
Can ORF handle it?
Thanks!