Hi,

postfix 2.7.1 on SLES 10.3 i586 (probably not important, but who knows).

We run a production mailserver with reject_unknown_client_hostname enabled (for a few years now). To deal with the unavoidable misconfigurations we have a very large whitelist which was created automatically from years of message tracking and is also regularly updated. So far so good.

smtpd_client_restrictions =
        [...]
check_client_access cidr:${config_directory}/maps/access.client.connect-stage.cidr,
        [...]
        reject_unknown_reverse_client_hostname,
        reject_unknown_client_hostname,

This system is also IPv6-enabled. Since broken reverse DNS is a bit more common in the IPv6 world AND those problems remain unnoticed for much longer (as there are not nearly enough IPv6-enabled destinations outside), we override this check for the whole global IPv6 address block in above listed access.client.connect-stage.cidr:

2000::/3                OK

So far so good, take two. Now we are bitten by a special feature of IPv6. Systems (running postfix) in the same subnet as the mail servers that do NOT have a global IPv6 address configured (but the IPv6 stack loaded) still try IPv6. They use the link-local address (fe80::/64) to connect to the server ... and get rejected due to missing reverse DNS:

Nov  8 17:15:46 lxmhs17 postfix/smtpd[15061]: NOQUEUE: reject: RCPT from
unknown[fe80::250:56ff:fea9:2c72%vlan6]: 550 5.7.1 Client host rejected:
cannot find your reverse hostname, [fe80::250:56ff:fea9:2c72%vlan6];
from=<> to=<root+...@yyy.zzz.de> proto=ESMTP
helo=<xxx.yyy.zzz.de>

See the %vlan6 scope identifier at the address. Unfortunately, this seems to prevent the CIDR table from matching when we whitelist the link-local address range.

fe80::/64               OK

% postmap -q fe80::250:56ff:fea9:2c72%vlan6 cidr:./access.client.connect-stage.cidr % postmap -q fe80::250:56ff:fea9:2c72 cidr:./access.client.connect-stage.cidr
OK
%

We can workaround using regexp tables (for example), but it's pretty inconvenient. Can this be fixed easily? Or is it a known limitation?

Thanks,
Bernhard

Reply via email to