[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Building an IMAP server



On Sat, 01 Feb 2003, Hans Wilmer wrote:
> + about 60--100 users
Piece of cake on anything better than a Pentium MMX200.

> + Mail must be saved on the server, not on the clients.
> + Users should be able to create folders and subfolders to store their
>   mail.
IMAP will do this.

> + Exim should be used as MTA; amavis and spamassassin should be used.
>   Mail filtering by .forward files and eventually maildrop should be
>   possible; probably assisted/done by the admin (vacancy,
>   redirections, maybe automatic sorting into folders).

Cyrus would not like the .forward much, but it has its own built-in
RFC-defined mail filtering language.  amavisd-new can be used to call
spamassassin and AV software.

Courier is more on the track of what you're looking for, I think.

> + Users may be real users on the server. --- Are there good reasons
>   against this?

Security. You REALLY don't want your users to be real users on the server.

> + Mail should be stored in maildir format (in users' home
>   directories). The server will use ext3fs.

I suggest using xfs instead of ext3. Also, any maildir-like or MH-like spool
format is good for backups.

> + Each user should have about 1 GB to store his mails. This will
>   probably be enforced by setting filesystem quotas. Are there
>   better solutions to set maildir quotas? Users should be informed

Yes. Some servers such as Cyrus can do that at the mail spool level.

>   automatically in case they reach their quota limitation; the admin
>   should get a note, too.

I don't know about anything that gives the admin a note... never heard of
any reasonably busy admin wanting such a thing, either :)  But it is rather
easy to write scripts to do that (even for Cyrus).

> + Some/most users will store quite a lot of mail (in the sense of the
>   amount of data, not the number of mails). This should not
>   impact performance too much. (leads to using maildir, again)

Leads to using maildir-like or a real database backend, you mean.

> + It would be nice to have POP3 working, too.

Both cyrus and courier can do that.

> + To make things easy, I'd like to stay with software from standard
>   Debian packages, but that's not a must.

Again both cyrus and courier, although cyrus 2.1 is not on stable (but I do
regular backports of it).

> Cyrus seems to be good for performance, but it is using its own format
> to store the mail. That would make it impossible to recover particular
> mailboxes from backups, and if something goes wrong, you're more or

Hah, untrue. Just restore the proper spool directory and run cyrreconstruct
(and maybe cyrquota -f) on _that_ mailbox.  You think people would use Cyrus
for 100k+ users spools if it were that unreliable on crash conditions?

Every message is a single file (standard text, even. Just pipe it to
/usr/sbin/sendmail if you want it forwarded somewhere...), just like in
maildir. However, the spool has indexes that must be kept in sync.

> less left stranded because of the propriatry format that is used.

The format is fully documented and open, it's just that it is INTERNAL to
the mailsystem, and you are REALLY not supposed to muck with it.  This
enforces the black-box design of Cyrus, which is a good thing.

> Courier would do maildir, but it is an MTA in itselfe. It might be

You don't have to use the MTA portion of courier. In fact, I would suggest
you don't, and stick to exim or postfix.

> As of yet, the capabilities of uw-imapd are unknown to me. Does it
> support maildir?

Stay away from anything from UW if you want any sort of security.

> How do I improve secure operation and reliability? For example, while
> backing up the server, mail might be delivered or sent
> nonetheless. And even with daily backups, when having to recover from
> a backup, the intermediate traffic would be lost.

Cyrus/courier and rsync-based backups can do this. There are many other
possible methods, as well.

> Since the costs are a critical issue, the server will have IDE disks
> and probably no hardware RAID. Does IDE RAID work at all? Does it make

Ick. Bad performance, but it will be enough if you stick to software RAID1
in a good machine (PIII 800+) with at least 256MB of RAM, use no LVM, and
use XFS instead of ext3.

You should use very good IDE controllers and drives, and just one device per
80-wire UDMA cable (no slaves, cdroms or other crap!).  Two 7200RPM drives
should be enough.

> (On the long run, there should be a second server to accept mail from
> the outside world as a fallback in case the 'real' server is down. It
> should keep the incoming mail in its queue to deliver it to the real
> server when it comes back online.)

You mean a secondary MX?  Sometime ago people would not even dream of not
having one...  Anyway, this is done by the MTA.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh



Reply to: