Why does not ORF do “real Reverse DNS”?

Proposed Dialog Layout for the Reverse DNS TestWell, that is an easy question. The answer is 3.2%.

The “Real reverse DNS test”—that is, checking whether the sending server has a DNS name—is in the Top 10 requested features since years. So far we resisted adding it to ORF, due to the high false positive rate and once or twice a year I ran a test on our legitimate email sample body to see whether the false positive figures changed. My last test was performed on ORF tech support emails from the last 45 days and the false positive rate was an unacceptably high 3.2%.

Sure, we can treat this type of test a policy enforcement tool instead of a spam filter, but come on, who want to lose 3.2% or even 0,5% of the legitimate emails? Yes, we could add a big flashing warning sign telling “You will shoot yourself in the foot”, but I think it is better not to allow the user to shot herself in the foot at the first place.

What do you say?

13 thoughts on “Why does not ORF do “real Reverse DNS”?

  1. Kurt (EC)

    I think it’s a marvellous idea.
    I get over a 30 million of spams a month, so I’m really tempted by the third option :))

  2. allianz

    I think we can be smarter here. I think the reverse DNS test you refer to is one where:
    looking up the hostname of the sender IP address gives you a DNS name that matches the one in the envelope return path.

    This has a high false positive rate because many small senders either do not have a permanent IP address or have not requested that their ISP add appropriate RDNS entries in their DNS databases.

    It also fails for a surprisingly high number of big senders. Do an RDNS on email sent via attglobal.net and the answer is prserv.net. Large companies often own multiple domain names and may in fact have multiple public identities as a result of mergers and aquisitions.

    There is however a simple way to improve on the test. If I do a DNS lookup on attglobal.net for their MX I get: mx2.prserv.net, mx1.prserv.net and this matches the name resolved by the RDNS.

    You can also exclude any sender who has passed the SPF test from needing the RDNS test.

    My analysis shows however that there are still a few legitimate senders who would fail this combination of tests.

    Even at this point there is another test you can do. Every IP address falls within a range allocated by one of the 4 regional internet registries. These registries publish a database available by FTP (as well as providing whois access). I wrote a program to extract the combined database, it is about 5mb in size and does not change very frequently. It has entries for each allocation, for example mail from attglobal.net from an IP address like Look this up in the database (or whois.arin.net) and you get:

    ATT MIS IP-WCS OPERATIONS CTRS ATT-MIS-44-55 (NET-12-154-55-0-1) = –

    Now if you also use DNS to look up the MX servers e.g. mx2.prserv.net, mx1.prserv.net above are given at and If just one of these is within the allocated range as both are, then you pass the test.

    In my analysis the number of spams passing this test as well as other ORF tests was less than 1 in 10,000. For any that did get past, you would only have one entity to complain too, and if that did not work, a single IP address range to block.

    It is hard to determine the false positive rate from these tests, but I think that it is a lot lower than 3.2%. It would also vary user to user. If you have to be open to the general public, you may not want this test, or you may want it to simply tag or redirect.

    If you mainly deal with other businesses like myself, then you would simply block them.

  3. David L. West

    I agree that requiring the rDNS entry to match anything in particular will result in lots of false positives. What I want is the option to block anything where there is no DNS entry at all. I know Yahoo does this, and I suspect other big providers do it. I quite realize some small fry will not have the wit to have rDNS for their mail servers, but I think that pool is shrinking by the day.

    As long as it respected the other whitelists, I think having the option to required a non-null rDNS would be beneficial to many users.

  4. Frank

    Correct me if I’m wrong: ORF’s current so-called “Rerverse DNS” test takes the domain as specified in the MAIL FROM (the SMTP envelope Sender email address) and performs a DNS lookup on it to see if it has an MX record published (the “strict check”) or atleast an A record (the “normal check”). The proposed rDNS test would perform a DNS lookup on the Sender IP address and it should resolve to a domain name. Could (or must) that domain match the domain in the Sender email address, the HELO, or the MX? Is it a good idea to rDNS the HELO domain or at least require it to have an A record?

  5. Peter Post author


    Actually, this test would check only whether there is name for the IP (reverse DNS, a.k.a PTR record). For instance, resolves to colocation.vamszoft.hu, but some other IP addresses that send email do not resolve to a DNS name.

    The 3.2% rate above refers to the percentage of IPs in the legit email sample that did not have name assigned to the IP.

    As for checking whether the MX IPs fall into the same netblock (either determined by WHOIS or just using an e.g. /24 fixed definition) is an interesting idea, however there is technically no relation between the outgoing email server IP and the inbound MX IPs. SPF and Sender ID were invented exactly to fill this gap.

    I think the RDNS test and the test you suggested could work very well in a rating system, but not in ORF.

    [BTW, these could be implemented as External Agents]

  6. Peter Post author

    David, I got the 3.2% false positive rate with the method you suggested. I know there are a bunch of servers who use this type of validation and similar ones*, but I am not sure if we should allow this in ORF. In any case, a relatively simple External Agent can do the trick–we pass the IP to be checked.

    * Some servers bring this test further and resolve the IP to name, then resolve the name again into an IP and the two IPs has match.

  7. Peter Post author


    Correct, the RDNS test in ORF works the way you described and the proposed test would merely check the existence of the name for the IP.

    The name got from this test may not match/fall into the sender domain, because your outgoing mail server may be in a different domain than the sender domain. For instance, we send emails from a couple of domains (vamsoft.com, vamszoft.hu, vaminfo.hu) and our outgoing email server is colocation.vamszoft.hu.

    Doing any DNS on the HELO domain is a bad idea, because legitimate servers often announce their internal DNS name as the HELO domain and testing for funnyservername.internal.domain will fail.

    I wrote about my concerns with the MX testing in my comment for Allianz.

    The problem is, all these tests would require the sending IP to resolve into an IP, so we start with 3.2% false positives.

  8. allianz


    You seem to think that I was lobbying for an enhancement to ORF. I gave up doing that a long time ago. The next enhancement by your own choice will be 64bit support.

    I was simply pointing out that if you were to go down the route of doing a true RDNS without getting into a total rewrite of ORF to make it scoring based, then one way of doing this would be to put it after the SPF test as follows:

    1. SPF test passed -> no further tests.
    2. RDNS resolves to a domain == envelope sender domain -> no futher tests.
    3. Further tests.

    The further tests I was proposing was a relationship test based on NETBLOCKS. Earlier on you probed the envelope sender domain for MX and A entries. If any of these are in the same NETBLOCK as the sender IP then pass the test.

    I was simply pointing out that based on my own research there were almost no false positives to this test in over 3 years of usage. The one I did have, a long time ago involved someone trying to run an SMTP MTA from a laptop that moved around from place to place.

    There might still be some users out there who feel they have the right to send mail from anywhere with a return path to an unrelated entity (e.g. an email they were given for life while at college), but in my experience this just does not happen.

    I suscribe to a very large number of ezines etc. and all of these pass the test.

    In the arguments being put up in the noe defunct MARID forum, there were a lot of people arguing against SPF for the very same reasons, and they were deeply passionate about it.

    What they need to understand is that if I want to block a category of email, that is my perogative and I kind of resent anyone trying to but in and say: “wait a minute, we will not allow you to do that”.

    The proposed test may never make it into ORF, but this is another matter. If Spamhaus get their proposed ZEN/PBL lists going (that incidently are also NETBLOCK based), then the need for any futher tests may simply vanish altogether.

  9. Steve

    The feature should be added for the following reasons…

    1) Brings Microsoft’s SMTP services on par with that of Exim, Sendmail, .etc

    2) It has been on the customer’s top 10 wish list for years by your own admission

    3) Vamsoft shouldn’t been seen as resistent based on statistical data gather from just their site. For example, statistics gathered from my site for 60 days and supplied to Vamsoft on Nov 7, 2006 show a 73% reduction of UCE if I could reject during the “Before Arrival” event. In order that I didn’t erk the pointy haired boss, I would have had to whitelist 2 servers because the failed rDNS look ups based on the way Microsoft marks the header.

    In closing, let me leave you with this thought… Spam prevention is just that, policy enforcment of what is acceptable behavior. The feature is just another option like so many options in a great product like ORFEE that it can’t hurt to add it. Those that run their servers will make the right choice. Those that don’t will be applying for another job once the smoke clears.

  10. Peter Post author


    Maybe I misinterpret your proposal, but I certainly do not think that it is right to send emails from any host in the name of a domain that tells otherwise. SPF is a great tool for domain administrators to claim back the control for their domains.

    What I am more concerned of is the scenario when someone uses an unrelated email provider. One possible example is email campaing providers, who send emails on behalf of their client (and client domain), but do protocol-level bounce handling themselves. This, and having inbound MXs on a different network block than outbound ones are technically OK.

    I should emphasize that I do not claim that this test would have a high false positive rate (in fact, I think the opposite) and I am sure that it would have an excellent spam catch rate, it is just that technically it is not fully reasonable.

    Anyhow, I would love to see this as an experimental External Agent. ORF can pass any parameters required by this test (except for test completion results, but they are not really needed anyway).

  11. Peter Post author


    Thanks, we will consider this. Actually, I already promised the PTR test a few months ago on the ORF newsgroups, but I never really felt it OK…

  12. Chris

    We’ve been blocking on no PTR for a few years now. The false positive rate for the past 18 months is 0. I truly mean 0. I’m guaranteed now that when I block on no PTR, I’m not blocking any legit mail. When AOL and Yahoo started enforcing this or at least announcing they were enforcing this, I knew we had made the correct decision.

    Furthermore, we analyze the PTR for strings that indicate the mail came from a dynamic block — ppp, cpe, dial, dsl, pool, in-addr-arpa, etc. Those pretty much get added to our own DNS blacklist. It would be nice to have that feature available. The false positives from those are so small (maybe 1 in 100,000 message blocked from those strings) as to make it very worthwhile.

Leave a Reply

Your email address will not be published. Required fields are marked *

AlphaOmega Captcha Classica  –  Enter Security Code