> 1. DBMail doesn't support "shared" mailboxes well -- where multiple > users can access the same mailbox. However I would assume it allows > multiple IMAP clients owned by the same user to access the > same folder > at the same time. This isn't explicitly stated, and I just > want to make > sure.
1.0/2.0 - multiple access to same imap folder work 2.0 - (currently in final beta) supports shared mailboxes, and a lot more features. > 4. With MySQL/InnoDB, I assume that the database size is really only > limited by the file system size. If we were to setup a SCSI RAID 5 > array for the MySQL server, are there any considerations that would > seriously affect performance once we start getting 40Gb to 80Gb+ of > email data in one server? We're currently running at around 130Gb of mail data, on a dual Xeon 2.4G dedicated database server with load running between 30 and 80% average (bursts above but only for brief periods). Scales very well. I would recommend putting your smtp/pop servers on different machines if you're looking at a large install. We're running 6 smtp servers (also doing spam/virus scanning) and 3 pop/imap servers. The pop/imap servers don't have high load at all - mainly there for redundancy and scalability. > 7. With all the separate IMAP and POP daemons that run on the dbmail > server, each one presumably has its own database handle. > Once you start > getting a lot of users using a cluster of IMAP/POP servers, you get a > high number of MySQL collections. What are the practical limits that > have been seen in terms of the maximum number of connections? Any > case-histories that can be used for comparison and > specification design? I'm starting to have a few issues with that - but the daemons do persistent connections so not to intense. The dbmail-smtp forks so connects and disconnects, which can be a bit hard on the database and harder to predict. Every now and then we get thread memory problems reported and a failed connect on the database. Trying to work through this now -- I'm sure it's a config problem at our end. If any one can help out here (happy to pay reasonable rates) [nudge nudge Eelco or Roel]. We're currently running at about 200 connections from daemons/smtp processes. The lmtp daemon in 2.0 should mean persistent connects and more predictable perfomance. Haven't tried this yet. > 8. Has the "dbmail-smtp" branch been code reviewed by 3rd > parties? I am concerned about the possibility of SQL Injection. Peer review. There was a bug in early 1.x train, but was fixed I believe. > * A separate database for user authentication. This way, you > could have > multiple separate databases for email storage and the user > authentication could tell you which database to use for which user. > Moving users from one machine to another would then be > seamless as the > front-end machine would be the same, only the database entries would > change. This becomes a concern once your big database server > runs out > of room. They had this in an early 1.x release -- but unfortunately removed it. There is discussion for later in 2.x train to provide more configurable authentication support (e.g. ldap there now, other plugins can be written). I looked at the code and it wouldn't take too much work to write this again. The focus I think is on core-needed features rather than the big-end scalability needs at the moment. I'm not certain but I get the impression there aren't many people who are running servers with over 20G of data. But for my part - I love dbmail. /Mark
