Hello,
I have noticed that at MailEnable Management>Messaging Manager>SPAM PROTECTION in ME Premium V5.02, specifically there is one check called "Has no reverse PTR".
I would recommend that Spam Protection is upgraded and have an extra check regarding reverse PTR. And this is if a PTR is bad configured, has a CNAME record instead of an "A" record, or if simple the reverse PTR results on the ISP provider instead of the owner of the mail server. (Kind of the SPF, in Spam Protection exists: Passes SPF, Fails SPF, Softfail SPF, error SPF).
Because almost all 'Best Practices' documents say that the reverse DNS should resolve to the responsible party for any email or traffic that comes from that IP Address; meaning that the reverse PTR should resolve back to the IP sending the messages and should not resolve to the ISP or any other third party that is not responsible for the mail server.
For instance, take a look at this reverse PTR lookups:
Scenario 1: http://www.dnsstuff.com/tools/ptr?ip=14 ... 1f3a9dd01a
This has a PTR Record but there is no an "A" type record for that reverse PTR result, which is completely incorrect.
So there should be an option similiar to Fails SPF, could be Fails PTR (because the IP has a PTR but fails since there is no "A" record).
Scenario 2: http://www.dnsstuff.com/tools/ptr?ip=88 ... 160e183019
If it resolves to 'server88-208-230-50.live-servers.net' this would mean that the upstream provider is responsible for the content from that IP, which it isn't. The administrator of the mail server for RFL.UK.COM is responsible.
This type of incorrect reverse PTR is documented as wrong (again) in almost all the BEST PRACTICES documents:
http://www.linuxmagic.com/best_practice ... e_dns.html
Again there should be an option similar to Softfail SPF, could be Softfail PTR (because the results brings us to the ISP instead to the Administrator of the mail server).
Scenario 3: http://www.dnsstuff.com/tools/ptr?ip=20 ... 19066fa010
Mailenable IP resolves PERFECTLY as it should be. Has an "A" type record and this record is "mailenable.com" which resolves back to MailEnable and not the ISP for MailEnable, which is the best practice. So this would be a 100% positive result.
This is a perfect example of a PASSES PTR!
There is another Scenario, in where some reverse PTR lookups show that some mail servers have CNAME configured instead of "A" type records. This would be similar to the error SPF, could be called error PTR.
If MailEnable apply this set of Spam Protection in the reverse PTR tests (not only verify if a PTR exists) would result in catching more spam making MailEnable one of the leading products with the best Antispam integration possible.
In addition, some other antispam features like this one would be great:
http://forum.mailenable.com/viewtopic.php?f=7&t=20092
Would like to know what do you think about this Mailenable and other users?
Thank you.
Login