Postfix and no reverse DNS

X

xy16644

My Postfix server rejects email from clients that don't have reverse DNS. Unfortunately there is one company I need to receive email from and, you guessed it, they don't have their reverse DNS record setup correctly. I have mentioned it to them but who knows how long it will take for them to fix this issue.

In the interim, I would like to whitelist their IP address. So in my main.cf I set:
Code: 
smtpd_client_restrictions = permit_sasl_authenticated,
                            check_client_access hash:/usr/local/etc/postfix/client_whitelist,
                            reject_invalid_hostname,
                            reject_unauth_destination,
                            reject_rbl_client cbl.abuseat.org,
                            reject_rbl_client b.barracudacentral.org,
                            reject_rbl_client zen.spamhaus.org,
                            reject_unknown_client,
                            permit

In /usr/local/etc/postfix/client_whitelist I set:

Code: 
xxx.xxx.xxx.xx OK

and then ran postmap /etc/postfix/client_whitelist. I also restarted the Postfix service.

But emails from them are still being rejected. Am I doing this correctly?
 
You could remove reject_invalid_hostname, but a better method is to ask them to ask their ISP to set their reverse DNS entry to their IP address.
 
Reverse DNS should not be required for successful transfer of email. It's a nice convinience but not strictly required by any standards or regulations. You're better off not requiring it in your configuration. Of course you can not do anything if someone else is foolish enough to require it in their own MTA but that's another matter.
 
kpa said:
Reverse DNS should not be required for successful transfer of email. It's a nice convinience but not strictly required by any standards or regulations. You're better off not requiring it in your configuration. Of course you can not do anything if someone else is foolish enough to require it in their own MTA but that's another matter.
Click to expand...
You won't believe how many battles I've had with admins that insisted an outgoing mailserver should have an MX record x(
 
I know you turned the whole thing off in the mean time, personally I consider that a bad idea because requiring PTR records is a very good way to block a lot of spam right at the front door. Of course this point becomes a bit moot if you also have greylisting set up. Even so all my servers demand a PTR record and so far I've yet to receive complaints or see something go horribly wrong.

Alas; I'd still like to answer the question.

I think the easiest way for you would be not using a list but simply setting their IP straight into the main.cf. Something in the likes of:

Code: 
noptr = xx.xx.xx.xx/32;
smtpd_client_restrictions = permit_sasl_authenticated, permit_noptr,
                            reject_invalid_hostname,
                            reject_unauth_destination,
                            reject_rbl_client cbl.abuseat.org,
                            reject_rbl_client b.barracudacentral.org,
                            reject_rbl_client zen.spamhaus.org,
                            reject_unknown_client,
                            permit
When looking at your whitelist I think not specifying the mask was the main issue. If you check cidr_table(5) you'll notice that the common way to specify a network address is by using network_address/network_mask result. I think that's where the lookup may have gone wrong at your end.

Edit: s/setup/set\ up/
 
It may have worked for you but there are many completely legit mail servers out there without PTR records for their IP addresses, some even for very large well known companies. I can't remember offhand a good example but I did ran across a few in my previous job as a systems admin.

Edit:

Code: 
dig huawei.com MX +noall +answer

; <<>> DiG 9.8.3-P1 <<>> huawei.com MX +noall +answer
;; global options: +cmd
huawei.com.		86094	IN	MX	20 mx4.huawei.com.
huawei.com.		86094	IN	MX	15 mx2.huawei.com.
huawei.com.		86094	IN	MX	10 mx1.huawei.com.
huawei.com.		86094	IN	MX	20 mx3.huawei.com.

Code: 
dig mx1.huawei.com A +noall +answer

; <<>> DiG 9.8.3-P1 <<>> mx1.huawei.com A +noall +answer
;; global options: +cmd
mx1.huawei.com.		86070	IN	A	119.145.14.94

Code: 
dig -x 119.145.14.94 +noall +answer

; <<>> DiG 9.8.3-P1 <<>> -x 119.145.14.94 +noall +answer
;; global options: +cmd
 
kpa said:
I can't remember offhand a good example but I did ran across a few in my previous job as a systems admin.
Click to expand...
Your example doesn't quite match up because you're now also assuming that huawei.com uses their SMTP servers for both incoming and outgoing e-mail. Some companies do that but usually this isn't the case. Neither in this particular example:

Code: 
smtp2:/home/peter $ dig huawei.com TXT | grep spf1
huawei.com.             86343   IN      TXT     "v=spf1 ip4:119.145.14.64/30 ip4:58.251.152.64/30 ip4:119.145.14.93 ip4:58.251.152.93 ip4:206.16.17.74 ip4:194.213.3.16 ip4:194.213.3.17 ip4:206.16.17.72 ~all"
smtp2:/home/peter $ dig -x 119.145.14.65
;; ANSWER SECTION:
65.14.145.119.in-addr.arpa. 86400 IN    PTR     szxga02-in.huawei.com.
smtp2:/home/peter $ dig -x 119.145.14.66
;; ANSWER SECTION:
66.14.145.119.in-addr.arpa. 86400 IN    PTR     szxga03-in.huawei.com.
In my experience most companies and providers make sure to provide PTR records for their outgoing mailservers.
 
You must log in or register to reply here.
Back
Top