I've done some thinking about the many suggestions about handling
the limits and wanted to summarize some of the pros & cons.

First was whether to use a generic approach that had a
table with domain, name, value which has a row for each
parameter, or to use a single row will all values per domain.

The pros:

 - allows extensability - we can easily add new attributes with a new row

The cons:

 - consumes more space - there's overhead of N-1 times the size of
   the domainname, plus N times the size of the option name, plus
   overhead for the value to be able to hold the largest possible value
   even for smaller items.
 - updates not atomic - there would have to be N update statements to
   change a value.  We would have to encapsulate the updates within a
 - performance - there would be more data going back and forth to/from
   the sql server.  We would also have to store all data as strings in
   the database and do conversions.  When we perform updates, there would
   have to be N updates sent to the server, which is N round trips plus
   the transaction overhead.

At first when I saw the suggestion I thought it was a great idea,
however after thinking it over, I believe performance and reliability
would suffer just to save an "alter table" if/when the schema needs to
be extended.

That being said, I'll continue down the path of a single row per domain,
however if others have arguments to the contrary, please speak up.

The schema needs to be adjusted to accomodate all the requests I've seen.
Both the C structure and the database schema needs to change.

I've read the Maildir++ quotas and understand that the concept of a
"Maildir quota" encapsulates both a maximum size and maximum message count.
It appears to be just a string that contains "#S,#C", which combines
the Size and the Count into one string, where the #C is optional.  I
personally would want them separated as two values, since you can't do
much with the combined string but pass it around.  To actually use it,
you need to split them up with a parser and convert them to numbers.
I think the API should keep them as numbers in the structure in C.  Its
easy enough to combine them with a snprintf(), but more work to parse
them out to actually use/enforce them.  How they're stored in the database
and/or file doesn't really matter (but should be discussed).  I believe
they were combined due to the old hack to put the quota value into
the "shell" field of a password record.  Being that we're in new
territory here, we don't even have the concept of message count in
.qmailadmin-limits files or the database, so adding a field/column
for the "default per-user message count" or "per-domain message count"
shouldn't be an issue, and would even keep the old fileformat backward
compatible.  In fact, it appears the vqpasswd structure has already
been amended to add a "clear password", so why wasn't it just updated
to add fields for "storage quota" and "max message count" ?  Wouldn't
that be cleaner?  Sorry for going off topic...  I'll stick to the subject

So my suggestion would be to store 4 "quota type" fields to handle
storage/message count for per-domain/per-user.  Any comments?

Here's what I would see as a new C structure:

 * permissions for non-postmaster admins

struct vlimits {
      int       maxpopaccounts;
      int       maxaliases;
      int       maxforwards;
      int       maxautoresponders;
      int       maxmailinglists;
      int       diskquota;
      int       maxmsgcount;
      int       defaultquota;
      int       defaultmaxmsgcount;
      /* the following are 0 (false) or 1 (true) */
      short     disable_pop;
      short     disable_imap;
      short     disable_dialup;
      short     disable_passwordchanging;
      short     disable_webmail;
      short     disable_relay;
      short     disable_smtp;
      /* the following permissions are for non-postmaster admins */
      short     perm_account;
      short     perm_alias;
      short     perm_forward;
      short     perm_autoresponder;
      short     perm_maillist;
      short     perm_maillist_users;
      short     perm_maillist_moderators;
      short     perm_quota;
      short     perm_defaultquota;

We need to patch qmailadmin to create another "AdminType"
to distinguish between "postmaster" and user admins.  The
perm_??? items would have the VLIMIT_DISABLE_xxx masks
applied to them.

I'm sure there are other ways to handle this, such as
consolidate the maillist permissions to a single item
and add more bit flags to handle users & moderators.
But this can be done in the API function before it hits
the file or database.

And here's what I would see as a new database schema:

create table vlimits (
      domain                   CHAR(64) PRIMARY KEY,
      maxpopaccounts           INT(10) NOT NULL DEFAULT -1,
      maxaliases               INT(10) NOT NULL DEFAULT -1,
      maxforwards              INT(10) NOT NULL DEFAULT -1,
      maxautoresponders        INT(10) NOT NULL DEFAULT -1,
      maxmailinglists          INT(10) NOT NULL DEFAULT -1,
      diskquota                INT(12) NOT NULL DEFAULT -1,
      maxmsgcount              INT(12) NOT NULL DEFAULT -1,
      defaultquota             INT(12) NOT NULL DEFAULT -1,
      defaultmaxmsgcount       INT(12) NOT NULL DEFAULT -1,
      disable_pop              TINYINT(1) NOT NULL DEFAULT 0,
      disable_imap             TINYINT(1) NOT NULL DEFAULT 0,
      disable_dialup           TINYINT(1) NOT NULL DEFAULT 0,
      disable_passwordchanging TINYINT(1) NOT NULL DEFAULT 0,
      disable_webmail          TINYINT(1) NOT NULL DEFAULT 0,
      disable_relay            TINYINT(1) NOT NULL DEFAULT 0,
      disable_smtp             TINYINT(1) NOT NULL DEFAULT 0,
      perm_account             TINYINT(2) NOT NULL DEFAULT 0,
      perm_alias               TINYINT(2) NOT NULL DEFAULT 0,
      perm_forward             TINYINT(2) NOT NULL DEFAULT 0,
      perm_autoresponder       TINYINT(2) NOT NULL DEFAULT 0,
      perm_maillist            TINYINT(4) NOT NULL DEFAULT 0,
      perm_quota               TINYINT(2) NOT NULL DEFAULT 0,
      perm_defaultquota        TINYINT(2) NOT NULL DEFAULT 0

Note that this schema would take up *alot* less room than
the generic name/value alternative with little wasted space.

We need to figure out what other items are needed or desired.
This will also require that we have more developers go in and
start modifying the programs/utilities to actually *use* these 
limits.  There are some that go all the way back to qmail
itself (i.e. smtp) as well as into imap, webmail, etc.

This is a discussion list, so please provide comments...



Reply via email to