I'm planning to migrate my mailservers from uw-imap to another one.
Since
- UW became to slow with large mailboxes and
- Cyrus is just to heavy
I thought of courier. But I recently saw Binc on imap.org and I'm willing to give it a try to be the better courier.
The compilation and build of an rpm of binc-1.2.6 was no problem. But within the migration concept, some question arose, that I like to ask for here. I already browsed the mailingliste-archive but still some things are not clear, so I'm posting my ideas and questions here.
This is the state right now:
Mail get's delivered to a central mailserver running postfix and a pop3-daemon, which is not part of the migration and will be untouched, so:
- I poll the mails with fetchmail (6.2.3) to the imap-server
- the mail is given from fetchmail to sendmail (8.12.10) for local delivery (that's what fetchmail always does afaik)
- sendmail gives the mail to procmail (3.15.1) which does filtering based on the rules of the users in ~/.procmailrc
- if there's no procmail in .forward or if there's no matching rule in procmailrc, mail goes to /var/mail/<username> in mbox format and waits there to be picked up by an imap-client
- this /var/mail ist mounted (ro) via nfs by other machines to provide direct (read-only) access to the inbox with new messages. This mainly is for mailcheckers like biff to provide mail-notification for new mails, but not for working with the mails. Work on the mailboxes is only done via imap, so /var/mail is read-only via nfs.
- users have a directory ~/imap which is accessed using uw-imap and which is mbox-type. It stores the tree structure of user-specific imapfolders. fetchmail does filtering and sorts messages to /imap/<mailbox> using mbox-format
- users use Mozilla/Thundebird/pine (all using imap) to access the server via imap. no pop access allowed and no direct access to mbox-files.
- from the internal network imap and imaps is allowed. from external, uw only accepts imaps
- unread messages in INBOX reside in /var/mail/<username> until they are read by a client. Then they go to ~/mbox which is the local INBOX with unread mail or they stay in /var/mail if the user has no ~/mbox (but this theoretical, because all users have that (forced).
Or they go to ~/imap mboxes when users sorts them into his tree-structure or procmail directly drops them there.
To replace uw with binc, the following steps need to be done and questions need to be asked:
- check if binc suports SSL - okay, it does!
- check if mbox can be converted to maildir - okay, can be done by some perl-scripts
- check if procmail can drop mails to maildir - okay, it can do it adding a trailing "/" to the destination folder
now still some questions are left:
- can binc be run by inetd instead of xinetd ?
- can binc use /var/mail/<username> (mbox) as source for *new* mails which are dropped there by the queue fetchmail->sendmail->postfix (in case no postfix rule applies)? The place and format for unread mail in INBOX doesn't matter for me, unless Thunderbird/Mozilla/pine can work with that. Best place would be somewhere in the maildir-tree.
This is mainly to stay compatbile with the nfs-mount(ro) of /var/mail which allows the use of simple tools like mail or biff to check for new mail.
Further, I don't want to replace fetchmail or sendmail for devlivery, since I'm experienced with both and both are "rock-hard" (to use binc compatbile expressions ;-)) and the process of fetching new mail from the central pop-server can not be avoided.
(I haven't understood the explenations if MailDir++ and ImapDir-Format on the website, so this question is still open)
Is this all possbile? Please comment that!
- I've read in the archvies, that there was/is a bug with the message-date. When converting from mbox to maildir the message-date was displayed as the file-date of the message-file instead of the date in the header. Is this definitly fixed in 1.2.6 since it is a k.o.-argument against binc!?
- Since I'm no authentcation specialist: can binc used with simple authentication against unix-system-password using /etc/shadow and pam just like uw does?
- How fast is Binc compared to courier/uw/cyrus ? Since I use large mailboxs, uw became much to slow and I need a much faster imap-server
- And at last: are there known problem with fetchmail/sendmail/procmail/nfs-mounts of /var/mail etc. which could make problems within my setup?
Sorry for the long e-mail. I'll promise if I get help here, I'll share my experience with this setup within this community!
Regards Volker
pgp00000.pgp
Description: PGP signature
