Re: Bug report: problem with smtp_mx_address_limit = 0
On 3/04/19 17:13, Viktor Dukhovni wrote: > > > It seems you're in a sardonic mood, ... best to not go there. If I gave that impression, I apologize. All I was trying to say is that, because of the bug, you may be more likely to run out of disk space by trying to send to bona fide domains like postfix.org than because of overworked delivery agents, simply because MX's with both A and records are much more common (and growing) than malicious ones. Anyway, the most important thing is that the bug has been noted, and will eventually be fixed, one way or another. Thanks for that. Luc
Re: Bug report: problem with smtp_mx_address_limit = 0
> On Apr 3, 2019, at 7:02 AM, Luc Pardon wrote: > >> ... and watch their mail queues melt down. > > ... because of all the mail that will get stuck in the queue with > "server unavailable or unable to receive mail" for _any_ MX that has > _both_ A and records. No, because failing deliveries to domains with tens to hundreds of unavailable MX host IPs would DoS the queue by tying up delivery agents for an unreasonably long time. It seems you're in a sardonic mood, ... best to not go there. Your bug report has been noted, and the solution will most likely be to drop the interpretation of 0 == unlimited. If someone decides to set an explicit non-default limit, it will be more obviously a potential resource issue than "I can't think of what the limit should be, so just turn it off". -- Viktor.
Re: Bug report: problem with smtp_mx_address_limit = 0
On 3/04/19 01:16, Wietse Venema wrote: > I prefer to remove the ability to disable safety mechanisms. And in your initial response, you also wrote: > Probably better to not allow a limit-less smtp_mx_address_limit, > as it makes Postfix vulnerable to resource exhaustion attack. Both responses seem to translate to "I prefer to remove the ability to set smtp_mx_address_limit to zero". As I said, that's fine with me. My only comment is that this won't bring you much. As you indicate yourself, people would still have the ability to effectively disable the safety mechanism (by setting smtp_mx_address_limit to one bazillion or so). The only difference is that, if they really want to get rid of the limit, they would (have to) disable it in an undocumented way. So, given that you can't prevent people from shooting themselves in the foot anyway, it seems more logical to let them do it in the (currently) documented way. This being said, I personally don't really care whether the ability to set smtp_mx_address_limit to zero is fixed or removed, but something has to be done. As it stands now, people can still set it to zero ... > > ... and watch their mail queues melt down. > ... because of all the mail that will get stuck in the queue with "server unavailable or unable to receive mail" for _any_ MX that has _both_ A and records. One of each is enough to trigger the bug, even if they would all respond if Postfix bothered to try. But it doesn't. It simply defers the mail until it eventually expires and bounces. Anyway, I have reported the issue and am happy to leave it at that. Luc
Re: Bug report: problem with smtp_mx_address_limit = 0
Luc Pardon: > On the same topic: what if smtp_mx_address_limit was simply made to > apply for each family separately? E.g. the default of 5 would mean: keep > max 5 IPv6 addresses _and_ max 5 IPv4's ? The purpose of these and other Postfix limits is not to frustrate legitimate mail operators. Instead the purpose is to maintain sanity under insane conditions. Therefore I would not be comfortable with suddenly doubling these limits. I prefer to remove the ability to disable safety mechanisms. If sites want to receive MX responses that specify a bazillion hosts (none of which is likely to respond), then they can configure Postfix to try all those hosts, and watch their mail queues melt down. Wietse
Re: Bug report: problem with smtp_mx_address_limit = 0
On 2/04/19 13:21, Wietse Venema wrote: > Probably better to not allow a limit-less smtp_mx_address_limit, > as it makes Postfix vulnerable to resource exhaustion attack. > > Wietse > Fair enough, but then the docs for smtp_mx_address_limit ought to be changed to remove the "or zero (no limit)" at the end. I'd also suggest an explicit warning in case it is still set to zero, instead of the rather misleading (and inaccurate) "server unavailable or unable to receive mail" for any MX with both A and records. On the same topic: what if smtp_mx_address_limit was simply made to apply for each family separately? E.g. the default of 5 would mean: keep max 5 IPv6 addresses _and_ max 5 IPv4's ? That would a) eliminate the need for balancing the mix, b) simplify the code, and c) allow the client to honor the smtp_address_preference setting in a safe way. Separate limit parameters for each family would also do the job, but that would probably be overkill. Luc
Re: Bug report: problem with smtp_mx_address_limit = 0
Probably better to not allow a limit-less smtp_mx_address_limit, as it makes Postfix vulnerable to resource exhaustion attack. Wietse
Bug report: problem with smtp_mx_address_limit = 0
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 .
The Postfix logs show that both IP's are found in DNS :
"begin address list"
"pref 300 host /
"pref 300 host /
"end 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 '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
