DNS PTR Record with 2 FQDN Entries with SPAM Check
-
Running a Zimbra server, and came across this today. 2 fqdn and 1 ip (ptr lookup).
Is there a simple way of avoiding the rejection of the email ?
ip in questions is 198.160.191.6 ( sending server)
and the pandemonium..is the sending server.
-
Maybe I don't have enough caffeine yet, but I am fairly certain you can have as many FQDN as you want looking at hte same IP.
-
If you have 2 Fqdn using that Zimbra server it will not affect the PTR. The IP reverse DNS just needs to match one of the 2 FQDN.
-
@JaredBusch said in ptr + 2 fqdn:
Maybe I don't have enough caffeine yet, but I am fairly certain you can have as many FQDN as you want looking at hte same IP.
You can. Unlimited.
-
@pattonb said in ptr + 2 fqdn:
2 fqdn and 1 ip (ptr lookup
This is the norm. Nothing weird here, and nothing special to set up.
You always get one and only one PTR record per IP address. This is the name of the server.
FQDNs are not related to the PTR record and millions can point to the same IP address. And you can't stop other people from doing this. Jared could go make 100 different FQDNs that point to your server right now if he wanted.
-
@pattonb said in ptr + 2 fqdn:
and the pandemonium..is the sending server.
Shouldn't be any. Neither the server, nor people sending to it, care about the FQDNs in use, nor do they know about them.
-
I should clarify, the ptr record single ip) has 2 fqdn, how does zimbra ( or any mailserver), know which fqdn
to verify, My understanding it attempts to verify the 'greeting' sever by doing a ptr lookup, and if it doesn't match, then
the attempted connection is rejected, as there is a mismatch with the sending server, and the ptr record. -
I thought there was an rfc that stipulates, 1 fqdn with 1 ip per ptr record.
-
@pattonb said in ptr + 2 fqdn:
I should clarify, the ptr record single ip) has 2 fqdn, how does zimbra ( or any mailserver), know which fqdn
to verify, My understanding it attempts to verify the 'greeting' sever by doing a ptr lookup, and if it doesn't match, then
the attempted connection is rejected, as there is a mismatch with the sending server, and the ptr record.That is if you are using Reverse DNS checks.
-
@dbeato it has been my experience that, dns checks eliminates loads of spam
-
@pattonb said in ptr + 2 fqdn:
@dbeato it has been my experience that, dns checks eliminates loads of spam
I guess, that is not the only way. What other checks you have enabled in Zimbra or external spam filtering?
-
@JaredBusch the question is more about a ptr record
-
@pattonb said in ptr + 2 fqdn:
I should clarify, the ptr record single ip) has 2 fqdn, how does zimbra ( or any mailserver)
Then this is a bad PTR record and must be fixed. PTR is to point to the canonical name of the server, so multiple entries must be wrong.
Like all DNS, the return would come as a round robin, Zimbra doesn't see both, it only sees the semi-random one returned. So it verifies the one returned by DNS, whichever one that is.
PTR records should never have multiple entries, there is no situation where that is correct.
-
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.
