Mikhail Ramendik wrote:
Paul J Stevens wrote:
I use it too. And don't plan on abandoning the clients who pay me to
provide email services for their students
and employees. Typically many small mailboxes. That's where dbmail is
quite good atm.
Agreed. For many small mailboxes the current code may be great -
especially if *most* people download their mail (with POP3, or with IMAP
that is used as another POP3), and therefore searching is not used.
The problems are with searching performance, and with downloading on BIG
boxes.
I'm running about 5000 mailboxes over ten domains, most with less than 100 messages (though some of the imap users have 60-100,000). When I was using postfix maildirs and courier-imap, the imap users with huge mailboxes used to lock up the server when they did searches.. Now, even with dbmail's less-than-optimal sql searching, it runs about fifty times faster.
I figure, it's all uphill from here.
After that, replacing dbmail-smtp, dbmail-util and dbmail-user with
python-based rewrites could lead to a nice
set of base-classes to tackle the more complex task of replacing the
daemons should we choose to do so (or
find someone crazy enough). However, eliminating the code required by
the stand-alone tools will have the
added benefit of a good spring cleaning in the source tree.
If we go this way, we are stuck with the existing storage until the
daemons get rewritten.
But this means we are stuck with slow searching, and somewhat slow
fetching.
Within the current storage, searching can be improved by using fulltext
non-indexed regexp searching (although I'm not sure if it works with
pgsql). And fetching can be improved by using is_header, and moving
everything *except* actual messageblk retrieval into one query per fetch
(not per message).
But this is quite limited. And adding separate header tables could break
the current code.
What about the proposed idea to have the header stored in a seperate
field in addition to the messageblks? dbmail could check for a field in
the header table, and if it doesn't exist for the message being grabbed,
use the old mechanism to parse (and copy the header to the header table
for future reference), or a hard upgrade could be done with a header
import script of some sort..
-Sri
