> > As to disabling accounts, do you wish to block user access, or disable
> > mail delivery, or both? For the former I use the UNIX tactic of changing
> > the password string to !! and set the type to crypt.
>
> Right, except that if you're managing a system with many users, you
> don't wanna be resetting passwords, just disable the account.
Just change the encryption_type to something bogus, eg. "disabled".
The password isn't changed, and you just set the proper encryption_type
again to reenable it.
> Attached patch, is one way of doing so. Rewuires two new fields to be
> added to the dbmail_users table: webenabled, and popenabled, both
> boolean.
>
> webenabled allows pop/imap access from localhost, while popenabled
> allows access from everywhere. if webenabled is false, no access at all.
Proper support for capabilities is planned, and will be a nice
solution once there (not just a quick hack). For something trivial
like this, I would wholeheartedly recommend working within the existing
code, otherwise you end up having to maintain your own patch sets every
time you want to upgrade to a newer version of upstream source.
> Note that mail is still delivered. To change that behaviour, change the
> source :)
For smtp/lmtp, you could just fiddle with the aliases table (eg. update
all [EMAIL PROTECTED] aliases to [EMAIL PROTECTED]). Alternately,
you could bounce it in your mta (eg. make postfix look into a db table
with a check map in smtp_recipient_restrictions, and can bounce with a
custom message (found in the table)).
--
Jesse Norell
jesse @ kci.net
