# Postfix - does not resolve a new revDNS entry



## IPTRACE (May 18, 2017)

Hello!

I have a strange problem. My postfix does not resolve one of the IP address to domain name.
So, in such case mail is dropped. Restarting the postfix does not help.
host command from this OS resolves this IP correctly. I don't use any DNS server on this machine.
Where can be a problem?


```
warning: hostname mail.domain.dot does not resolve to address A.B.C.D
```
`$ host A.B.C.D
D.C.B.A.in-addr.arpa domain name pointer mail.domain.dot.`


----------



## SirDice (May 18, 2017)

Looks like forward and reverse lookups may not agree. Forward lookup of mail.domain.tld resolves to 1.1.1.1 but a reverse lookup of 1.1.1.1 doesn't resolve to mail.domain.tld.


----------



## IPTRACE (May 18, 2017)

I get confused.

`$ host A.B.C.2
2.C.B.A.in-addr.arpa domain name pointer mail.domain.dot.`

`$ host A.B.C.12
12.C.B.A.in-addr.arpa domain name pointer mail.domain.dot.`

`$ host mail.domain.dot
mail.domain.dot has address A.B.C.12`

mail.domain.dot resolves to A.B.C.12
A.B.C.2 resolves to mail.domain.dot

Do you mean the problem is A.B.C.12<>A.B.C.2 in this case?
Or with mail.domain.dot resolves to one IP address only?


```
warning: hostname mail.domain.dot does not resolve to address A.B.C.2
connect from unknown[A.B.C.2]
NOQUEUE: reject: CONNECT from unknown[A.B.C.2]: 450 4.7.25 Client host rejected: cannot find your hostname, [A.B.C.2]; proto=SMTP
disconnect from unknown[A.B.C.2] quit=1 commands=1
```


----------



## SirDice (May 18, 2017)

IPTRACE said:


> Do you mean the problem is A.B.C.12<>A.B.C.2 in this case?


Yes, that's the most likely cause. 


IPTRACE said:


> Or with mail.domain.dot resolves to one IP address only?


My guess is that they're using A.B.C.2 as outgoing only and A.B.C.12 for incoming. That's a common setup.


----------



## IPTRACE (May 18, 2017)

They use A.B.C.2 as outgoing and they doesn't resolve mail.domain.dot to A.B.C.2 .
Is it correct to drop transmission in such case? (due to spam etc.)


----------



## IPTRACE (May 18, 2017)

I've found nice explanation in postfix config.
http://www.postfix.org/postconf.5.html


```
reject_unknown_client_hostname (with Postfix < 2.3: reject_unknown_client)
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.
This is a stronger restriction than the reject_unknown_reverse_client_hostname feature, which triggers only under condition 1) above.
The unknown_client_reject_code parameter specifies the response code for rejected requests (default: 450). The reply is always 450 in case the address->name or name->address lookup failed due to a temporary problem.
```


----------



## gkontos (May 18, 2017)

This is a very strict rule and IMHO you should not use it. There a a lot of valid mail servers out there with the same problems.


----------



## IPTRACE (May 18, 2017)

I've changed the entry to following. Instead "reject_unknown_client" I set "reject_unknown_reverse_client_hostname" to block no revDNS.


```
smtpd_client_restrictions = reject_unknown_reverse_client_hostname
```
Anyway, how can I avoid "warning" in my logs?

```
warning: hostname mail.domain.dot does not resolve to address A.B.C.2
connect from unknown[A.B.C.2]
Anonymous TLS connection established from unknown[A.B.C.2]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
warning: hostname mail.domain.dot does not resolve to address A.B.C.2
connect from unknown[A.B.C.2]
```


----------



## SirDice (May 18, 2017)

gkontos said:


> This is a very strict rule and IMHO you should not use it. There a a lot of valid mail servers out there with the same problems.


I agree. It's actually a violation of the protocol to deny email based on the resolvability (is that an actual word?) of an IP address.

You won't believe the arguments I've had with admins denying perfectly good emails. I even had several arguments because the receiving admin insisted my _outgoing_ mailserver must have an MX record.


----------



## IPTRACE (May 18, 2017)

SirDice said:


> I agree. It's actually a violation of the protocol to deny email based on the resolvability (is that an actual word?) of an IP address.



But if the outgoing mail server tells "My hostname is mail.domain.dot", then I check it if you don't lie and I try to resolve mail.domain.dot and get another IP address than transmission comes from.
I think it's client misconfiguration of DNS or mail server setup.

IMHO it's enough to add A DNS record to have resolving IP address A.B.C.2 and set proper hostname in mail server configuration.


----------



## SirDice (May 18, 2017)

IPTRACE said:


> But if the outgoing mail server tells "My hostname is mail.domain.dot", then I check it if you don't lie and I try to resolve mail.domain.dot and get another IP address than transmission comes from.
> I think it's client misconfiguration of DNS or mail server setup.


Doesn't matter what the reason is, you should still accept the email.


> IMHO it's enough to add A DNS record to have resolving IP address A.B.C.2 and set proper hostname in mail server configuration.


Sure. But you have no control over that. So there's a choice, block the mail and try and get the receiving admin to fix things while you have pissed off users or simply accept it.


----------



## IPTRACE (May 18, 2017)

SirDice said:


> Doesn't matter what the reason is, you should still accept the email.


So, should I accept no revDNS IP address as well ?!


----------



## SirDice (May 18, 2017)

Basically, yes. You can always filter further down the line and mark the email as potential spam.


----------



## IPTRACE (May 18, 2017)

In some circumstances server could receive umpteen of fake mails.
Using third party software to fight with spam is moving the problem to another application and takes server resources.
Finally, the user can have thousands of mails exp. in him spam folder or worse still in him inbox.

I've found in RFC about SMTP something like this.
https://www.ietf.org/rfc/rfc2821.txt

```
3.6 Domains

  Only resolvable, fully-qualified, domain names (FQDNs) are permitted
   when domain names are used in SMTP.  In other words, names that can
   be resolved to MX RRs or A RRs (as discussed in section 5) are
   permitted, as are CNAME RRs whose targets can be resolved, in turn,
   to MX or A RRs.  Local nicknames or unqualified names MUST NOT be
   used.  There are two exceptions to the rule requiring FQDNs:

   -  The domain name given in the EHLO command MUST BE either a primary
      host name (a domain name that resolves to an A RR) or, if the host
      has no name, an address literal as described in section 4.1.1.1.

   -  The reserved mailbox name "postmaster" may be used in a RCPT
      command without domain qualification (see section 4.1.1.3) and
      MUST be accepted if so used.
```


----------



## SirDice (May 18, 2017)

This is for the HELO (or EHLO). It says nothing about the connecting IP addresses.


----------



## IPTRACE (May 18, 2017)

SirDice said:


> This is for the HELO (or EHLO). It says nothing about the connecting IP addresses.


So, if DNS<>IP resolving is out the scope of SMTP it means that we can consider it as the third party software to control such restrictions.
Right, it's Postfix but it works before SMTP transmission and we can set it if we want. Exactly the same with any antispam apps and its rules.
Simillar approach is to block IP due to too many connections within a period of time.


----------



## no-pain-no-gain (Jul 28, 2017)

If you are using postfix then postscreen is your friend.


----------

