Postfix - does not resolve a new revDNS entry

IPTRACE

IPTRACE

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?

Code: 
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.
 
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.
 
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?

Code: 
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
 
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.)
 
I've found nice explanation in postfix config.
http://www.postfix.org/postconf.5.html

Code: 
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.
 
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've changed the entry to following. Instead "reject_unknown_client" I set "reject_unknown_reverse_client_hostname" to block no revDNS.

Code: 
smtpd_client_restrictions = reject_unknown_reverse_client_hostname
Anyway, how can I avoid "warning" in my logs?
Code: 
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]
 
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.
Click to expand...
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.
 
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.
Click to expand...

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.
 
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.
Click to expand...
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.
Click to expand...
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.
 
Basically, yes. You can always filter further down the line and mark the email as potential spam.
 
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
Code: 
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.
 
This is for the HELO (or EHLO). It says nothing about the connecting IP addresses.
 
SirDice said:
This is for the HELO (or EHLO). It says nothing about the connecting IP addresses.
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top