| Main Archive Page > Month Archives > postfix-users archives |
Problem matching IPv6 link-local in cidr-map
From: Bernhard Schmidt <berni_at_nospam>Date: Mon Nov 08 2010 - 19:27:43 GMT
To: postfix-users@postfix.org
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+xxx@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