[Dovecot] Courier migration and vpopmail with dovecot-lda
I've been using Dovecot in some fresh installs lately and have found it fairly easy to configure. However I'm starting on a migration that involves moving from some very old software (ancient vpopmail, qmail and Courier).
On the Courier front, I've reviewed the migration page in the wiki, and it looks like the main concerns are just matching the namespace and then using the migration script to create new subscription and uidlist files. Given that my Courier IMAP setup is so old (4.0.6), is there anything to be aware of that's not covered in the wiki due to the age of Courier here?
Are there any other general issues to be aware of as far as interactions with MUAs are concerned? For example, if Courier has been presenting the user's MUA with a given set of IMAP capabilities and then the MUA sees a bunch of extra capabilities on a subsequent login, will that trigger any strange behavior?
And lastly on this subject, I will obviously be doing some testing before cutting over to the other server. Is it valid in something like Thunderbird to have it pointed to "imap.domain.com" and then change the imap server to point to something like "testimap.domain.com" for testing whether subscriptions and the uidlists are working as expected or should I fully replicate the move as an end user would see it by making the change in my local hosts file?
Now, assuming that portion of the move goes alright, I'm incredibly confused about getting Dovecot and Vpopmail working together. I assume that initially I can stick with the Maildir++ mailbox format and let vpopmail's vdelivermail continue working as my LDA - vdelivermail understands how to find the user's Maildir, it can check quotas, and it can update the maildirsize file (which I'm assuming dovecot can also read and then report quota/usage to an IMAP client). However it does look like the Dovecot-only mailbox format(s) will offer much better performance than Maildir as the two dbox formats are the only supported mailbox formats with separate index files, correct? Is there any guidance on how to use dovecot's LDA with a virtual mail system such as vpopmail? From what I've read so far, I probably don't want to use the vpopmail extension supplied with dovecot, but query the mysql vpopmail db directly. I'm finding a ton of info while searching for this, but most deals with older versions of dovecot, and there are also many "this works but I don't know why" tutorials on combining dovecot and vpopmail and dovecot's own LDA. I'm not even able to guess how one handles the per-user .qmail files in vpopmail if not using vdelivermail (this is where we enable/disable spam filtering by piping the message through spamc).
Any input on the overall migration process is appreciated. It's a bit overwhelming as I have to deal with a big jump in the vpopmail version, rebuilding qmail with a ridiculous number of patches, and then on top of that a migration to new imap/pop server software. eek.
Thanks,
Charles
Charles Sprickman NetEng/SysAdmin Bway.net - New York's Best Internet www.bway.net spork@bway.net - 212.982.9800
On 18 September, 2013 - Charles Sprickman wrote:
I've been using Dovecot in some fresh installs lately and have found it fairly easy to configure. However I'm starting on a migration that involves moving from some very old software (ancient vpopmail, qmail and Courier).
On the Courier front, I've reviewed the migration page in the wiki, and it looks like the main concerns are just matching the namespace and then using the migration script to create new subscription and uidlist files. Given that my Courier IMAP setup is so old (4.0.6), is there anything to be aware of that's not covered in the wiki due to the age of Courier here?
Are there any other general issues to be aware of as far as interactions with MUAs are concerned? For example, if Courier has been presenting the user's MUA with a given set of IMAP capabilities and then the MUA sees a bunch of extra capabilities on a subsequent login, will that trigger any strange behavior?
And lastly on this subject, I will obviously be doing some testing before cutting over to the other server. Is it valid in something like Thunderbird to have it pointed to "imap.domain.com" and then change the imap server to point to something like "testimap.domain.com" for testing whether subscriptions and the uidlists are working as expected or should I fully replicate the move as an end user would see it by making the change in my local hosts file?
Now, assuming that portion of the move goes alright, I'm incredibly confused about getting Dovecot and Vpopmail working together. I assume that initially I can stick with the Maildir++ mailbox format and let vpopmail's vdelivermail continue working as my LDA - vdelivermail understands how to find the user's Maildir, it can check quotas, and it can update the maildirsize file (which I'm assuming dovecot can also read and then report quota/usage to an IMAP client). However it does look like the Dovecot-only mailbox format(s) will offer much better performance than Maildir as the two dbox formats are the only supported mailbox formats with separate index files, correct? Is there any guidance on how to use dovecot's LDA with a virtual mail system such as vpopmail? From what I've read so far, I probably don't want to use the vpopmail extension supplied with dovecot, but query the mysql vpopmail db directly. I'm finding a ton of info while searching for this, but most deals with older versions of dovecot, and there are also many "this works but I don't know why" tutorials on combining dovecot and vpopmail and dovecot's own LDA. I'm not even able to guess how one handles the per-user .qmail files in vpopmail if not using vdelivermail (this is where we enable/disable spam filtering by piping the message through spamc).
Any input on the overall migration process is appreciated. It's a bit overwhelming as I have to deal with a big jump in the vpopmail version, rebuilding qmail with a ridiculous number of patches, and then on top of that a migration to new imap/pop server software. eek.
Hi Charles!
I can share some of my war-stories about qmail/vpopmail.
Along time ago i ran quite a few qmail/vpopmail/courier/ezmlm/qmailadmin clusters and back then i thought it was the only rely good way of running it. Then the years passed and when i needed to add patches to qmail consisting of more code than qmail started out with it got quite frustrated. Due to speed and scalability we didn't run with a db-backend for vpopmail, we used vpasswd/cdb(?) hash-files and that ran quite well.
So when it was time to migrate i came up with the following solution:
I ran postfix as smtp-server, querying vpopmail via a tcp:-maps to a daemon written in perl, that ran diffrent vpopmail-commands. That old daemon is now available at: https://github.com/glance-/postfixvpopmail/
For some reason that i can't really remember vdelivermail was just incapable of being used in this case to deliver mail, i think it had something to do with .qmail-files and might have bin something with ezmlm, so i used qmail as a lda, and had postfix pipe mail to qmail-inject. This way we kept qmailadmin/ezmlm running as they did before and just replaced the world-facing components.
On top of that i ran Dovecot with the vpopmail plugin. This was a realy old dovecot, probaby like 1.0.x or something, but everything worked smoothly. I just followed the notes on the wiki about uidl-format and no users noticed.
I actually just checked, and that server is still running strong, and handling mail for a couple of k users, so it couldn't bin that bad design =) Btw. Its still running Debian Sarge =)
I hope you might have gotten some ideas about what to do with a old qmail/vpopmail install.
//Anton
-- Anton Lundin +46702-161604
On Sep 19, 2013, at 4:59 AM, Anton Lundin wrote:
On 18 September, 2013 - Charles Sprickman wrote:
I've been using Dovecot in some fresh installs lately and have found it fairly easy to configure. However I'm starting on a migration that involves moving from some very old software (ancient vpopmail, qmail and Courier).
On the Courier front, I've reviewed the migration page in the wiki, and it looks like the main concerns are just matching the namespace and then using the migration script to create new subscription and uidlist files. Given that my Courier IMAP setup is so old (4.0.6), is there anything to be aware of that's not covered in the wiki due to the age of Courier here?
Are there any other general issues to be aware of as far as interactions with MUAs are concerned? For example, if Courier has been presenting the user's MUA with a given set of IMAP capabilities and then the MUA sees a bunch of extra capabilities on a subsequent login, will that trigger any strange behavior?
And lastly on this subject, I will obviously be doing some testing before cutting over to the other server. Is it valid in something like Thunderbird to have it pointed to "imap.domain.com" and then change the imap server to point to something like "testimap.domain.com" for testing whether subscriptions and the uidlists are working as expected or should I fully replicate the move as an end user would see it by making the change in my local hosts file?
Now, assuming that portion of the move goes alright, I'm incredibly confused about getting Dovecot and Vpopmail working together. I assume that initially I can stick with the Maildir++ mailbox format and let vpopmail's vdelivermail continue working as my LDA - vdelivermail understands how to find the user's Maildir, it can check quotas, and it can update the maildirsize file (which I'm assuming dovecot can also read and then report quota/usage to an IMAP client). However it does look like the Dovecot-only mailbox format(s) will offer much better performance than Maildir as the two dbox formats are the only supported mailbox formats with separate index files, correct? Is there any guidance on how to use dovecot's LDA with a virtual mail system such as vpopmail? From what I've read so far, I probably don't want to use the vpopmail extension supplied with dovecot, but query the mysql vpopmail db directly. I'm finding a ton of info while searching for this, but most deals with older versions of dovecot, and there are also many "this works but I don't know why" tutorials on combining dovecot and vpopmail and dovecot's own LDA. I'm not even able to guess how one handles the per-user .qmail files in vpopmail if not using vdelivermail (this is where we enable/disable spam filtering by piping the message through spamc).
Any input on the overall migration process is appreciated. It's a bit overwhelming as I have to deal with a big jump in the vpopmail version, rebuilding qmail with a ridiculous number of patches, and then on top of that a migration to new imap/pop server software. eek.
Hi Charles!
I can share some of my war-stories about qmail/vpopmail.
Along time ago i ran quite a few qmail/vpopmail/courier/ezmlm/qmailadmin clusters and back then i thought it was the only rely good way of running it. Then the years passed and when i needed to add patches to qmail consisting of more code than qmail started out with it got quite frustrated. Due to speed and scalability we didn't run with a db-backend for vpopmail, we used vpasswd/cdb(?) hash-files and that ran quite well.
So when it was time to migrate i came up with the following solution:
I ran postfix as smtp-server, querying vpopmail via a tcp:-maps to a daemon written in perl, that ran diffrent vpopmail-commands. That old daemon is now available at: https://github.com/glance-/postfixvpopmail/
Thanks for that, I'm doing this in steps, and initially qmail will remain exposed to the interwebs. Down the line it's going to be hidden behind Postfix. That little daemon might be helpful. I wasn't sure how hard it would be to query the vpopmail db directly for users and aliases (I don't think we have any ezmlm, which is I think the one thing not tracked in the db).
For some reason that i can't really remember vdelivermail was just incapable of being used in this case to deliver mail, i think it had something to do with .qmail-files and might have bin something with ezmlm, so i used qmail as a lda, and had postfix pipe mail to qmail-inject. This way we kept qmailadmin/ezmlm running as they did before and just replaced the world-facing components.
On top of that i ran Dovecot with the vpopmail plugin. This was a realy old dovecot, probaby like 1.0.x or something, but everything worked smoothly. I just followed the notes on the wiki about uidl-format and no users noticed.
Since this is the Dovecot list, I'll try to focus on this part.
First, can anyone confirm the current state of the vpopmail plugin? Usable or no? Is it better to just query the vpopmail db for login info? What does the vpopmail plugin, if it's still maintained as part of Dovecot, bring that the db method does not?
Second, I have other Dovecot installs, all using Maildir and maildrop is doing the final delivery to handle looking at amavis results and appropriately shuffle spam off to the spam box. It looks like I could do the same here, but I'm not clear on what advantages the Dovecot LDA brings. From what I gather, using the Dovecot LDA will make sure my indexes are regularly updated if people aren't checking their email regularly, and it also allows me to move from Maildir to dbox. The downside is that since our current system relies on manipulating maildrop rc files, we could not move to the Dovecot LDA until we switch everything around to support Sieve.
And regarding dbox, I'm not quite sure what that's going to do to my backups. Maildir backups are slow (traversing a huge number of files), but in the end, I'm not re-copying old messages. I fear dbox might be similar to mbox - delete one message in a box and then I have to fetch the whole thing at backup time. Any input on that from the list?
I actually just checked, and that server is still running strong, and handling mail for a couple of k users, so it couldn't bin that bad design =) Btw. Its still running Debian Sarge =)
I hope you might have gotten some ideas about what to do with a old qmail/vpopmail install.
Yes, thanks very much!
Charles
//Anton
-- Anton Lundin +46702-161604
participants (2)
-
Anton Lundin
-
Charles Sprickman