You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Danny Angus <da...@gmail.com> on 2006/10/26 15:33:14 UTC

POP3 Virtual Hosting - Danny's vision

Hi,

please read this if you have an opinion on vhosting, I hope this is a
compromise which allows everyone to achieve their goals.

It is just a suggestion, giving a bit more detail about how to do
vhosting the "danny way"...
I believe it answers *everyones* concerns about vhosting, and is based
on literally _years_ of debate on this list about it.

I recently wrote:
> > Right.
> > All we need to do is to allow the <pop3server> blocks to take the
> > repository as a config param. and to let the local delivery mailet do
> > the same thing.

And Norman replied:
> I think thats cool.. but i don't see so many user cases. I prefer the
> "normal" vhosting like vpopmail etc do it

To which I reply...

It is incedibly simple, and quite intuitive to James admins, look at
this mock-up...

first one filters mydomain.tld into its own repo...

  <mailet match="HostIs=mydomain.tld" class="LocalDelivery">
     <inboxRepository>file://var/mail/inboxes/mydomain.tld</inboxRepository>
  </mailet>

next one catches the ones which fall through..

  <mailet match="RecipientIsLocal" class="LocalDelivery">
     <inboxRepository>file://var/mail/inboxes/mydomain.tld</inboxRepository>
  </mailet>


You can use this with either:
  1/a name based scheme, which allows you to map your domains to your
user and inbox repositories

  <pop3server enabled="true">
      <port>110</port>
Config users logging-in with @mydomain.tld to use their repo
      <domain>
          <match>mydomain.tld</match>
          <userRepository>file://var/users/mydomain.tld</userRepository>
          <inboxRepository>file://var/mail/inboxes/mydomain.tld</inboxRepository>
      </domain>

Config users logging-in without @ to use default repo
      <domain>
          <match></match>
          <userRepository>file://var/users/default</userRepository>
          <inboxRepository>file://var/mail/inboxes/default</inboxRepository>
      </domain>

      <handler>
         <helloName autodetect="false">mydomain.tld</helloName>
         <connectiontimeout>120000</connectiontimeout>
      </handler>
   </pop3server>

  2/an ip based scheme which binds pop3servers to IP addresses (or
just different ports) and repositories using *exact same* pop3server
config e.g...

  <pop3server enabled="true">
      <port>110</port>
      <bind>127.0.0.1</bind>
      <domain>
          <match></match>
          <userRepository>file://var/users/default</userRepository>
          <inboxRepository>file://var/mail/inboxes/mydomain.tld</inboxRepository>
      </domain>
      <handler>
         <helloName autodetect="false">mydomain.tld</helloName>
         <connectiontimeout>120000</connectiontimeout>
      </handler>
   </pop3server>

Bingo, virtual hosting the James way...

Feel free to flame me, I'm a big boy :-)

d.

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: POP3 Virtual Hosting - Danny's vision

Posted by Danny Angus <da...@gmail.com>.
On 10/26/06, Stefano Bagnara <ap...@bago.org> wrote:

> We was pursuing the above goal, and I think we should consider it if we
> want to talk about real world use of virtual hosting.
>
> Do you agree with this goal? If yes, can you elaborate more on the
> "danny way" wrt this goal?


I agree with the goal, and I it would be perfectly possible from the
way James works for the <domain> in the example to bind to a component
which provides the config from any resource, e.g. file, db, or direct
config params.
<domainConfig> (as last example)
<domainDB> takes a DBURL
<domainProps> takes a filename

Of course the local-delivery mailet would then need to be changed to
get its params from the same place too, and you might need a special
matcher.

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: POP3 Virtual Hosting - Danny's vision

Posted by Danny Angus <da...@gmail.com>.
On 10/26/06, Norman Maurer <nm...@byteaction.de> wrote:

> If we have to check for same stuff on many places i whould prefer to
> create a service which provide such infos..

I agree.

d.

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: POP3 Virtual Hosting - Danny's vision

Posted by Norman Maurer <nm...@byteaction.de>.
Danny Angus schrieb:
> On 10/26/06, Stefano Bagnara <ap...@bago.org> wrote:
>
>> We was pursuing the above goal, and I think we should consider it if we
>> want to talk about real world use of virtual hosting.
>>
>> Do you agree with this goal? If yes, can you elaborate more on the
>> "danny way" wrt this goal?
>
>
> I agree with the goal, and I it would be perfectly possible from the
> way James works for the <domain> in the example to bind to a component
> which provides the config from any resource, e.g. file, db, or direct
> config params.
> <domainConfig> (as last example)
> <domainDB> takes a DBURL
> <domainProps> takes a filename
>
Sorry Danny but i don't understand what you try to show us.. Can you
give a more detailed example ?

> Of course the local-delivery mailet would then need to be changed to
> get its params from the same place too, and you might need a special
> matcher.
If we have to check for same stuff on many places i whould prefer to
create a service which provide such infos..


bye
Norman



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: POP3 Virtual Hosting - Danny's vision

Posted by Stefano Bagnara <ap...@bago.org>.
I think that we need a way to let James manage a lot of domains (let say 
100) with few users for each one and have it automatically manageable 
via db and without config.xml changes and without james restart.

I was working with Norman toward this solution.

Before talking of the real implementation details I think we should talk 
about the goal.

We was pursuing the above goal, and I think we should consider it if we 
want to talk about real world use of virtual hosting.

Do you agree with this goal? If yes, can you elaborate more on the 
"danny way" wrt this goal?

Stefano

Danny Angus wrote:
> Hi,
> 
> please read this if you have an opinion on vhosting, I hope this is a
> compromise which allows everyone to achieve their goals.
> 
> It is just a suggestion, giving a bit more detail about how to do
> vhosting the "danny way"...
> I believe it answers *everyones* concerns about vhosting, and is based
> on literally _years_ of debate on this list about it.
> 
> I recently wrote:
>> > Right.
>> > All we need to do is to allow the <pop3server> blocks to take the
>> > repository as a config param. and to let the local delivery mailet do
>> > the same thing.
> 
> And Norman replied:
>> I think thats cool.. but i don't see so many user cases. I prefer the
>> "normal" vhosting like vpopmail etc do it
> 
> To which I reply...
> 
> It is incedibly simple, and quite intuitive to James admins, look at
> this mock-up...
> 
> first one filters mydomain.tld into its own repo...
> 
>  <mailet match="HostIs=mydomain.tld" class="LocalDelivery">
>     <inboxRepository>file://var/mail/inboxes/mydomain.tld</inboxRepository>
>  </mailet>
> 
> next one catches the ones which fall through..
> 
>  <mailet match="RecipientIsLocal" class="LocalDelivery">
>     <inboxRepository>file://var/mail/inboxes/mydomain.tld</inboxRepository>
>  </mailet>
> 
> 
> You can use this with either:
>  1/a name based scheme, which allows you to map your domains to your
> user and inbox repositories
> 
>  <pop3server enabled="true">
>      <port>110</port>
> Config users logging-in with @mydomain.tld to use their repo
>      <domain>
>          <match>mydomain.tld</match>
>          <userRepository>file://var/users/mydomain.tld</userRepository>
>          
> <inboxRepository>file://var/mail/inboxes/mydomain.tld</inboxRepository>
>      </domain>
> 
> Config users logging-in without @ to use default repo
>      <domain>
>          <match></match>
>          <userRepository>file://var/users/default</userRepository>
>          <inboxRepository>file://var/mail/inboxes/default</inboxRepository>
>      </domain>
> 
>      <handler>
>         <helloName autodetect="false">mydomain.tld</helloName>
>         <connectiontimeout>120000</connectiontimeout>
>      </handler>
>   </pop3server>
> 
>  2/an ip based scheme which binds pop3servers to IP addresses (or
> just different ports) and repositories using *exact same* pop3server
> config e.g...
> 
>  <pop3server enabled="true">
>      <port>110</port>
>      <bind>127.0.0.1</bind>
>      <domain>
>          <match></match>
>          <userRepository>file://var/users/default</userRepository>
>          
> <inboxRepository>file://var/mail/inboxes/mydomain.tld</inboxRepository>
>      </domain>
>      <handler>
>         <helloName autodetect="false">mydomain.tld</helloName>
>         <connectiontimeout>120000</connectiontimeout>
>      </handler>
>   </pop3server>
> 
> Bingo, virtual hosting the James way...
> 
> Feel free to flame me, I'm a big boy :-)
> 
> d.



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org