DNS PTR Record with 2 FQDN Entries with SPAM Check
-
Good write up here on ServerFault:
The PTR record for a reverse name (eg 7.2.0.192.in-addr.arpa) is expected to identify the canonical name that is associated with that IP address.
Both the gateway pointers at network nodes and the normal host pointers at full address nodes use the PTR RR to point back to the primary domain names of the corresponding hosts.
From: http://tools.ietf.org/html/rfc1035#section-3.5
This expectation is reflected in software that does reverse lookups; often such software specifically expects a single name back and it expects to be able to use that name as a canonical name for that host. If there are multiple names returned it's common to just take one at random because they have absolutely no way of knowing which one you would have preferred for this particular occasion.
As the general expectation is that there is one canonical name associated with an IP address and that name is what the PTR should point to, adding multiple names generally has no upside (nothing expects any random A/AAAA record to have a matching PTR) but it has a potential downside as it can cause strange results as you have no control over which of your PTR records will be used if you have added more than one.
In essence, if you have multiple PTR records you do not actually make your host appear more legitimate but rather the opposite, you run the risk of failing some validation or otherwise breaking something.
As a perhaps somewhat extreme metaphor, handing over five passports all with your photo but with different names at the airport is probably not going to be received as well as if you just hand over one.
-
@scottalanmiller I have read it. the question is/was, how do you deal with this situation when it occurs (rarely), is there a way other than whitelisting the offending ip for the ptr. and the ip is listed in their spf list.
-
@pattonb said in ptr + 2 fqdn:
I thought there was an rfc that stipulates, 1 fqdn with 1 ip per ptr record.
No, not quite. But it does stipulate the purpose of a PTR, which tells us that your assumption of "requirement" is the only one that would have a valid purpose. So you are nearly correct. But it allows other usages, even though no legitimate usage would exist.
The RFC also does not specify how a DNS server should react to being put in that situation, so the results aren't even predictable. Generally we assume round robin, but other options exist, like full random.
Email servers using PTR for lookups assume that correct usage suggests "less likely to be spam", and they are correct. So one of the purposes of the PTR check in Zimbra would be to find situations like the one in question and mark it as spam. Since it would return bad results. PTR checks aren't only to look for blank PTRs, but also "wrong" ones. This is a wrong one, ergo, should be getting flagged as more likely to be spam.
-
@pattonb argh the ip IS NOT listed in their spf record, can't type today
-
@pattonb said in ptr + 2 fqdn:
@scottalanmiller I have read it. the question is/was, how do you deal with this situation when it occurs (rarely), is there a way other than whitelisting the offending ip for the ptr. and the ip is listed in their spf list.
No, there is no possible way to deal with it without bypassing the PTR check because the whole purpose of the PTR check is to see if the PTR is good and if not, mark as spam. And in this case, it's a bad PTR. Leaving whitelisting (or disabling PTR checks) as your only options since it is legitimately failing the check since the record is bad.
-
@pattonb said in ptr + 2 fqdn:
@pattonb argh the ip IS NOT listed in their spf record, can't type today
Are you confident that this isn't a spammer? LOL Even at the human level, they are failing one spam check after another. Pretty suspicious.
-
Edited the title for clarity (and SEO) and added topic tags.
-
@scottalanmiller ok, thanks, I am sure it isn't a spammer, it is an email, for me, I was expecting. The sender 'city of calgary"
has their ptr record setup that way. -
@pattonb said in DNS PTR Record with 2 FQDN Entries with SPAM Check:
@scottalanmiller ok, thanks, I am sure it isn't a spammer, it is an email, for me, I was expecting. The sender 'city of calgary"
has their ptr record setup that way.Then they desperately need email help, that's going to cause issues for them across the board. You'll have to white list it.
-
WTF does this have to do with receiving email?
-
Normal offices have zero control over their PTR records. It is something that an ISP deals with.
-
@JaredBusch true, and your point is ?
-
@pattonb said in DNS PTR Record with 2 FQDN Entries with SPAM Check:
@pattonb argh the ip IS NOT listed in their spf record, can't type today
This should affect things.
Valid SPF is critical to helping reducing spam.
-
@JaredBusch SPF has it flaws, however, in this case , ptr check yields 2 fqdn, and no listing in the SPF to confirm validity of sender.
-
@pattonb said in DNS PTR Record with 2 FQDN Entries with SPAM Check:
@JaredBusch true, and your point is ?
That you could likely not receive email from my client because the PTR does not resolve to their domain name. Hence PTR is not a verification of for email.
Or my other client that proxies their outbound email through Google Mail Security (wtf ever they changed the name to).
-
@pattonb said in DNS PTR Record with 2 FQDN Entries with SPAM Check:
@JaredBusch SPF has it flaws, however, in this case , ptr check yields 2 fqdn, and no listing in the SPF to confirm validity of sender.
PTR and SPF have nothing to do with each other.
-
@JaredBusch correct, they are tools to determine validity of incoming email. If you have a mail server , ( I would think with a static ip), why you wouldn't have a ptr record that matches your mailserver, is asking for issues.
-
@pattonb said in DNS PTR Record with 2 FQDN Entries with SPAM Check:
why you wouldn't have a ptr record that matches your mailserver, is asking for issues.
Two very simple reasons that I hae already stated.
Because PTR is not for email verification.
Because PTR records are not something I have access to update. -
Look at it more obviously, taking the entire stupid local email server out of the equation.
How the fuck am I supposed to know what IP Microsoft is using to send my email since I use O365? Let alone how am I supposed to get access to the IP scope to change the PTR.
Of and then also that would screw over every other O365 user that has their email sent out on the same IP address.
-
@pattonb said in DNS PTR Record with 2 FQDN Entries with SPAM Check:
@JaredBusch correct, they are tools to determine validity of incoming email. If you have a mail server , ( I would think with a static ip), why you wouldn't have a ptr record that matches your mailserver, is asking for issues.
No reason for a sending mail server to have a static IP, that's for receipt only. It's actually a sending client. The whole concept of email sending as a static IP'd server doesn't actually make sense. People do it because of bad spam filtering attempts, but it isn't actually logical. The sending action is more akin to a web browser and we don't expect a static IP or PTR record for each web browser out there. It's a transient action.
PTR records are controlled by the ISP and loads of ISPs won't modify them.
