[prev in list] [next in list] [prev in thread] [next in thread] 

List:       info-cyrus
Subject:    Re: [STATUS] Virtual domain support (7/19/02)
From:       Michael Fair <michael () daclubhouse ! net>
Date:       2002-07-24 18:13:06
[Download RAW message or body]

There are stateful packet inspecting software
bandwidth throttling programs which would work
even on IP aliases.  Especially a *BSD/Linux
box acting as a firewall/traffic shaping bridge.

In this case any ordinary IP firewall rule is 
used to dictate the up/down bandwidth.

Though I'm with Jeremy on the threat analysis.
It seems to me that the number of end users 
smart enough to actually A) know that they
don't have to use what they were told, and
B) figure out what other IP they could use,
and C) know they are going to get more 
bandwidth for their email out of it versus
the number of people who just do what they're
told and have a hard time even doing that isn't
worth any herculian efforts to defend against.

I can see three options:
A) Use the restriction method you mentioned
(though I certainly think as an option and
not the default (what implications does this
have for a Murder setup?))

B) Get to it the next time around in a 
2.2.x release.

C) Make a flag that enforces the domain name
   following the '@' must either not exist or
   must match the domain retrieved from the IP
   address.


Out of curiousity.... How is the domain determined
from the IP address is it a config option somewhere
or does it just use whatever is returned from the
reverse lookup on the IP number?  If the latter, 
then either the hosts file or the DNS entries 
need to be modified (and one doesn't always have 
control over the reverse lookup responses).

-- Michael --

----- Original Message ----- 
From: "Ken Murchison" <ken@oceana.com>
To: "Jeremy Howard" <jh_lists@fastmail.fm>
Cc: "Cyrus Mailing List" <info-cyrus@andrew.cmu.edu>
Sent: Wednesday, July 24, 2002 10:00 AM
Subject: Re: [STATUS] Virtual domain support (7/19/02)


> 
> 
> Jeremy Howard wrote:
> > 
> > Ken Murchison wrote:
> > 
> > > - disallow user@dom.ain logins on wrong IP (might be difficult w/o
> > > breaking default domain logins)
> > 
> > I've been thinking about that too--it makes things complex. Personally
> > if it came down to a choice, I think maintaining default domain support
> > should have higher priority--the only argument I can think of for IP
> > domain restrictions is bandwidth tracking, which can be done by adding
> > rate tracking directly to the code anyway (such as my rate_chk patch
> > from a few months back).
> 
> The one way that I can easily prevent this is to make multiple-ip
> support mutually exclusive from user@domain support via a config option
> (ie, multipleip, or useipdomain, etc).  When useipdomain is on, I don't
> bother looking at the loginid and automatically try to authenticate
> using the domain from the ip address.  When useipdomain is off, I can
> either always use the loginid and ignore the domain from the ip, or
> allow both (user@domain having higher priority).
> 
> If I stick with the current implementation, there is no easy way to
> prevent a user from using someone else's ip (and/or bandwidth.
> 
> Thoughts?
> 
> When I first implemented this, I hadn't anticipated people actually
> using a separate NIC for each domain.  I assumed that people would use
> ipaliases, in which case bandwidth isn't an issue.
> 
> Ken
> -- 
> Kenneth Murchison     Oceana Matrix Ltd.
> Software Engineer     21 Princeton Place
> 716-662-8973 x26      Orchard Park, NY 14127
> --PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp
> 

[prev in list] [next in list] [prev in thread] [next in thread]