> Dave Jones: > > >On 9/16/2013 5:41 PM, Dave Jones wrote: > > >> > > >> Received: from mail02.corp.ena.net (unknown [96.4.3.90]) > > >> by mr11.mail.ena.net (Postfix) with ESMTP id 57C091480688 > > >> for <redac...@domain.com>; Mon, 16 Sep 2013 16:04:46 -0500 (CDT) > > >> > > >> My forward DNS lookup for this host is an internal IP address that > > >> doesn't not match the public but it has been this way for years. > > > > > You need to do your tests as the postfix user, possibly also > > > chrooted. Turn off the chroot flag in master.cf for testing. > > > > I don't have anything chrooted (all n's in that column of the master.cf ). > > The dig as the postfix user returns the same result.
> First, I can't fail to notice that the PTR record for 96.4.3.90 > says "mail02.corp.ena.net.", but the A record for "mail02.corp.ena.net." > resolves to 172.27.0.25. Therefore, it is no surprise that Postfix > uses the name "unknown" instead of "mail02.corp.ena.net". I fixed the A record to match the PTR (external NAT) and now it's showing up properly: Received: from mail02.corp.ena.net (mail02.corp.ena.net [96.4.3.90]) by mr10.mail.ena.net (Postfix) with ESMTP id 5FA9114806F4 So there is no way to get Postfix to just show the PTR value in the headers without validating anything? It seems like MTAs should show the PTR value to the left of the square brackets even when it doesn't match the HELO to the left of the parenthesis. If FCRDNS doesn't pass, I would think that could be an additional string in the headers or something. In this case, the message has already been accepted so the reject_unknown_client_hostname and reject_unknown_reverse_client_hostname logic for determining the "unknown" value shouldn't apply and the PTR value should been shown. In this case, the PTR was correct in DNS but showed as "unknown" like it didn't exist in DNS. > Second, Postfix does not query DNS to determine the SMTP client > hostname. Instead, Postfix uses the system library getnameinfo() > and getaddrinfo() routines. Attached are small programs that > you can run to see what result Postfix would get. > Again, if the address->name result is not consistent with the > name->address result, Postfix will use "unknown" instead. On Wed, Sep 18, 2013 at 8:35 AM, Wietse Venema <wie...@porcupine.org> wrote: > Dave Jones: > > >On 9/16/2013 5:41 PM, Dave Jones wrote: > > >> > > >> Received: from mail02.corp.ena.net (unknown [96.4.3.90]) > > >> by mr11.mail.ena.net (Postfix) with ESMTP id 57C091480688 > > >> for <redac...@domain.com>; Mon, 16 Sep 2013 16:04:46 -0500 (CDT) > > >> > > >> My forward DNS lookup for this host is an internal IP address that > > >> doesn't not match the public but it has been this way for years. > > > > > You need to do your tests as the postfix user, possibly also > > > chrooted. Turn off the chroot flag in master.cf for testing. > > > > I don't have anything chrooted (all n's in that column of the master.cf > ). > > The dig as the postfix user returns the same result. > > First, I can't fail to notice that the PTR record for 96.4.3.90 > says "mail02.corp.ena.net.", but the A record for "mail02.corp.ena.net." > resolves to 172.27.0.25. Therefore, it is no surprise that Postfix > uses the name "unknown" instead of "mail02.corp.ena.net". > > Second, Postfix does not query DNS to determine the SMTP client > hostname. Instead, Postfix uses the system library getnameinfo() > and getaddrinfo() routines. Attached are small programs that > you can run to see what result Postfix would get. > > Again, if the address->name result is not consistent with the > name->address result, Postfix will use "unknown" instead. > > Wietse >
