On Sat, May 05, 2001 at 10:38:55AM -0700, Michael Fair wrote:
> I also had envisioned matching that scheme at the
> top of the mailstore as well.
>
> /ip.address1.of.host/user/bob
> /ip.address2.of.host/user/bob
Please do not use IP addresses in directoty names, use the domain names
instead. I
D]>
Sent: Friday, May 04, 2001 5:03 PM
Subject: Re: How to add virtual domain support
> Joe Rhett wrote:
> > > The main point of this is to actually get some virtual hosting
within a
> > > single mailstore. The use_ip_as_realm patch will provide most of the
>
Joe Rhett wrote:
> > The main point of this is to actually get some virtual hosting within a
> > single mailstore. The use_ip_as_realm patch will provide most of the
> > changes needed to do either named or ip vhosts, primarily how
> > information (mailboxes, acls, message flags, etc) is sep
On Fri, 4 May 2001, Joe Rhett wrote:
> If you have a different DNS name & IP address for each virtual domain,
> you'll need a different SSL certificate for each one or the browser will
> complain upon establishing a connection -- long before SASL issues are
Doh. I realized my mistake a minute af
> > > I have a suggestion on this subject. What about the possibility of
> > > binding a realm to a local address for cyrus (IP based vhost)? Yes,
> > > authentication and named vhosts via username and realm is ideal, but
> > > given that that information is usually not explicitly send by the
> >
> > The best way is to have the client log into a single hostname with a single
> > IP (and single matching certificate) but provide domain information during
> > the login.
>
> This is indeed a better idea, which already has been discussed. My
> opinion is that the server should have the option
On Fri, 4 May 2001, Joe Rhett wrote:
> > I have a suggestion on this subject. What about the possibility of
> > binding a realm to a local address for cyrus (IP based vhost)? Yes,
> > authentication and named vhosts via username and realm is ideal, but
> > given that that information is usually n
Joe Rhett wrote:
>
> It's not possible at that level, which is what I was saying.
>
> The best way is to have the client log into a single hostname with a single
> IP (and single matching certificate) but provide domain information during
> the login.
This is indeed a better idea, which already
Joe Rhett wrote:
>
> > I have a suggestion on this subject. What about the possibility of
> > binding a realm to a local address for cyrus (IP based vhost)? Yes,
> > authentication and named vhosts via username and realm is ideal, but
> > given that that information is usually not explicitly send
It's not possible at that level, which is what I was saying.
The best way is to have the client log into a single hostname with a single
IP (and single matching certificate) but provide domain information during
the login.
The second, non-scaleable approach is a different configuration per IP
ad
> I have a suggestion on this subject. What about the possibility of
> binding a realm to a local address for cyrus (IP based vhost)? Yes,
> authentication and named vhosts via username and realm is ideal, but
> given that that information is usually not explicitly send by the
> client, if the ima
- Original Message -
From: "Todd Nemanich" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 27, 2001 9:11 AM
Subject: Re: How to add virtual domain support
> Michael Fair wrote:
> > Yes, the Cyrus server supports realms though it is largely
&
Michael Fair wrote:
> Yes, the Cyrus server supports realms though it is largely
> unused. Currently SASL just fills the realm info in with
> the hostname of the machine. You can see this when you do
> "sasldblistusers".
>
> In regards to all clients supportnig SASL. Perhaps it's only
> a matt
> > The problem is that email clients don't supply the realm
> > information when they authenticate. If they log in as
> > their email address then this isn't a problem because
> > the login name contains the domain info but the "holy
> > grail" in my mind's eye would be to allow [EMAIL PROTECTED
>[...]
>>> What about SASL?
>>> SASL has different 'Login realms' - use the domain as realm.
>> The problem is that email clients don't supply the realm
>> information when they authenticate. If they log in as
>> their email address then this isn't a problem because
>> the login name contains the
>
> The problem is that email clients don't supply the realm
> information when they authenticate. If they log in as
> their email address then this isn't a problem because
> the login name contains the domain info but the "holy
> grail" in my mind's eye would be to allow [EMAIL PROTECTED]
> an
[...]
>> What about SASL?
>> SASL has different 'Login realms' - use the domain as realm.
> The problem is that email clients don't supply the realm
> information when they authenticate. If they log in as
> their email address then this isn't a problem because
> the login name contains the domain
>> I then planned that the users log in with their
>> email address (or a slightly modified version of
>> it to support older versions of Netscape and a
>> couple other MUA's that didn't like email addresses
>> as log in name) and rewrote the mailbox lookup
>> routines to return the new mailbox in
Ørnulf Nielsen wrote:
>
> [...]
> > I then planned that the users log in with their
> > email address (or a slightly modified version of
> > it to support older versions of Netscape and a
> > couple other MUA's that didn't like email addresses
> > as log in name) and rewrote the mailbox lookup
>
[...]
> I then planned that the users log in with their
> email address (or a slightly modified version of
> it to support older versions of Netscape and a
> couple other MUA's that didn't like email addresses
> as log in name) and rewrote the mailbox lookup
> routines to return the new mailbox in
20 matches
Mail list logo
