Questioning the Use of PTR Records as SMTP Verification

[dkovacevic]

Why are PTR records used to verify an SMTP server's client, as opposed to having the server do a simple lookup on the FQDN provided by the client in the HELO exchange?

For example, there is an SMTP server authoritative for domain “example.org”. A spammer connects to it from IP 1.1.1.1. In the HELO exchange, the spammer provides “ns1.yahoo.com”.

From a security perspective, it makes sense to verify this name against the IP address. Why are PTR records used to do so? Why does the SMTP server not simply query its DNS forwarder for “ns1.yahoo.com” and compare the IP to the spammer's IP (1.1.1.1)?

 

[ShelLuser]

Why are PTR records used to verify an SMTP server's client, as opposed to having the server do a simple lookup on the fqdn provided by the client in the HELO exchange?

First of all you have to realize that there are no official rules for all this. Some check PTR records (my own MTA's do the same) while others may perform other checks instead (think about SPF for example).

As to your question, there are two important reasons. First: speed. The time it takes to detect that a PTR record isn't available for a certain IP address is much shorter than having to check if a certain domain actually exists at all.

The problem here is that a client can provide just about anything in the initial HELO exchange, the name doesn't even have to exist.

And that leads up to reason two: different mail servers.

Sticking with your example of Yahoo: they have several incoming servers, but that doesn't automatically mean that those servers will also be used for outgoing e-mail. So if someone gives my server a Yahoo domain in the HELO exchange it can only check for Yahoo's incoming servers. It can't determine which servers the domain (or company) would use for outgoing e-mail.

That is also why people eventually started opting to use SPF (Sender Policy Framework).

 

[dkovacevic]

First of all you have to realize that there are no official rules for all this.

Yeah, this kills me.

A PTR lookup is much faster than a normal forwarding lookup? Why? Do you have an example?

a client can provide just about anything in the initial HELO exchange

Yes, but that does not mean that we believe them. That's the whole point of the PTR lookup- to ensure the identity of the client.

if someone gives my server a Yahoo domain in the HELO exchange it can only check for Yahoo's incoming servers

I was under the impression that a fully qualified domain name was given in the HELO exchange. Am I incorrect?

 

[Anonymous]

Why are PTR records used to verify an SMTP server's client, as opposed to having the server do a simple lookup on the FQDN provided by the client in the HELO exchange?

Checking for a well defined domain name in the PTR response, i.e. a non-generic domain name that does neither contain an encoded IP-address nor contain, "dyn", "dsl", "cable", "dial", etc., is usually a quick way to distinguish real SMTP servers on a fixed IP from SMTP senders on a dynamic IP. 99 % of the latters want to send only SPAM to you, so most admins prefer stopping a huge amount of spam-in at almost no cost, even though having 1 % of collateral damage.

Another point is, that the PTR record is usually maintained by the ISP, so in combination with the provided domain names (A and NS records) it serves as a quite simple chain of trust. It is not 100 % perfect, however, if an ISP sets up a non-generic PTR for you, then usually this means that they know you.

The simple workround for small SMTP servers on IP addresses (perhaps dynamic) with no valid PTR, is to relay outgoing e-mails to the SMTP server of the ISP, who then distributes it to the final receivers.

 

[kpa]

One of the big problems with PTR records is that their delegation to nameservers is not controlled by the same authority that delegates the forward zones of your domains. It's always the ISP that owns the addresses that handles the delegation of them. In many cases even with a business class connection the ISPs just don't offer the possibility to further delegate the reverse zone to client's own nameserver.

 

[dkovacevic]

So essentially, because valid PTR records are only possible through the cooperation between the end host and the ISP, it can generally be assumed that a valid PTR record is a good indicator of the legitimacy of the end host.

A fully qualified domain name that resolves correctly with a forwarding request is not necessarily a guarantee that a host is legitimate because dynamically assigned IP addresses typically come with an assigned hostname from the ISP which might resolve correctly for that IP address. This doesn't require any cooperation between the end host and the ISP (other than the requirement of a basic service contract).

Thank you all for your patient explanations.

 

[throAU]

So essentially, because valid PTR records are only possible through the cooperation between the end host and the ISP, it can generally be assumed that a valid PTR record is a good indicator of the legitimacy of the end host.

A fully qualified domain name that resolves correctly with a forwarding request is not necessarily a guarantee that a host is legitimate because dynamically assigned IP addresses typically come with an assigned hostname from the ISP which might resolve correctly for that IP address. This doesn't require any cooperation between the end host and the ISP (other than the requirement of a basic service contract).

Thank you all for your patient explanations.

Correct, somewhat - though there are rogue ISPs who will set up PTRs for spammers, and a valid PTR record should only be one of a series of checks to determine how legit the host looks.

Put another way - if I was a spammer who actually owned a netblock, I could set up my PTR records to resolve to say, mail.google.com, use that as my SMTP server's HELO, and your PTR checking will think I'm legit.

 

[hockey97]

So essentially, because valid PTR records are only possible through the cooperation between the end host and the ISP, it can generally be assumed that a valid PTR record is a good indicator of the legitimacy of the end host.

A fully qualified domain name that resolves correctly with a forwarding request is not necessarily a guarantee that a host is legitimate because dynamically assigned IP addresses typically come with an assigned hostname from the ISP which might resolve correctly for that IP address. This doesn't require any cooperation between the end host and the ISP (other than the requirement of a basic service contract).

Thank you all for your patient explanations.

I think the reason why we use PTR records is not to actually verify but to decrease spamming. You have to have a static IP given by your ISP and you would need to contact them to set up the PTR record.

It's a pain in the butt. Also they will charge you more money for a static IP address. Having a static IP address isn't easy and isn't given by default. So, most spammers either don't know this or do know this but don't want to spend more money. So, they don't have a PTR record that matches their hostname or domain name. So, doing this check will not eliminate spammers but will cut down a lot of the spammers.

So, I Think this method is commonly used to lower the numbers of spammers. It does a good job reducing the numbers. So, it's a good store. My mail servers do the same and before when I didn't used this method. I would get spammers from Mexico sending me adds in e-mails that are in Spanish. After I put this method into action. I no longer get these spammers. It has a huge effect but won't eliminate the problem.

 

[ShelLuser]

So, most spammers either don't know this or do know this but don't want to spend more money. So, they don't have a PTR record that matches their hostname or domain name.

Unfortunately it's more devious than that. A lot of spammers expect their IP address to eventually end up in an anti-spam list or two, and that's why they prefer to use dynamic ranges. If one address is blocked they'll just move on to the next.