> I read the RFC, and along with it being terse to the point of > (IMHO)inadequately describing what's happening, it basically > looks like it's a way for a user to set their own restrictions. > That might make sense if we supported per-mailbox quotas and > message limits (I don't think we have the column for that, > though, but I haven't looked recently) but since we only > support per-user quotas, they should be read-only. Who lets a > user change their own primary quota!?
That's exactly what I thought when proposing the default NO answer. So for 2.0.x this would imho be a way to go for QUOTA compliance, as there's no such column in the tables and changing the table structure in the stable branch would be kinda weird :o) For a future release I'm curious if adding another table between dbmail_users and dbmail_mailboxes (besides acl and subscription) for quotas would be good database design as the multiple relationships between dbmail_users and dbmail_mailboxes created by dbmail_subscription, dbmail_acl and the owner_idnr look a little non-normalized to me. Wouldn't it be possible to keep acls, subscriptions as well as an owner flag in *one* table between dbmail_users and dbmail_mailboxes? -- Wolfram
