return value of getnameinfo() + NI_NAMEREQD

[Bernhard Schmidt <berni at birkenwald dot de>]

Hello everyone,

short problem statement: We run a Postfix inbound MX setup on SLES 10.1
which imposes a very aggressive reverse DNS check on the delivering
host. It checks if the host has a) a PTR record pointing to a hostname
and b) this hostname resolves back to the connecting IP address again.
If one of these conditions applies the message is rejected permanently
using a 550 SMTP response code. However, if one of the associated DNS
queries fails (SERVFAIL or timeout) the response code that is supposed
to be given (and the only reasonable one in this situation as the
problem could very well be on our end and/or temporary) is a 450
temporary reject, which does not bounce the message but retries the
delivery later. The first check is implemented using getnameinfo(), the
second using getaddrinfo().

We now had a few false positives where the nameservers responsible for
the reverse mapping were unreachable or misconfigured and still postfix
rejected the message with a full-blown permanent reject instead of a
deferral. I brought this issue up on the postfix mailinglist.

http://thread.gmane.org/gmane.mail.postfix.user/183129

Now, apparently Postfix does getnameinfo() with NI_NAMEREQD for a) and
expects EAI_AGAIN, EAI_MEMORY or EAI_SYSTEM as marker for a temporary
error, while glibc appears to be returning EAI_NODATA if NI_NAMEREQD is
set. I think (I'm nowhere near to understanding C) the responsible code
is in lines 294-300 in inet/getnameinfo.c:

1.16          drepper    294:        if (!ok)
1.8           drepper    295:          {
1.16          drepper    296:            if (flags & NI_NAMEREQD)
1.8           drepper    297:              {
                         298:                __set_errno (serrno);
1.22          drepper    299:                return EAI_NONAME;
1.8           drepper    300:              }

Reading RFC3493 I think both options are valid, although I tend to be on
the Postfix side.

What is the official position on this, bug in glibc, bug in postfix, but
in neither or bug in both?

Bernhard