[Dovecot] Binc IMAP "IMAPdir" style layout
Hi,
I'm in the process of migrating several years worth of mail to be accessible via an IMAP server. Some time ago, I evaluated both Binc IMAP and Dovecot and found Dovecot to be much faster on large folders, which is quite important to me. One thing I did not however manage to determine from the documentation on namespaces is whether or not it is possible to implement what Binc IMAP calls an "IMAPdir" style layout.
IMAPdir lets me layout mailboxes in the filesystem like so:
$HOME/
Maildir/ <---- users mail goes here
Mail/ <---- IMAP root
INBOX -> ../Maildir/ <---- (symlink)
folder/ <---- some other mailbox in Maildir format
folder.subfolder/ <---- '.' is the hierarchy separator
folder.subfolder-2/
other-folder/
So IMAP clients subscribe to 'INBOX' and 'folder' and 'folder/subfolder' respectively.
This gives me two features that I want:
The ability to easily access all my mail using a command line Maildir capable client such as nail, for when I'm connection over a super-slow SSH over GPRS connection. Also, I can actually see my folders (and their subfolders) without having to look for Maildir++ style names with 'ls -a' (e.g. Maildir/.subfolder/).
Mail folders are organized logically, unlike the standard Maildir++ layout where everything is a subfolder of 'INBOX', which strikes me as stupid.
Is such a thing possible with Dovecot? Any help would be much appreciated.
Thanks,
-mato
Hi,
IMAPdir lets me layout mailboxes in the filesystem like so:
$HOME/ Maildir/ <---- users mail goes here Mail/ <---- IMAP root INBOX -> ../Maildir/ <---- (symlink) folder/ <---- some other mailbox in Maildir format folder.subfolder/ <---- '.' is the hierarchy separator folder.subfolder-2/
other-folder/So IMAP clients subscribe to 'INBOX' and 'folder' and 'folder/subfolder' respectively.
The current layout I get with default is: $HOME/ Maildir/ INBOX/ INBOX.subfolder-of-inbox-if-you-have-any-I-dont/ folder/ folder.subfolder/ etc.
Dovecot can even handle (afaik) having inbox in a different place by simply configuring
default_mail_env = maildir:/home/%u/Maildir:INBOX=/home/%u/Mail/
I think. Not sure if it can handle INBOX being a maildir. Check the wiki/docs.
johannes
On 2.7.2005, at 17:32, Martin Lucina wrote:
This gives me two features that I want:
- The ability to easily access all my mail using a command line Maildir capable client such as nail, for when I'm connection over a super-slow SSH over GPRS connection. Also, I can actually see my folders (and their subfolders) without having to look for Maildir++ style names with 'ls -a' (e.g. Maildir/.subfolder/).
This can't be currently done. Shouldn't be too difficult to hack the code to do it though. I might add support for it sometimes after v1.0 release.
- Mail folders are organized logically, unlike the standard Maildir++ layout where everything is a subfolder of 'INBOX', which strikes me as stupid.
Dovecot doesn't use the "INBOX." -namespace even with Maildir++ unless you explicitly tell it to. So this isn't a problem.
tss@iki.fi said:
- The ability to easily access all my mail using a command line Maildir capable client such as nail, for when I'm connection over a super-slow SSH over GPRS connection. Also, I can actually see my folders (and their subfolders) without having to look for Maildir++ style names with 'ls -a' (e.g. Maildir/.subfolder/).
This can't be currently done. Shouldn't be too difficult to hack the code to do it though. I might add support for it sometimes after v1.0 release.
Can you give me a pointer to where this change would have to be made in the code? I'll give it a go...
-mato
On 4.7.2005, at 01:27, Martin Lucina wrote:
tss@iki.fi said:
- The ability to easily access all my mail using a command line Maildir capable client such as nail, for when I'm connection over a super-slow SSH over GPRS connection. Also, I can actually see my folders (and their subfolders) without having to look for Maildir++ style names with 'ls -a' (e.g. Maildir/.subfolder/).
This can't be currently done. Shouldn't be too difficult to hack the code to do it though. I might add support for it sometimes after v1.0 release.
Can you give me a pointer to where this change would have to be made in the code? I'll give it a go...
src/lib-storage/maildir/maildir-list.c and maildir-storage.c
Find all instances of MAILDIR_FS_SEP or MAILDIR_FS_SEP_S and if they are added/looked at the beginning of string, remove it.
That's assuming 1.0-stable/test version. With 0.99.x I wouldn't bother, but basically same idea except it uses '.' directly instead of those macros.
On 4.7.2005, at 01:32, Timo Sirainen wrote:
On 4.7.2005, at 01:27, Martin Lucina wrote:
tss@iki.fi said:
- The ability to easily access all my mail using a command line Maildir capable client such as nail, for when I'm connection over a super-slow SSH over GPRS connection. Also, I can actually see my folders (and their subfolders) without having to look for Maildir++ style names with 'ls -a' (e.g. Maildir/.subfolder/).
This can't be currently done. Shouldn't be too difficult to hack the code to do it though. I might add support for it sometimes after v1.0 release.
Can you give me a pointer to where this change would have to be made in the code? I'll give it a go...
src/lib-storage/maildir/maildir-list.c and maildir-storage.c
Find all instances of MAILDIR_FS_SEP or MAILDIR_FS_SEP_S and if they are added/looked at the beginning of string, remove it.
And now that I think of it, an alternative would be to just change the separator to something else than "." if you don't mind all of the mailboxes beginning with some special character. No need for "ls -a" then and the change is really simple :) Of course, then it's not really anything like Maildir++ or IMAPdir..
On Sat, Jul 02, 2005 at 04:32:51PM +0200, Martin Lucina wrote:
Hi,
I'm in the process of migrating several years worth of mail to be accessible via an IMAP server. Some time ago, I evaluated both Binc IMAP and Dovecot and found Dovecot to be much faster on large folders, which is quite important to me. One thing I did not however manage to determine from the documentation on namespaces is whether or not it is possible to implement what Binc IMAP calls an "IMAPdir" style layout.
<etc>
See, for example,
http://www.dovecot.org/list/dovecot/2003-July/001923.html
:-)
-mm-
On Wed, 2005-07-06 at 15:53 -0400, Mark E. Mallett wrote:
I'm in the process of migrating several years worth of mail to be accessible via an IMAP server. Some time ago, I evaluated both Binc IMAP and Dovecot and found Dovecot to be much faster on large folders, which is quite important to me. One thing I did not however manage to determine from the documentation on namespaces is whether or not it is possible to implement what Binc IMAP calls an "IMAPdir" style layout.
<etc>
See, for example,
http://www.dovecot.org/list/dovecot/2003-July/001923.html
Actually I thought back then that IMAPdir was using normal directories for mailbox hierarchy, but it's actually pretty much the same as Maildir++, just without the leading dots and with some other small changes. So even though IMAPdir support could come one day, I don't see it being very useful.
On Wed, Jul 06, 2005 at 11:03:30PM +0300, Timo Sirainen wrote:
Actually I thought back then that IMAPdir was using normal directories for mailbox hierarchy, but it's actually pretty much the same as Maildir++, just without the leading dots and with some other small changes. So even though IMAPdir support could come one day, I don't see it being very useful.
I think its most useful thing would be the ability to encapsulate any storage format inside a subfolder/subdirectory, e.g. being able to include an mbox inside of a maildir++ hierarchy. I don't remember if IMAPdir supports that, exactly, and I'm too occupied (er, lazy) to go look it up right now, but my impression was that that would be one of its strong points if it did.
mm
On Wed, 2005-07-06 at 16:13 -0400, Mark E. Mallett wrote:
On Wed, Jul 06, 2005 at 11:03:30PM +0300, Timo Sirainen wrote:
Actually I thought back then that IMAPdir was using normal directories for mailbox hierarchy, but it's actually pretty much the same as Maildir++, just without the leading dots and with some other small changes. So even though IMAPdir support could come one day, I don't see it being very useful.
I think its most useful thing would be the ability to encapsulate any storage format inside a subfolder/subdirectory, e.g. being able to include an mbox inside of a maildir++ hierarchy. I don't remember if IMAPdir supports that, exactly, and I'm too occupied (er, lazy) to go look it up right now, but my impression was that that would be one of its strong points if it did.
Nothing really prevents that kind of usage with Maildir++ layout either.. :) After v1.0 I'll separate the directory layouts and the actual mailbox handling code. Then we could have eg.:
Maildir++: Maildir/.maildir.subfolder/ Maildir/.mbox.subfolder.file
IMAPdir: Mail/maildir.subfolder/ Mail/mbox.subfolder.file
Real directory layout, whatever it should be called: Mail/maildir/subfolder/ Mail/mbox/subfolder/file
With symlinking and everything being possible..
On Wed, Jul 06, 2005 at 11:19:33PM +0300, Timo Sirainen wrote:
Maildir++: Maildir/.maildir.subfolder/ Maildir/.mbox.subfolder.file
That would be interesting. But I was thinking that mbox (and every other kind of storage) would have to be encapsulated inside a subdirectory so that it could contain any indexes and any other control files that might be wanted down the road. No?
mm
Hi, all.
I've been lurking around here for a while, with growing interest in dumping my crusty old UW-imapd setup in place of something better.
So far I like what I see of dovecot -- it's lean, fast, easy to configure, robust, and secure -- none of which really apply to UW-imapd.
However, I'm having a problem with dates, both with 0.99.14 and now with 1.0-stable.
First a few words about my setup. I'm running on AIX 5.1, with SSL
enabled. I had to tweak the dovecot-1.0-stable source tree to get rid
of the "//"-style comments, since the AIX xlc compiler doesn't like that
construct. And, as with the 0.99.14 build, there's tons of compiler
warnings about
I am using procmail to file INBOX mail in parallel into both my old UW-imapd server (which uses mbx-format mailboxes) and into maildir-style mailboxes accessible by the dovecot server.
In my mail user agent (Mulberry 3.1.6), I display and sort by date received. The glitch is that all the mail on my dovecot server shows timestamps in GMT, while the mail on my UW server properly shows timestamps in local time (CST6CDT, currently five hours behind GMT).
In order to isolate user agent issues, I identified a recent message sent to both my UW and dovecot servers with the thought of connecting via telnet to both servers, fetching the message, and comparing the difference. The results below show that when I do the
FETCH message INTERNALDATE
IMAP command, UW-imapd gives me the correctly-localized time, while dovecot gives me GMT.
Incidentally, I've tried starting dovecot both with and without chroot and even explicitly setting the TZ environment variable on startup, both with no effect.
Does anyone have any ideas, or is this a known issue? I have a lot more voluminous log data that can be provided on request. Thanks in advance.
First, the uw-imapd instance running on local port 143:
Script started on Wed Jul 6 16:49:13 2005 $ telnet localhost 143 Trying... Connected to loopback. Escape character is '^]'.
- OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS AUTH=LOGIN] loopback IMAP4rev1 2002.336 at Wed, 6 Jul 2005 16:49:19 -0500 (CDT) a001 login roma XXXXXXXX a001 OK [CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS BINARY SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User roma authenticated a002 capability
- CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS BINARY SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND LOGIN-REFERRALS AUTH=LOGIN a002 OK CAPABILITY completed a003 select inbox
- 3604 EXISTS
- 0 RECENT
- OK [UIDVALIDITY 979758742] UID validity status
- OK [UIDNEXT 26156] Predicted next UID
- FLAGS ($MDNSent Cyrusoft.Mulberry.01 Cyrusoft.Mulberry.05 \Answered \Flagged \Deleted \Draft \Seen)
- OK [PERMANENTFLAGS ($MDNSent Cyrusoft.Mulberry.01 Cyrusoft.Mulberry.05 \* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags a003 OK [READ-WRITE] SELECT completed a004 fetch 3602 internaldate
- 3602 FETCH (INTERNALDATE " 6-Jul-2005 15:55:30 -0500") a004 OK FETCH completed a006 fetch 3602 envelope
- 3602 FETCH (ENVELOPE ("Wed, 6 Jul 2005 16:55:11 -0400" {46} Re: [Dovecot] Binc IMAP "IMAPdir" style layout (("Mark E. Mallett" NIL "mem" "mv.mv.com")) ((NIL NIL "dovecot-bounces" "dovecot.org")) (("Mark E. Mallett" NIL "mem" "mv.mv.com")) (("Timo Sirainen" NIL "tss" "iki.fi")) ((NIL NIL "dovecot" "dovecot.org")) NIL "1120681173.2890.10.camel@hurina" "20050706205511.GA11708@osmium.mv.net")) a005 OK FETCH completed
a007 logout
- BYE zippy.cso.uiuc.edu IMAP4rev1 server terminating connection a007 OK LOGOUT completed Connection closed.
And now the equivalent operation in dovecot:
Script started on Wed Jul 6 16:44:39 2005 $ telnet localhost 9897 Trying... Connected to loopback. Escape character is '^]'. permitted.
- OK Dovecot ready. a001 login roma XXXXXXXX a001 OK Logged in. a002 capability
- CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS a002 OK Capability completed. a003 select inbox
- FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
- OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags
- 43 EXISTS
- 1 RECENT
- OK [UNSEEN 2] First unseen.
- OK [UIDVALIDITY 1118339114] UIDs valid
- OK [UIDNEXT 285] Predicted next UID a003 OK [READ-WRITE] Select completed. a004 fetch 41 internaldate
- 41 FETCH (INTERNALDATE "06-Jul-2005 20:55:30 +0000") a004 OK Fetch completed. a005 fetch 41 envelope
- 41 FETCH (ENVELOPE ("Wed, 6 Jul 2005 16:55:11 -0400" {46} Re: [Dovecot] Binc IMAP "IMAPdir" style layout (("Mark E. Mallett" NIL "mem" "mv.mv.com")) ((NIL NIL "dovecot-bounces" "dovecot.org")) (("Mark E. Mallett" NIL "mem" "mv.mv.com")) (("Timo Sirainen" NIL "tss" "iki.fi")) ((NIL NIL "dovecot" "dovecot.org")) NIL "1120681173.2890.10.camel@hurina" "20050706205511.GA11708@osmium.mv.net")) a005 OK Fetch completed. a007 logout
- BYE Logging out a007 OK Logout completed. Connection closed.
-- Jon Roma roma@uiuc.edu Senior Research Programmer Campus Information Technologies and Educational Services (CITES) University of Illinois at Urbana-Champaign
On Wed, 2005-07-06 at 17:43 -0500, Jon Roma wrote:
First a few words about my setup. I'm running on AIX 5.1, with SSL enabled. I had to tweak the dovecot-1.0-stable source tree to get rid of the "//"-style comments, since the AIX xlc compiler doesn't like that construct.
Yes, these kind of comments shouldn't be there. I've used them only for "temporary" FIXME-comments, so hopefully when they're all fixed there are no more // comments.. :)
And, as with the 0.99.14 build, there's tons of compiler warnings about
, but the applications build and seem to generally work fine.
What sys/types.h errors?
IMAP command, UW-imapd gives me the correctly-localized time, while dovecot gives me GMT.
Incidentally, I've tried starting dovecot both with and without chroot and even explicitly setting the TZ environment variable on startup, both with no effect.
Dovecot deletes the TZ environment (and everything else) before starting imap process. Doesn't AIX use something similar to /etc/localtime?
Try running imap binary manually, eg.:
MAIL=~/Maildir /usr/local/libexec/dovecot/imap
and give it the commands to fetch INTERNALDATE (and set TZ if needed?). If it works, maybe I'll start setting TZ for Dovecot's child processes.
Timo Sirainen tss@iki.fi wrote:
On Wed, 2005-07-06 at 17:43 -0500, Jon Roma wrote:
First a few words about my setup. I'm running on AIX 5.1, with SSL enabled. I had to tweak the dovecot-1.0-stable source tree to get rid of the "//"-style comments, since the AIX xlc compiler doesn't like that construct.
Yes, these kind of comments shouldn't be there. I've used them only for "temporary" FIXME-comments, so hopefully when they're all fixed there are no more // comments.. :)
And, as with the 0.99.14 build, there's tons of compiler warnings about
, but the applications build and seem to generally work fine. What sys/types.h errors?
Oh, it's this fun stuff that appears for just about every .c file compiled:
gmake[3]: Entering directory
`/usr/local/src/dovecot-1.0-stable-20050705/src/lib'
source='base64.c' object='base64.o' libtool=no
DEPDIR=.deps depmode=aix /bin/sh ../../depcomp
cc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -g -c base64.c
"/usr/include/sys/types.h", line 118.25: 1506-115 (E) Duplicate type
specifier "unsigned" ignored.
"/usr/include/sys/types.h", line 118.1: 1506-137 (W) Declaration must
declare at least one declarator, tag, or the members of an enumeration.
"/usr/include/sys/types.h", line 131.1: 1506-137 (W) Declaration must
declare at least one declarator, tag, or the members of an enumeration.
Alas, I didn't see anything obvious that causes this, but as mentioned, the executable seems to work fine -- it's just a very noisy compilation. Since I don't know whether attachments to this list are appropriate, please feel free to contact me directly and I'll send you the sys/types.h file and any other information that would help.
IMAP command, UW-imapd gives me the correctly-localized time, while dovecot gives me GMT.
Incidentally, I've tried starting dovecot both with and without chroot and even explicitly setting the TZ environment variable on startup, both with no effect.
Dovecot deletes the TZ environment (and everything else) before starting imap process. Doesn't AIX use something similar to /etc/localtime?
AIX uses TZ, but it has the unique behavior where some environment settings are imported from /etc/environment.
Try running imap binary manually, eg.:
MAIL=~/Maildir /usr/local/libexec/dovecot/imap
and give it the commands to fetch INTERNALDATE (and set TZ if needed?). If it works, maybe I'll start setting TZ for Dovecot's child processes.
It works right when I run the dovecot imap binary manually. Here's the transcript running with my normal TZ=CST6CDT environment:
28: MAIL=/var/imap/dovecot/roma /usr/local/libexec/dovecot/imap permitted.
- PREAUTH [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS] Logged in as roma a001 select inbox
- FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
- OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags
- 62 EXISTS
- 0 RECENT
- OK [UIDVALIDITY 1118339114] UIDs valid
- OK [UIDNEXT 414] Predicted next UID a001 OK [READ-WRITE] Select completed. a002 fetch 1 internaldate
- 1 FETCH (INTERNALDATE "09-Jul-2005 22:58:50 -0500") a002 OK Fetch completed.
And with my TZ environment manually tweaked to North American Pacific Time:
29: TZ=PST8PDT MAIL=/var/imap/dovecot/roma /usr/local/libexec/dovecot/imap permitted.
- PREAUTH [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS] Logged in as roma a001 select inbox
- FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
- OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags
- 62 EXISTS
- 0 RECENT
- OK [UIDVALIDITY 1118339114] UIDs valid
- OK [UIDNEXT 414] Predicted next UID a001 OK [READ-WRITE] Select completed. a002 fetch 1 internaldate
- 1 FETCH (INTERNALDATE "09-Jul-2005 20:58:50 -0700") a002 OK Fetch completed.
Thanks.
Timo:
Was there any more documentation you needed from me on the time zone issue that we had an email exchange about a couple weeks ago?
It looks like you had a fix in mind, but drop me a note either on or off list if I can help with the question of AIX environment variables or anything else related.
Regards and thanks.
Jon Roma roma@uiuc.edu wrote:
Timo Sirainen tss@iki.fi wrote:
On Wed, 2005-07-06 at 17:43 -0500, Jon Roma wrote:
First a few words about my setup. I'm running on AIX 5.1, with SSL enabled. I had to tweak the dovecot-1.0-stable source tree to get rid of the "//"-style comments, since the AIX xlc compiler doesn't like that construct.
Yes, these kind of comments shouldn't be there. I've used them only for "temporary" FIXME-comments, so hopefully when they're all fixed there are no more // comments.. :)
And, as with the 0.99.14 build, there's tons of compiler warnings about
, but the applications build and seem to generally work fine. What sys/types.h errors?
Oh, it's this fun stuff that appears for just about every .c file compiled:
gmake[3]: Entering directory `/usr/local/src/dovecot-1.0-stable-20050705/src/lib' source='base64.c' object='base64.o' libtool=no
DEPDIR=.deps depmode=aix /bin/sh ../../depcomp
cc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -g -c base64.c "/usr/include/sys/types.h", line 118.25: 1506-115 (E) Duplicate type specifier "unsigned" ignored. "/usr/include/sys/types.h", line 118.1: 1506-137 (W) Declaration must declare at least one declarator, tag, or the members of an enumeration. "/usr/include/sys/types.h", line 131.1: 1506-137 (W) Declaration must declare at least one declarator, tag, or the members of an enumeration.Alas, I didn't see anything obvious that causes this, but as mentioned, the executable seems to work fine -- it's just a very noisy compilation. Since I don't know whether attachments to this list are appropriate, please feel free to contact me directly and I'll send you the sys/types.h file and any other information that would help.
IMAP command, UW-imapd gives me the correctly-localized time, while dovecot gives me GMT.
Incidentally, I've tried starting dovecot both with and without chroot and even explicitly setting the TZ environment variable on startup, both with no effect.
Dovecot deletes the TZ environment (and everything else) before starting imap process. Doesn't AIX use something similar to /etc/localtime?
AIX uses TZ, but it has the unique behavior where some environment settings are imported from /etc/environment.
Try running imap binary manually, eg.:
MAIL=~/Maildir /usr/local/libexec/dovecot/imap
and give it the commands to fetch INTERNALDATE (and set TZ if needed?). If it works, maybe I'll start setting TZ for Dovecot's child processes.
It works right when I run the dovecot imap binary manually. Here's the transcript running with my normal TZ=CST6CDT environment:
28: MAIL=/var/imap/dovecot/roma /usr/local/libexec/dovecot/imap permitted.
- PREAUTH [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS] Logged in as roma a001 select inbox
- FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
- OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags
- 62 EXISTS
- 0 RECENT
- OK [UIDVALIDITY 1118339114] UIDs valid
- OK [UIDNEXT 414] Predicted next UID a001 OK [READ-WRITE] Select completed. a002 fetch 1 internaldate
- 1 FETCH (INTERNALDATE "09-Jul-2005 22:58:50 -0500") a002 OK Fetch completed.
And with my TZ environment manually tweaked to North American Pacific Time:
29: TZ=PST8PDT MAIL=/var/imap/dovecot/roma /usr/local/libexec/dovecot/imap permitted.
- PREAUTH [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS] Logged in as roma a001 select inbox
- FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
- OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags
- 62 EXISTS
- 0 RECENT
- OK [UIDVALIDITY 1118339114] UIDs valid
- OK [UIDNEXT 414] Predicted next UID a001 OK [READ-WRITE] Select completed. a002 fetch 1 internaldate
- 1 FETCH (INTERNALDATE "09-Jul-2005 20:58:50 -0700") a002 OK Fetch completed.
Thanks.
On 23.7.2005, at 20:10, Jon Roma wrote:
Was there any more documentation you needed from me on the time zone issue that we had an email exchange about a couple weeks ago?
Oh, I forgot it. Does this patch work: Index: main.c =================================================================== RCS file: /var/lib/cvs/dovecot/src/master/main.c,v retrieving revision 1.62 diff -u -r1.62 main.c --- main.c 5 Mar 2005 20:02:07 -0000 1.62 +++ main.c 23 Jul 2005 17:20:33 -0000 @@ -36,6 +36,7 @@ static struct timeout *to; static unsigned int settings_reload_hup_count = 0; static unsigned int log_reopen_usr1_count = 0; +static const char *env_tz; struct ioloop *ioloop; struct hash_table *pids; @@ -67,6 +68,8 @@ /* we'll log through master process */ env_put("LOG_TO_MASTER=1"); + if (env_tz != NULL) + env_put(t_strconcat("TZ=", env_tz, NULL)); #ifdef DEBUG if (gdb) env_put("GDB=1"); @@ -626,7 +629,11 @@ if (exec_protocol != NULL) mail_process_exec(exec_protocol, exec_section); - /* we don't need any environment anymore */ + /* save TZ environment for child processes. AIX depends on it to get + the timezone correctly. */ + env_tz = getenv("TZ"); + + /* we don't need any other environment anymore */ env_clean(); open_fds();
Timo:
You are very fast. It's not every day one gets a patch within 11 minutes
of asking about it. :)
Anyway, I rebuilt my dovecot tree (based on the stable branch as of
2005/07/05) with your patch. It works! So I consider this problem
fixed and now I can start considering switching over "for real" to
dovecot fairly soon.
Thank you for your fantastically speedy service! :)
Timo Sirainen
On 23.7.2005, at 20:10, Jon Roma wrote:
Was there any more documentation you needed from me on the time zone issue that we had an email exchange about a couple weeks ago?
Oh, I forgot it. Does this patch work:
Index: main.c =================================================================== RCS file: /var/lib/cvs/dovecot/src/master/main.c,v retrieving revision 1.62 diff -u -r1.62 main.c --- main.c 5 Mar 2005 20:02:07 -0000 1.62 +++ main.c 23 Jul 2005 17:20:33 -0000 @@ -36,6 +36,7 @@ static struct timeout *to; static unsigned int settings_reload_hup_count = 0; static unsigned int log_reopen_usr1_count = 0; +static const char *env_tz;
struct ioloop *ioloop; struct hash_table *pids; @@ -67,6 +68,8 @@
/* we'll log through master process */ env_put("LOG_TO_MASTER=1"); + if (env_tz != NULL) + env_put(t_strconcat("TZ=", env_tz, NULL));
#ifdef DEBUG if (gdb) env_put("GDB=1"); @@ -626,7 +629,11 @@ if (exec_protocol != NULL) mail_process_exec(exec_protocol, exec_section);
- /* we don't need any environment anymore */ + /* save TZ environment for child processes. AIX depends on it to get + the timezone correctly. */ + env_tz = getenv("TZ"); + + /* we don't need any other environment anymore */ env_clean();
open_fds();
Timo, I have an addendum to our mail exchange about timezones.
It turns out that the various dovecot applications running on my AIX
5.1 system are logging in GMT instead of in local time. I noticed this
earlier, but in the course of troubleshooting the issue with mail
reporting the wrong time zone, I forgot to report this to you -- my
apologies!
Jul 24 18:03:50 zippy dovecot: Dovecot v1.0-stable starting up
Jul 24 18:07:52 zippy dovecot: imap-login: Login: roma [192.17.16.93]
(The times are, of course, 5 hours ahead -- the difference between my
local time (CST6CDT) and GMT.
I'd guess this problem is caused by the same root cause as the other
problem, so the bad news is that this probably means the TZ patch you
sent me should probably also be applied to the other dovecot executables.
FWIW, as you can see above, I have seen misdated log messages from
dovecot itself as well as imap-login. Haven't seen from any of the
other applications, but I suppose this behavior is theoretically
possible with all the other dovecot applications.
Jon Roma
Timo:
You are very fast. It's not every day one gets a patch within 11 minutes of asking about it. :)
Anyway, I rebuilt my dovecot tree (based on the stable branch as of 2005/07/05) with your patch. It works! So I consider this problem fixed and now I can start considering switching over "for real" to dovecot fairly soon.
Thank you for your fantastically speedy service! :)
Timo Sirainen
wrote: On 23.7.2005, at 20:10, Jon Roma wrote:
Was there any more documentation you needed from me on the time zone issue that we had an email exchange about a couple weeks ago?
Oh, I forgot it. Does this patch work:
Index: main.c =================================================================== RCS file: /var/lib/cvs/dovecot/src/master/main.c,v retrieving revision 1.62 diff -u -r1.62 main.c --- main.c 5 Mar 2005 20:02:07 -0000 1.62 +++ main.c 23 Jul 2005 17:20:33 -0000 @@ -36,6 +36,7 @@ static struct timeout *to; static unsigned int settings_reload_hup_count = 0; static unsigned int log_reopen_usr1_count = 0; +static const char *env_tz;
struct ioloop *ioloop; struct hash_table *pids; @@ -67,6 +68,8 @@
/* we'll log through master process */ env_put("LOG_TO_MASTER=1"); + if (env_tz != NULL) + env_put(t_strconcat("TZ=", env_tz, NULL));
# ifdef DEBUG if (gdb) env_put("GDB=1"); @@ -626,7 +629,11 @@ if (exec_protocol != NULL) mail_process_exec(exec_protocol, exec_section);
- /* we don't need any environment anymore */ + /* save TZ environment for child processes. AIX depends on it to get + the timezone correctly. */ + env_tz = getenv("TZ"); + + /* we don't need any other environment anymore */ env_clean();
open_fds();
On Sun, 2005-07-24 at 14:12 -0500, Jon Roma wrote:
Timo, I have an addendum to our mail exchange about timezones.
It turns out that the various dovecot applications running on my AIX 5.1 system are logging in GMT instead of in local time. I noticed this earlier, but in the course of troubleshooting the issue with mail reporting the wrong time zone, I forgot to report this to you -- my apologies!
Jul 24 18:03:50 zippy dovecot: Dovecot v1.0-stable starting up Jul 24 18:07:52 zippy dovecot: imap-login: Login: roma [192.17.16.93]
Actually it's the other way around. The TZ environment gets passed to all child processes, but the Dovecot master process itself that does the logging has forgotten about it. Fixed in CVS now.
On Wed, 2005-07-06 at 16:55 -0400, Mark E. Mallett wrote:
On Wed, Jul 06, 2005 at 11:19:33PM +0300, Timo Sirainen wrote:
Maildir++: Maildir/.maildir.subfolder/ Maildir/.mbox.subfolder.file
That would be interesting. But I was thinking that mbox (and every other kind of storage) would have to be encapsulated inside a subdirectory so that it could contain any indexes and any other control files that might be wanted down the road. No?
Well, whatever people want when the list/format separation is done :)
The Maildir/.mbox.subfolder.file index could be stored in Maildir/.imap/ directory the way they are now stored for mboxes.
On Jul 2, 2005, at 07:32, Martin Lucina wrote:
Hi,
I'm in the process of migrating several years worth of mail to be accessible via an IMAP server. Some time ago, I evaluated both Binc IMAP and Dovecot and found Dovecot to be much faster on large folders, which is quite important to me. One thing I did not however manage to determine from the documentation on namespaces is whether or not it is possible to implement what Binc IMAP calls an "IMAPdir" style layout.
IMAPdir lets me layout mailboxes in the filesystem like so:
$HOME/ Maildir/ <---- users mail goes here Mail/ <---- IMAP root INBOX -> ../Maildir/ <---- (symlink) folder/ <---- some other mailbox in Maildir
format folder.subfolder/ <---- '.' is the hierarchy separator folder.subfolder-2/ other-folder/So IMAP clients subscribe to 'INBOX' and 'folder' and 'folder/ subfolder' respectively.
This gives me two features that I want:
- The ability to easily access all my mail using a command line
Maildir capable client such as nail, for when I'm connection over a super-slow SSH over GPRS connection. Also, I can actually see my folders (and their subfolders) without having to look for Maildir++ style names
with 'ls -a' (e.g. Maildir/.subfolder/).
[snip]
One problem I've had with using dovecot (and it looks like other
imap servers do this as well) and a CLI Maildir client (mutt) is that
whenever
I access the Maildirs via IMAP, all new messages get moved to cur/.
Mutt (w/ my config) marks unread messages in cur/ as O (old) rather
than N (new). Messages in new/ are marked N, and (the kicker) only
mailboxes with messages in new/ are marked as having new messages.
I'd really like to have messages that are accessed via dovecot (IMAP)
stay in new/, is there a reason that they get moved to cur/ ? I've
dug around some (both in dovecot and general maildir googling),
haven't found an answer.
Thanks much,
-eric
On Fri, 2005-07-08 at 13:29 -0700, Eric Hall wrote:
One problem I've had with using dovecot (and it looks like other
imap servers do this as well) and a CLI Maildir client (mutt) is that
whenever I access the Maildirs via IMAP, all new messages get moved to cur/.
Mutt (w/ my config) marks unread messages in cur/ as O (old) rather
than N (new). Messages in new/ are marked N, and (the kicker) only
mailboxes with messages in new/ are marked as having new messages.
I'd really like to have messages that are accessed via dovecot (IMAP)
stay in new/, is there a reason that they get moved to cur/ ? I've
dug around some (both in dovecot and general maildir googling),
haven't found an answer.
This is because the messages in new/ directory are treated as IMAP's "recent" messages, ie. messages that have noticed but not read yet. It would be possible to move the messages later, but it'd break IMAP protocol then, so I'm not going to implement it.
Although I've seen same feature request for POP3, so I could implement it for Dovecot's mail accessing functions, so it could be supported for IMAP with changing only one line in code..
Anyway, why not just make mutt use IMAP and you shouldn't have this problem?
On Tue, Jul 12, 2005 at 04:34:20PM +0300, Timo Sirainen wrote:
On Fri, 2005-07-08 at 13:29 -0700, Eric Hall wrote:
One problem I've had with using dovecot (and it looks like other
imap servers do this as well) and a CLI Maildir client (mutt) is that
whenever I access the Maildirs via IMAP, all new messages get moved to cur/.
Mutt (w/ my config) marks unread messages in cur/ as O (old) rather
than N (new). Messages in new/ are marked N, and (the kicker) only
mailboxes with messages in new/ are marked as having new messages.
I'd really like to have messages that are accessed via dovecot (IMAP)
stay in new/, is there a reason that they get moved to cur/ ? I've
dug around some (both in dovecot and general maildir googling),
haven't found an answer.This is because the messages in new/ directory are treated as IMAP's "recent" messages, ie. messages that have noticed but not read yet. It would be possible to move the messages later, but it'd break IMAP protocol then, so I'm not going to implement it.
Do you mean read by the imap process, or read by the user?
No problem if its what the protocol says to do.
Although I've seen same feature request for POP3, so I could implement it for Dovecot's mail accessing functions, so it could be supported for IMAP with changing only one line in code..
Anyway, why not just make mutt use IMAP and you shouldn't have this problem?
Partially because I don't need all of my mail accessible via
IMAP, and partially because it seems silly to have mutt talk to an IMAP process when mutt can access the filesystem directly (its running on the host that the mail is on).
Thanks much,
-eric
participants (6)
-
Eric Hall
-
Johannes Berg
-
Jon Roma
-
Mark E. Mallett
-
Martin Lucina
-
Timo Sirainen