The following issue has been RESOLVED. ====================================================================== http://www.dbmail.org/mantis/view.php?id=6 ====================================================================== Reported By: Dead2 Assigned To: paul ====================================================================== Project: DBMail Issue ID: 6 Category: IMAP daemon Reproducibility: always Severity: feature Priority: normal Status: resolved Resolution: fixed Fixed in Version: ====================================================================== Date Submitted: 09-Jul-04 11:57 CEST Last Modified: 31-Aug-05 14:27 CEST ====================================================================== Summary: Access control for IMAP Description: In my setup I want only certain people to be allowed to use the IMAP service. I suggest we set up a flag for this in the database.
acl->can_imap ? ====================================================================== ---------------------------------------------------------------------- Dead2 - 09-Jul-04 11:59 ---------------------------------------------------------------------- Actually, this should be added to pop3 and optionally webmail aswell. Since an ISP might want to disable a users access to his mailbox if he does not pay. But they might not want to delete the user or disable incoming mails. ---------------------------------------------------------------------- ilja - 09-Jul-04 14:11 ---------------------------------------------------------------------- This can be done by adding the following fields to the users table: can_imap (obvious) can_pop (obvious) can_sieve (is allowed to have sieve scripts (for later, when Sieve is implemented) etc? ---------------------------------------------------------------------- aaron - 15-Oct-04 18:25 ---------------------------------------------------------------------- With this response, let's pop over to the mailing list for a little while. But, I'm thinking, columns strikes me as a bad idea. It means a database upgrade for every new feature that we might want to control. Instead, we can add a permissions table that grants or removes privileges to the various daemons. With client_idnr in the mix, we can do things like say, "Client X pays for POP3, Client Y pays for IMAP and Client Z pays for both." We should consider how/if this will interact with the user account and client account suspensions feature that has been so often requested. ---------------------------------------------------------------------- paul - 31-Aug-05 14:27 ---------------------------------------------------------------------- I'm setting this one to resolved since this (and more) can be achieved with the usermap feature in 2.1 Issue History Date Modified Username Field Change ====================================================================== 09-Jul-04 11:57 Dead2 New Issue 09-Jul-04 11:59 Dead2 Note Added: 0000001 09-Jul-04 14:11 ilja Note Added: 0000002 09-Jul-04 14:11 ilja Status new => acknowledged 09-Jul-04 14:11 ilja Issue Monitored: ilja 15-Oct-04 18:25 aaron Note Added: 0000314 31-Aug-05 14:27 paul Status acknowledged => resolved 31-Aug-05 14:27 paul Resolution open => fixed 31-Aug-05 14:27 paul Assigned To => paul 31-Aug-05 14:27 paul Note Added: 0000901 ======================================================================
