Sven Hartge wrote:
> Heiko Schlittermann<hs@???> wrote:
>> W B Hacker<wbh@???> (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.
