Postfix Reverse DNS Lookup: 450 4.7.1 Client host rejected

Question

Postfix seems to be consistently rejecting mails from few servers though PTR lookup for those domains is successful. Please see log below. I have run out of ideas on what we can do to get this working. I am sure the issue is not with the sending server as they do not have errors sending to other domains.

Oct 26 09:08:32 mail postfix/smtpd[16158]: NOQUEUE: reject: RCPT from  
unknown[XX.XX.XX.XX]: 450 4.7.1 Client host rejected: cannot find your hostname, 
[XX.XX.XX.XX]; from=<[email protected]> to=<[email protected]> proto=ESMTP 
helo=<somedomain.com>

[root@mail log]# dig -x XX.XX.XX.XX

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> -x XX.XX.XX.XX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26837
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 6

;; QUESTION SECTION:
;XX.XX.XX.XX.in-addr.arpa.  IN  PTR

;; ANSWER SECTION:
XX.XX.XX.XX.in-addr.arpa. 7813  IN  PTR somedomain.com.

;; Query time: 417 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Oct 26 09:24:25 2014
;; MSG SIZE  rcvd: 66

Solution 1

Can't 100% answer since you anonamized the data, but Postfix is looking for the PTR and A records to match, as well as the hostname the mail server is claiming to be which looks to be "somedomain.com" from the HELO command in your obfuscated log message.

These are controlled by:

reject_unknown_sender_domain
reject_unknown_client_hostname
reject_invalid_helo_hostname

Postfix Config Params http://www.postfix.org/postconf.5.html

Solution 2

I know this is an old thread, but I wanted to add a little more texture to the answers.

There is, in fact, a problem with the sender's domain. As @milli pointed out the PTR and A records should match - and they do not.

if postfix is configured with reject_unknown_sender_domain, postfix performs the following checks...

1) retrieve PTR record from dns - if there is no PTR record, reject the email

2) retrieve A record from dns for the domain in the PTR - if the IP in the A record does not match the IP of the connected MX, reject the email.

For instance, an MX connects from the IP 74.125.195.27

$ host 74.125.195.27
27.195.125.74.in-addr.arpa domain name pointer wj-in-f27.1e100.net.
$ dig a wj-in-f27.1e100.net. +short
216.239.32.27
66.102.12.27
74.125.195.27

In this case, the A record from the domain in the PTR record contains the same IP address as the host that is connected. This email will NOT be rejected.

The "problem" in most cases, though, is illustrated in the following:

$ host 216.117.130.109
109.130.117.216.in-addr.arpa domain name pointer jalequity.com.
$ dig a jalequity.com. +short
104.239.175.211

The A record from the domain in the PTR record doesn't match that of the connected host - this email will be REJECTED with "Client host rejected: cannot find your hostname"

The most common mistake that leads to this is putting the actual domain (in this example "jalequity.com") in the PTR record, rather than a subdomain. To fix this, the sender should amend their PTR record to something like mail.jalequity.com, then add an A record for mail.jalequity.com with the IP address 216.117.130.109. Any further email sent from that server would be accepted.

The BEST fix is for the sender to correct their DNS records.

The ALTERNATE fix is to loosen your postfix restrictions from "reject_unknown_sender_domain" to "reject_unknown_reverse_client_hostname". But there are consequences to this action - primarily that most spammers have a PTR record (it just doesn't match an A record), so relaxing the postfix restrictions will ensure that you don't miss an important email, but it will also ensure that your spam filters have constant work!

Comments

[user1880957]

Found out the problem. Postfix Docs. Reject the request when 1) the client IP address->name mapping fails, 2) the name->address mapping fails, or 3) the name->address mapping does not match the client IP address. Mine was failing on Step 3. Changed the rule to reject_unknown_reverse_client_hostname instead.