On Sep 12, 2014, at 1:55 PM, li...@rhsoft.net wrote: > > Am 12.09.2014 um 21:49 schrieb Philip Prindeville: >>> However, any time I connect via telnet to this server and specify >>> *any* IP address in the form [X.X.X.X], the smtpd_helo_restrictions >>> won't trigger. >> This is both legal and reasonable. >> >> If you’re a DHCP’d host running inside a NATting firewall, there’s a good >> chance that you don’t have a valid rDNS mapping (or at least not one that’s >> publicly visible, since your own address is probably inside on an RFC-1918 >> unroutable network number like 192.168.0.0/16 or 172.16.0.0/12 and not >> publicly resolvable), and the address that the remote MTA sees is going to >> be your firewall’s public address post-NATting, not your internal IP address >> on the LAN. > > it maybe true but it is *not* reasonable > > it's not rocket science to configure your mailserver using the > HELO name of the *public* IP matching the *public* PTR and > *public* hostname independent of how many RFC-1918 networks > are between your box and the internet >
Who says anything about mail servers? What if it’s an MUA doing this? And even if it’s an MTA, you sure it’s such a trivial problem? Because this is an issue we dealt with in agonizing detail on the thunderbird developers mailing list… for close to 4 years. You can’t count on your local gateway speaking UPnP or NAT-PMP… and what if you’re on a doubly-NATted network (as AT&T typically does for their Universe and 4G customers)? Even if you discovered the public address of your innermost gateway, you still have no reliable way to interrogate any gateway’s beyond that one. You can’t count on STUN, and a lot of lightweight clients aren’t STUN, UPnP, or NAT-PMP aware. -Philip
