Just want to add my take on this subject. It's related to the IMAP
access control but more in a global way and not on a per-user basis.
It would be real nice if there was a way to disable IMAP search
capability within dbmail using a config line in dbmail.conf.
The reason is that no matter how much optimization goes into IMAP
search, it's just way too slow and overload the backend too much for the
feature it offers. Even with fulltext search enabled, the performance
issue will not go away as IMAP folders can easily contain 10s of
thousands of entries.
Most clients I believe already perform sender/subject/from/header
searches internally since they have to cache them regardless of
settings. Not sure if Thunderbird would use internal mech for body
searches if IMAP offline features are checked for all the folders.
For a large install of dbmail, IMAP search is just too costly for the
benefit it offers.
Xing
----------------------
Feature Suggestion:
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000006&nbn=3#bugnotes
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.
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.
