# Postfix and no reverse DNS



## xy16644 (Feb 17, 2014)

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:

```
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:


```
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?


----------



## neel (Feb 18, 2014)

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.


----------



## kpa (Feb 18, 2014)

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.


----------



## xy16644 (Feb 19, 2014)

Yeah, I turned off the reverse DNS checks. Was causing too many problems.


----------



## SirDice (Feb 19, 2014)

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.


You won't believe how many battles I've had with admins that insisted an _outgoing_ mailserver should have an MX record  x(


----------



## ShelLuser (Feb 19, 2014)

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:


```
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/


----------



## kpa (Feb 19, 2014)

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:


```
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.
```


```
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
```


```
dig -x 119.145.14.94 +noall +answer

; <<>> DiG 9.8.3-P1 <<>> -x 119.145.14.94 +noall +answer
;; global options: +cmd
```


----------



## ShelLuser (Feb 19, 2014)

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.


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:


```
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.


----------

