Mailing List Archive

Feargal Reilly wrote:

> Has any though been given to the idea of imposing a quota per group,
> instead of per user?
>
> I want to allow clients to add as many addresses/accounts as they
> wish, but to limit their total storage space. While you could allow
> the client to manage the quota for each account, and limit the total
> through your management interface, it works against the KISS
> principle.
>
> I'm assuming here that the client_idnr field can be used for grouping
> mailboxes together.
>

Some other systems do that, and it is a *very* good idea IMHO, as it
makes better use of space, and simplifies admin.

Bill Hacker

Group quota is in fact implemented.. we use it all the time!
Each user has a client_id field. This way you can group users.
You'll have to add a table though to configure the max quota per
client_id group.
And add an interface to assign total quota's for such a group.

We connected dbmail to our client information system. Each client has x
mailboxes
and y quotum. She / he can divide the quota over the mailboxes with the
max of the
groupquota on the client_id.

I hope this makes sence ;)

Good luck!



On 25-nov-03, at 17:35, Feargal Reilly wrote:

> Has any though been given to the idea of imposing a quota per group,
> instead of per user?
>
> I want to allow clients to add as many addresses/accounts as they
> wish, but to limit their total storage space. While you could allow
> the client to manage the quota for each account, and limit the total
> through your management interface, it works against the KISS
> principle.
>
> I'm assuming here that the client_idnr field can be used for grouping
> mailboxes together.
>
> --
> Feargal Reilly,
> Codeshifter,
> Chrysalink Systems.
>
_________________________
E.J.A. van Beek
ICT Manager
IC&S
T: +31 30 6355730
F: +31 30 6355731

PGP-key:
www.ic-s.nl/keys/eelco.txt

On Tue, 25 Nov 2003 18:51:50 +0100
Eelco van Beek - IC&S <eelco@ic-s.nl> wrote:

> Group quota is in fact implemented.. we use it all the time!
> Each user has a client_id field. This way you can group users.
> You'll have to add a table though to configure the max quota per
> client_id group.
> And add an interface to assign total quota's for such a group.
>
> We connected dbmail to our client information system. Each client has x
> mailboxes
> and y quotum. She / he can divide the quota over the mailboxes with the
> max of the
> groupquota on the client_id.
>

> I hope this makes sence ;)

It does, but it's not what I'm looking for, unless I'm entirely stupid.

I was hoping to override user quotas where a group quota exists, and to have this happen internal to dbmail. The implementation you describe relies on the user quota mechanism, whereas I'm proposing an extension to this.

This is the flow I would be expecting:
1) When a mail arrives to a mailbox, the client_idnr of the mailbox's owner is retrieved.
2) A query is made to a group quota table to get the quota for that client_idnr.
3) If a value is found, the total size of the mailboxes belonging to users with that client_idnr is retrieved and compared against it. If no value is set, it proceeds as normal by comparing the size of the mailboxes belonging to that user against the user's quota.

The reason I want to do it this way is precisely so the client doesn't have to juggle his quotum. While some clients will like to have this level of control, most just want to see email appearing on their computer screen, and don't want to be confronted with having to set limits on each staff account.

Hopefully this too makes sense... :)

-Feargal.

> Good luck!
>
>
>
> On 25-nov-03, at 17:35, Feargal Reilly wrote:
>
> > Has any though been given to the idea of imposing a quota per group,
> > instead of per user?
> >
> > I want to allow clients to add as many addresses/accounts as they
> > wish, but to limit their total storage space. While you could allow
> > the client to manage the quota for each account, and limit the total
> > through your management interface, it works against the KISS
> > principle.
> >
> > I'm assuming here that the client_idnr field can be used for grouping
> > mailboxes together.
> >
> > --
> > Feargal Reilly,
> > Codeshifter,
> > Chrysalink Systems.
> >
> _________________________
> E.J.A. van Beek
> ICT Manager
> IC&S
> T: +31 30 6355730
> F: +31 30 6355731
>
> PGP-key:
> www.ic-s.nl/keys/eelco.txt
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>


--
Feargal Reilly,
Codeshifter,
Chrysalink Systems.

You have precisely explained how it works.

I think the confusion is that Eelco said that you can "divide the quota over
the mailboxes" and you don't want to set any kind of per-user quota at all,
just a per group quota. That's fine. It works that way, too -- if you set 0
quota on each user, and 100 quota on the group, then each user may have as
much email as they want, so long as their common total is limited to 100 mb.

Aaron


Feargal Reilly <feargal@chrysalink.net> said:

> On Tue, 25 Nov 2003 18:51:50 +0100
> Eelco van Beek - IC&S <eelco@ic-s.nl> wrote:
>
> > Group quota is in fact implemented.. we use it all the time!
> > Each user has a client_id field. This way you can group users.
> > You'll have to add a table though to configure the max quota per
> > client_id group.
> > And add an interface to assign total quota's for such a group.
> >
> > We connected dbmail to our client information system. Each client has x
> > mailboxes
> > and y quotum. She / he can divide the quota over the mailboxes with the
> > max of the
> > groupquota on the client_id.
> >
>
> > I hope this makes sence ;)
>
> It does, but it's not what I'm looking for, unless I'm entirely stupid.
>
> I was hoping to override user quotas where a group quota exists, and to have
this happen internal to dbmail. The implementation you describe relies on the
user quota mechanism, whereas I'm proposing an extension to this.
>
> This is the flow I would be expecting:
> 1) When a mail arrives to a mailbox, the client_idnr of the mailbox's owner
is retrieved.
> 2) A query is made to a group quota table to get the quota for that client_idnr.
> 3) If a value is found, the total size of the mailboxes belonging to users
with that client_idnr is retrieved and compared against it. If no value is
set, it proceeds as normal by comparing the size of the mailboxes belonging to
that user against the user's quota.
>
> The reason I want to do it this way is precisely so the client doesn't have
to juggle his quotum. While some clients will like to have this level of
control, most just want to see email appearing on their computer screen, and
don't want to be confronted with having to set limits on each staff account.
>
> Hopefully this too makes sense... :)
>
> -Feargal.
>
> > Good luck!
> >
> >
> >
> > On 25-nov-03, at 17:35, Feargal Reilly wrote:
> >
> > > Has any though been given to the idea of imposing a quota per group,
> > > instead of per user?
> > >
> > > I want to allow clients to add as many addresses/accounts as they
> > > wish, but to limit their total storage space. While you could allow
> > > the client to manage the quota for each account, and limit the total
> > > through your management interface, it works against the KISS
> > > principle.
> > >
> > > I'm assuming here that the client_idnr field can be used for grouping
> > > mailboxes together.
> > >
> > > --
> > > Feargal Reilly,
> > > Codeshifter,
> > > Chrysalink Systems.
> > >
> > _________________________
> > E.J.A. van Beek
> > ICT Manager
> > IC&S
> > T: +31 30 6355730
> > F: +31 30 6355731
> >
> > PGP-key:
> > www.ic-s.nl/keys/eelco.txt
> >
> > _______________________________________________
> > Dbmail-dev mailing list
> > Dbmail-dev@dbmail.org
> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >
>
>
> --
> Feargal Reilly,
> Codeshifter,
> Chrysalink Systems.
>
>



--

I would also like to see group quotas. If you're looking at implementing it,
naturally you should look towards to 2.0 branch. As far as I know, group
quotas are not implemented at all... but based on the current roadmap, this
will probably have to wait until 2.1.

With respect to the dbmail_config table (yes, the tables should all be
prefixed with dbmail_, hint hint Ilja ;-) it was intentional that there not be
an auto_increment column. I'm trying to convince everyone that we don't need
them; multimaster clustering (particularly with MySQL) is reasonably trivial
once you begin handling your own index column.

There is a UNIQUE constraint, however. Rather than config_idnr, think more
along the lines of cluster_name as an apt name. Here's how it looks:

CREATE TABLE dbmail_config (
cluster_name varchar(64) not null,
key varchar(255) not null,
value varchar(255) ,
primary key (cluster_name, key)
);

So what this means is that the *combination* of a cluster_name and a key
creates the primary unique index. This allows multiple clusters of machines to
share the same database. An application of this might be having physically
separate front end mail exchangers for several domains, each of which runs a
local database that is multi-mastered with other domains that you also run,
each of which is also on a separate host. By multimastering the database, each
machine can transparently run as a backup of the other simply by starting up
new DBMail processes with the failed machine's cluster_name.

Aaron


Feargal Reilly <feargal@chrysalink.net> said:

> Hi all,
> Picking up on something I was thinking about last November, but got
> distracted from.
>
> I want to implement group quotas for users based on their client_idnr.
>
> The idea is that you set a quota of say, 100M for a group of users.
>
> When a mail arrives for a user in that group, a further quota check is
> carried out against the combined mailbox size for all users in that group.
> If the mail pushes this total over the group quota, it is rejected.
>
> The normal quota checks would still be carried out for that user, so that
> some people can still be restricted.
>
> I know some people kinda do this by averaging the group quota across the
> number of users in that group, or by using some management interface to
> juggle the individual quotas.
> However, this doesn't work in cases where the client doesn't care, they
> just want to pay x euros for y megs of space.
>
> Last time I broached this, I was told the mechanism already exists. If it
> does, it's not in the 1.2.3 code.
>
> In terms of mechanism, I was looking at using the config table to store
> the group quotas.
>
> I looked at the structure of this table and noticed something puzzling:
>
> config_idnr | integer | not null default '0'
> item | character varying(255) | not null
> value | character varying(255) | not null
>
> The config_idnr doesn't have a unique constraint - is this by design, or
> by accident?
>
> If it's by design, the implication is that usage is intended to group
certain types of config entries together. e.g. all the entries relating to
group quotas would have config_idnr=123, whereas all entries relating to
disabled users would have config_idnr=42. If this were the case, then
> is there a plan to avoid duplicating numbers for different purposes,
possibly publishing a list of used ones?
> Given the lack of indexing, I'm guessing that it's just that the table
hasn't really been used, and thus this hasn't been an issue. If that's the
case, then how *should* it be used? Should the config_idnr be unique and/or
auto-incrementing?
>
> Feedback please? I'd like to do this correctly so it can be committed to
further releases, so if people see a problem with this in their dbmail
deployment, please say so.
>
> Cheers,
> -Feargal.
>
> --
> Feargal Reilly,
> Codeshifter,
> Chrysalink Systems.
>
>
--