> Of course, SIOCGIFCONF isn't even close to provide the list of local
> addresses.
> Obvious example: it doesn't enlist all addresses 127.0.0.1, 127.0.0.2 etc.
> on common systems. If you handle 127.0.0.2 as local, you apply side
> knowledge about properties of loopback interface.
Well, 127.0.0.2 isn't a local address on my systems. It happens to pong
if you ping, but that's a matter of its netmask (/255.0.0.0) and the
"bounce all traffic" feature.
> Less obvious example: routes added to `local' table.
> SIOCGIFCONF can never show them.
We're not talking about routes and rules, we're still talking about
network addresses and the corresponding subnet masks. Don't digress to
complicate things.
> On Thu, Sep 06, 2001 at 04:17:49PM +0200, Matthias Andree wrote:
> > I'm not sure where and why you deduce the idea this is about MTA loop
> > detection or peer recognition.
>
> All other reasons are absolutely artificial.
Well, Postfix itself uses netmasks to obtain DEFAULT values. You can
override these, so there is absolutely no point in discussing this.
> > Or just use IPADDR_ANY...
>
> If the mailer's socket is bound to IPADDR_ANY, it's hard to find which
> connection attempts will be handled locally, so the best way to handle it is
> to ask the admin.
The MTA is to handle every connection attempt, and it is to make other
decisions based on whether the /peer/ is on a direct link or is routed.
There's absolutely no point in making decisions based on the local
address the client connected to.
> The language of that section is amazing:
> An SMTP MUST accept and recognize a domain literal for any of
> its own IP addresses.
> What might be ``own IP addresses'' of ``an SMTP''?..
> Does SMTP server have ``own IP addresses'' at all?
Please stop these harassments. We're talking about broken or
non-portable SIOCGIFNETMASK behaviour and not ranting about anything
else, particularly not about Internet Standards.
-- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/