Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip alias

Steve VanDevender (stevev@efn.org)
Thu, 6 Sep 2001 12:10:18 -0700


Wietse Venema writes:
> Steve VanDevender:
> > Wietse Venema writes:
> > > If an MTA receives a mail relaying request for user@domain.name
> > > then it would be very useful if Linux could provide the MTA with
> > > the necessary information to distinguish between local subnetworks
> > > and the rest of the world. Requiring the local sysadmin to enumerate
> > > all local subnetwork blocks by hand is not practical.
> >
> > I think you're making a couple of unjustified assumptions here:
>
> You are making unjustified assumptions:
>
> If the kernel knows about subnets, then an application should be
> able to find out about them. Whether or not you agree with the
> application's reasons does not matter.

The only justification I've seen you offer so far for wanting this
netmask information is apparently to use to decide whether your MTA
should allow relaying to another host or not. As a sysadmin who manages
several large MTA installations I'd say that allowing relaying to or
from other hosts on "local" subnets as determined by available
interfaces and netmasks should at best be an option, and that option
should be off by default -- there are too many common situations where
that would open an MTA to abuse, or circumvent other controls one would
want to put on an MTA's relaying permissions. If you were just talking
about the problem of determining which IP addresses are bound to the
host, I wouldn't disagree with you, but you keep saying things that make
it look like you really want to have your MTA permit relaying by default
to all hosts in "local" networks based on available interfaces and
netmasks.

So if the only reason your application wants this information is to
apply it in a useless or even awful way, I'd have to question why you
feel the need to obtain the information at all. In a pure sense maybe
an application should be able to obtain this information, but in a
practical sense if there's no good use for the information in this
specific situation then why make a big fuss about not being able to
obtain it?
-
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/