[Dovecot] migrating from uw imapd
Hi,
I'm trying to migrate from uw imapd to dovecot.
I'm having two problems at the moment.
uw imapd grabs new mail from /var/mail/user and then shoves it into ~/mbox, is there any way to make dovecot handle this kind of setup or am I better off merging ~/mbox back into /var/mail/user? If merging is better are what tools are best for this?
While I did have have everything in ~/Mail coming up dovetail stopped working and logs the following error:
syslog:Jul 19 23:01:07 epsilon3 imap-login: Login: haakon [192.168.0.107] syslog:Jul 19 23:01:07 epsilon3 imap(haakon): Failed to create storage with data: ~/Mail/:INBOX=/var/mail/haakon syslog:Jul 19 23:01:07 epsilon3 dovecot: child 10417 (imap) returned error 89
any idea what is causing this?
Regards, Craig.
On Saturday, Jul 19, 2003, at 16:17 Europe/Helsinki, Craig wrote:
- uw imapd grabs new mail from /var/mail/user and then shoves it into ~/mbox, is there any way to make dovecot handle this kind of setup or am I better off merging ~/mbox back into /var/mail/user? If merging is better are what tools are best for this?
There's no way currently. And I'm not sure what's the point of that anyway, so I don't really have plans to do that. Wasn't this mbox moving optional in UW-IMAP too?
For merging you could just use cat :) cat /var/mail/user >> /home/user/mbox, mv /home/user/mbox /var/mail/user
And to avoid losing mails you should stop SMTP and IMAP servers..
- While I did have have everything in ~/Mail coming up dovetail stopped working and logs the following error:
syslog:Jul 19 23:01:07 epsilon3 imap-login: Login: haakon [192.168.0.107] syslog:Jul 19 23:01:07 epsilon3 imap(haakon): Failed to create storage with data: ~/Mail/:INBOX=/var/mail/haakon
Try default_mail_env = mbox:~/Mail:INBOX=/var/mail/%u
Although it should have worked without the mbox: prefix too. Maybe some permission problem.
On Sat, Jul 19, 2003 at 05:35:20PM +0300, Timo Sirainen wrote:
On Saturday, Jul 19, 2003, at 16:17 Europe/Helsinki, Craig wrote:
- uw imapd grabs new mail from /var/mail/user and then shoves it into ~/mbox, is there any way to make dovecot handle this kind of setup or am I better off merging ~/mbox back into /var/mail/user? If merging is better are what tools are best for this?
There's no way currently. And I'm not sure what's the point of that anyway, so I don't really have plans to do that. Wasn't this mbox moving optional in UW-IMAP too?
Yes but last I knew it was compiled on by default. (EXTRADRIVERS=mbox). The behaviour only happened if mbox existed in the home directory-- if you never created that file you wouldn't see it happen. I always turned it off.
mm
On Sat, 2003-07-19 at 16:35, Timo Sirainen wrote:
On Saturday, Jul 19, 2003, at 16:17 Europe/Helsinki, Craig wrote:
- uw imapd grabs new mail from /var/mail/user and then shoves it into ~/mbox, is there any way to make dovecot handle this kind of setup or am I better off merging ~/mbox back into /var/mail/user? If merging is better are what tools are best for this?
There's no way currently. And I'm not sure what's the point of that anyway, so I don't really have plans to do that. Wasn't this mbox moving optional in UW-IMAP too?
For merging you could just use cat :) cat /var/mail/user >> /home/user/mbox, mv /home/user/mbox /var/mail/user
And to avoid losing mails you should stop SMTP and IMAP servers..
I had a look and no other users are setup that way on my server, I suspect it was uw imapd just carrying on from what mutt was doing.
The merge went successfully so that is that problem fixed.
- While I did have have everything in ~/Mail coming up dovetail stopped working and logs the following error:
syslog:Jul 19 23:01:07 epsilon3 imap-login: Login: haakon [192.168.0.107] syslog:Jul 19 23:01:07 epsilon3 imap(haakon): Failed to create storage with data: ~/Mail/:INBOX=/var/mail/haakon
Try default_mail_env = mbox:~/Mail:INBOX=/var/mail/%u
Although it should have worked without the mbox: prefix too. Maybe some permission problem.
Looks like the problem was with my .subscription file. After I fixed that it all came good.
Thanks for your quick response, your help is much appreciated.
Regards, Craig.
On Sat, 19 Jul 2003, Craig wrote:
- uw imapd grabs new mail from /var/mail/user and then shoves it into ~/mbox, is there any way to make dovecot handle this kind of setup or am I better off merging ~/mbox back into /var/mail/user? If merging is better are what tools are best for this?
It does that? I've never seen that kind of behavior. Perhaps your package is compiled with some weird options (if you didn't compile it yourself).
On Sat, 2003-07-19 at 11:35, Wouter Van Hemel wrote:
On Sat, 19 Jul 2003, Craig wrote:
- uw imapd grabs new mail from /var/mail/user and then shoves it into ~/mbox, is there any way to make dovecot handle this kind of setup or am I better off merging ~/mbox back into /var/mail/user? If merging is better are what tools are best for this?
It does that? I've never seen that kind of behavior. Perhaps your package is compiled with some weird options (if you didn't compile it yourself).
pine, in the default and mailx will do that annoying 'feature'
-sv
- On 2003.07.19, in Pine.LNX.4.56.0307191732110.172@cocaine.cryolabs.net,
- "Wouter Van Hemel" wouter@pair.com wrote:
It does that? I've never seen that kind of behavior. Perhaps your package is compiled with some weird options (if you didn't compile it yourself).
C-client (i.e., pine and uw-imap) will append /var/mail/$user to ~$user/mbox if ~/$user/mbox exists. AFAIK it's non-optional in the stock c-client build. If you touch ~/mbox, it should begin happening for you too.
(Options? Configuration? Ha!)
Pine and IMAP will regard ~/mbox as your INBOX, though, so it's not necessarily obvious that it's happening unless you look at the folders from outside pine or imap.
The purpose of this was twofold, as far as I can see: compatibility with Columbia MM's behavior with regard to mail.txt files, and to allow users or admins to balance space on the spool disk vs. space on the user disk. It's not a bad behavior, all things considered, though more configurability for this and other c-client behaviors would almost always be a fine thing.
-- -D. dgc@uchicago.edu NSIT University of Chicago When using any driving directions or map, it's a good idea to do a reality check and make sure the road still exists, watch out for construction, and follow all traffic safety precautions.
participants (7)
-
Craig
-
Craig Askings
-
David Champion
-
Mark E. Mallett
-
seth vidal
-
Timo Sirainen
-
Wouter Van Hemel