[Dovecot] converting from mbox to maildir ?
Hello We are planning to convert our mailhub ( freebsd 7.4 ) from mbox format to maildir format. I've read the documentation and performed some tests on another machine it is a bit long ... I would like some feedback from guys who did this operation and need some advice on what to convert first ? - first convert INBOX then convert IMAP folders ? - first convert IMAP folders then convert INBOX ? the machine use real users thru openldap ( pam_ldap + nss_ldap ) another problem is disk space. The users's email data takes about 2 Terabytes of data and I cannot duplicate as I only have 3 Tb on the raid array of the server. My idea is to use one of our NFS netapp filer during the convertion to throw the result of the convertion on an NFS mounted directory. Anyone did this before ? If yes I would be greatly interrested by their experience Thank you
Re: [Dovecot] LMTP : Can't handle mixed proxy/non-proxy destinations
On 1/28/12, Timo Sirainen wrote: > On 27.1.2012, at 12.59, Alexis Lelion wrote: > >> Jan 25 09:05:12 mail01 postfix/lmtp[23934]: A92709300DB: to=< >> user_on_mai...@domain.com>, relay=mail01.domain.com[private/dovecot-lmtp], >> delay=0.07, delays=0.01/0/0/0.06, dsn=4.3.0, status=deferred (host >> mail01.domain.com[private/dovecot-lmtp] said: 451 4.3.0 < >> user_on_mai...@domain.com> Can't handle mixed proxy/non-proxy destinations >> (in reply to RCPT TO command)) >> >> I was wondering if there was another way of handling this, for example >> by triggering an immediate queue lookup from postfix or forwarding a >> copy of the mail to the other server. Note that the postfix >> "queue_run_delay" was increased to 15min on purpose, so I cannot change >> that. > > It would be possible to change the code to support mixed destinations, but > it's probably not a simple change and I have other things to do.. Yes I understand, this is a quite specific request, and not that impacting actually. But it would be cool if you could keep this request somewhere in your queue :-) > > Maybe you could work around it so that LMTP always proxies the mails, to > localhost as well, but to a different port which doesn't do proxying at all. Actually this was my first try, but I had proxying loops because unlike for IMAP, the LMTP server doesn't seem to support 'proxy_maybe' option yet, does it? > >
Re: [Dovecot] UID 0 problem while issuing an UID THREAD REFS command
Hi Timo: On Sábado, 28 de Enero de 2012 19:23:12 Timo Sirainen escribió: > On 23.1.2012, at 14.55, Jesús M. Navarro wrote: > >>> I'm having problems on a maildir due to dovecot returning an UID 0 to > >>> an > > > >>> UID THREAD REFS command: > > I'm sending to your personal address a whole maildir that reproduces the > > bug (it's very short) to avoid having it published in the mail archives. > > Thanks, I finally looked at this. The problem happens only when the > THREADing isn't done for all messages. I thought this would have been a > much more complex bug. Fixed: > http://hg.dovecot.org/dovecot-2.0/rev/57498cad6ab9 Thank you very much. Do you have a expected date for new packages covering this issue to be published at xi.rename-it.nl?
[Dovecot] Director to keep redirecting users to the same server even after all sessions closed?
Hi there, Just wondering how easy it would be to make the director continue to send a user to the same server (assuming it's still in the pool) for say 90 seconds after they have last been active (ie lmtp or pop/imap)? Basically we are working in quite a heavily cached environment so it takes perhaps 60-90 seconds for our imap servers to properly flush to our network storage meaning if the user got put on a different server in that time we would see some issues. Presently we have fixed proxying, but I'd really like to use the director if possible to allow us to more easily add & remove servers. Mark
Re: [Dovecot] Director to keep redirecting users to the same server even after all sessions closed?
On 30.1.2012, at 15.32, Mark Zealey wrote: > Just wondering how easy it would be to make the director continue to send a > user to the same server (assuming it's still in the pool) for say 90 seconds > after they have last been active (ie lmtp or pop/imap)? Basically we are > working in quite a heavily cached environment so it takes perhaps 60-90 > seconds for our imap servers to properly flush to our network storage meaning > if the user got put on a different server in that time we would see some > issues. Presently we have fixed proxying, but I'd really like to use the > director if possible to allow us to more easily add & remove servers. Already done, and enabled by default: # How long to redirect users to a specific server after it no longer has # any connections. #director_user_expire = 15 min I added this mainly to make sure that all attribute caches have timed out.
Re: [Dovecot] Director to keep redirecting users to the same server even after all sessions closed?
Brilliant; I had read the director page in the wiki but didn't see it there & a search of the wiki text doesn't show up the option - perhaps you could add it or is there another place to see a list of director options? Mark From: Timo Sirainen [t...@iki.fi] Sent: 30 January 2012 13:58 To: Mark Zealey Cc: dovecot@dovecot.org Subject: Re: [Dovecot] Director to keep redirecting users to the same server even after all sessions closed? On 30.1.2012, at 15.32, Mark Zealey wrote: > Just wondering how easy it would be to make the director continue to send a > user to the same server (assuming it's still in the pool) for say 90 seconds > after they have last been active (ie lmtp or pop/imap)? Basically we are > working in quite a heavily cached environment so it takes perhaps 60-90 > seconds for our imap servers to properly flush to our network storage meaning > if the user got put on a different server in that time we would see some > issues. Presently we have fixed proxying, but I'd really like to use the > director if possible to allow us to more easily add & remove servers. Already done, and enabled by default: # How long to redirect users to a specific server after it no longer has # any connections. #director_user_expire = 15 min I added this mainly to make sure that all attribute caches have timed out.
[Dovecot] INBOX and IMAP forlders on differents machines ?
Hello In MBOX format would it be possible with dovecot 2 to have two machines one containing the INBOX and the other containing IMAP folders. Of course this need a frontend but would it be possible ? thanks
Re: [Dovecot] INBOX and IMAP forlders on differents machines ?
On 30.1.2012, at 19.29, Frank Bonnet wrote: > In MBOX format would it be possible with dovecot 2 to have two machines > one containing the INBOX and the other containing IMAP folders. > > Of course this need a frontend but would it be possible ? With v2.1 I guess you could in theory do this with imapc backend.
Re: [Dovecot] Mountpoints
On Mon, 30 Jan 2012, dovecot-requ...@dovecot.org wrote: So, I was thinking about adding doveadm commands to explicitly tell Dovecot about the mountpoints that it needs to care about. When no mountpoints are defined Dovecot would behave as it does now. Maybe I don't understand the subtlety of your question, but are you trying to disambiguate between a mounted filesytem and a failed mount that presents the underlying filesystem (which looks like an uninitilized index directory)? Couldn't you write some cookie file "/mount/.../dovecot-data-root/.dovemount", whose existence will tell you whether the FS is mounted without trying to find the mount root. Oh, but then again if you have per-user mounts, that's going to get messy. Joseph Tam
[Dovecot] Help required
Hi I use dovecot on CentOS. It was installed and configured by some other person who doesn't work here anymore. I am trying to renew ssl. But the command works fine and restarts the dovecot. But the license shows the same old expiry. Can you please help me with the same. When I type in dovecot --version, I get command not found. Please guide me! Regards, -- Deepa Malleeswaran
Re: [Dovecot] Mountpoints
On 31.1.2012, at 2.03, Joseph Tam wrote: > On Mon, 30 Jan 2012, dovecot-requ...@dovecot.org wrote: > >> So, I was thinking about adding doveadm commands to explicitly tell >> Dovecot about the mountpoints that it needs to care about. When no >> mountpoints are defined Dovecot would behave as it does now. > > Maybe I don't understand the subtlety of your question, but are you > trying to disambiguate between a mounted filesytem and a failed mount > that presents the underlying filesystem (which looks like an uninitilized > index directory)? Yes. A mounted filesystem where a directory doesn't exist vs. accidentally unmounted filesystem. > Couldn't you write some cookie file "/mount/.../dovecot-data-root/.dovemount", > whose existence will tell you whether the FS is mounted without trying to > find the mount root. This would require that existing installations create such a file or start failing after upgrade. Or that it's made optional and most people wouldn't use this functionality at all.. And I'm sure many people with a single filesystem wouldn't be all that happy creating /.dovemount or /home/.dovemount or such files.
Re: [Dovecot] moving mail out of alt storage
On Sat, Jan 28, 2012 at 12:44 PM, Timo Sirainen wrote: > On 12.1.2012, at 20.32, Mark Moseley wrote: > On Wed, 2011-09-14 at 23:17 -0400, Micah Anderson wrote: > I moved some mail into the alt storage: > > doveadm altmove -u jo...@example.com seen savedbefore 1w > > and now I want to move it back to the regular INBOX, but I can't see how > I can do that with either 'altmove' or 'mailbox move'. Is this sdbox or mdbox? With sdbox you could simply "mv" the files. Or apply patch: http://hg.dovecot.org/dovecot-2.0/rev/1910c76a6cc9 >>> >>> This is mdbox, which is why I am not sure how to operate because I am >>> used to individual files as is with maildir. >>> >>> micah >>> >> >> I'm curious about this too. Is moving the m.# file out of the ALT >> path's storage/ directory into the non-ALT storage/ directory >> sufficient? Or will that cause odd issues? > > You can manually move m.* files to alt storage and back. Just make sure that > the same file isn't being simultaneously modified by Dovecot or you'll > corrupt it. > Cool, good to know. Thanks!
