According to the docs, the smtp_mx_address_limit parameter determines
"the maximal number of MX (mail exchanger) IP addresses that can result
from mail exchanger lookups, or zero (no limit)".
However, when setting it to zero, the SMTP client won't even attempt to
deliver to a server that has _both_ IPv4 _and_ IPv6 addresses. Instead,
the mail is deferred forever (and 4 days ;-) with the error message
"4.4.4 server unavailable or unable to receive mail".
Yet a Perl script can connect to all these addresses just fine, and even
deliver mail when talking SMTP to the other side.
The problem seems to be that the function "smtp_balance_inet_proto" (in
smtp_addr.c) does not treat "0" as the special "no limit" case. Instead,
it treats it literally as a limit of zero IP's.
The function contains the line:
if (v4_count > 0 && v6_count > 0 && v4_count + v6_count > addr_limit)
and inside the "if" block, a clever algorithm attempts to create a mix
of IPv4 and IPv6 addresses, by eliminating some of each kind, while
enforcing the limit.
But when addr_limit is set to 0, all IP's are eliminated from the list.
I confirmed that by adding "-v" to the smtp client in master.cf and
sending an e-mail to an address in a domain with one MX that has one A
and one AAAA.
The Postfix logs show that both IP's are found in DNS :
"begin <hostname> address list"
"pref 300 host <hostname>/<IPv4 address>
"pref 300 host <hostname>/<IPv6 address>
"end <hostname> address list"
The logs then continue with the tell-tale entry:
"v6_target=0, v4_target=0"
Followed by the two lines:
"begin smtp_balance_inet_proto result address list"
"end smtp_balance_inet_proto result address list"
With nothing in between...
Note that, in the above, I have obfuscated the host name and IP
addresses. I think I could safely post them here, but I suppose that
they won't be needed. Besides, postfix.org has 3 A's and 3 AAAA's and
could probably be used as a test case as well ;-)
Adding "addr_limit > 0" as the first condition in the "if" statement
above would likely take care of the problem.
IMHO, a more elegant (because more readable) solution would be to put an
explicit extra test in front of the (already long) "if", like this:
if (addr_limit == 0) {
return (addr_list);
}
A suitable comment in front would make it even more clear.
I have not provided a patch as this seems such a trivial change. In the
Postfix 3.4.5 source code, the offending "if" statement is at line 409
of smtp_addr.c. Alternatively, you can go straight to the
smtp_balance_inet_proto() function in there.
However, this also means that I haven't tested if my proposed solution
actually works. If somebody tells me that it is not (or may not be)
sufficient, I'm willing to dig further myself.
In any case, a fix is not urgent, since there is an easy workaround, and
that is: "don't RTFM", i.e. leave smtp_mx_address_limit at its default of 5.
And if you really want "no limit", you can set it to a ridiculously high
value, such as 100.
>From the changelog, this seems to have been introduced on 20170505, and
in any case, smtp_addr.c has a timestamp of Dec 27, 2017.
If this has been reported already, I apologize. I did a quick search
only and came up empty. If I missed it, this "bug report" becomes a "bug
reminder" :-)
It goes without saying, I hope, that the other client parameters in
main.cf have to be set to the proper values to trigger the bug (e.g.
smtp_balance_inet_proto = yes).
Luc Pardon
