Sven Hartge wrote:
Heiko Schlittermann<[email protected]> wrote:
W B Hacker<[email protected]> (Thu Feb 17 03:48:30 2011):
Questions:
- do other POP/IMAP do this any differently? (eg: Dovecot)
Since POP/IMAP access is magnitudes less frequently, this side of the
problem does not matter.
Concerning Dovecot:
I just recently learned that dovecot is able to store the quota data in
a SQL database instead of a maildirsize file.
http://wiki2.dovecot.org/Quota/Dict
So right now I am looking forward to test this, because this also solves
(at least) my problem of being able to test a mailbox for being over
quota at the MX layer of my mailserver setup, which I have not been able
to do with Courier/maildir. Of course, you need to use dovecot-lda to
deliver the messages to the users mailbox to have the quota table
updated correctly.
But I have not tested such a setup so I cannot tell if this scales or is
horribly slow.
Grüße,
Sven
We use Dovecot with Exim - both driven off local copies of the same 'master'
PostgreSQL DB. This has solved many problems, made possible many unusual or
edge-case features, and - so far- not once ever posed a problem. (Ditto Prayer
Wemail, with or without Perdition).
FWIW, courier-mta and its components, courier-imap included, are also amenable
to PostgreSQL 'management'. Indeed, those are what we used before adopting Exim
for its in-session smtp decision making skills.
All that said - adding SQL to the smtp/POP/IMAP food chain should not be done
lightly. It needs extra resources, extra admin skills and work, adds yet-another
possible point of failure [1] and cannot always provide payback for the 'cost'
of those.
YMMV,
Bill Hacker
[1] To be fair, PostgreSQL, as used here, JFDNB. Server CPU or PSU fan will wear
out, or VR caps pop their tops before PG falls over.
--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/