http://dovecot.org/releases/1.1/dovecot-1.1.11.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.11.tar.gz.sig
Hopefully this v1.1 release will last a few months.
- IMAP: PERMANENTFLAGS list didn't contain \*, causing some clients
not to save keywords.
- dbox: INTERNALDATE and save date was returned wrong for converted
maildir files.
- auth: Using "username" or "domain" passdb fields caused problems
with cache and blocking passdbs in v1.1.8 .. v1.1.10.
- userdb prefetch + blocking passdbs was broken with non-plaintext
auth in v1.1.8 .. v1.1.10.
- If mail_chroot is set, don't fail at startup in dump-capability.On Feb 3, 2009, at 5:53 PM, Timo Sirainen wrote:
http://dovecot.org/releases/1.1/dovecot-1.1.11.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.11.tar.gz.sig
Just FYI, ONLY SINCE UPGRADING TO 1.1.11 from 1.1.10, a 'killall
dovecot' yields this...
Feb 5 07:59:23 G520X2 dovecot: Killed with signal 15
Feb 5 07:59:23 G520X2 dovecot: child 23439 (<^?) returned error 82
(Internal logging error)
Feb 5 07:59:24 G520X2 crashdump[23503]: dovecot crashed
Feb 5 07:59:24 G520X2 crashdump[23503]: crash report written to: /
Library/Logs/CrashReporter/dovecot.crash.log
Contents of crash log...
Host Name: G520X2 Date/Time: 2009-02-05 07:59:24.054 -0600 OS Version: 10.4.11 (Build 8S165) Report Version: 4
Command: dovecot Path: /usr/local/sbin/dovecot Parent: launchd [1]
Version: ??? (???)
PID: 22087 Thread: 0
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000018
Thread 0 Crashed: 0 <<00000000>> 0x00000018 0 + 24 1 dovecot 0x00004284 child_processes_deinit + 36 (child-process.c: 226) 2 dovecot 0x0000aaa8 main + 2504 (main.c:333) 3 dovecot 0x00001d4c _start + 760 4 dovecot 0x00001a50 start + 48
Thread 0 crashed with PPC Thread State 64:
srr0: 0x0000000000000018 srr1:
0x100000004000f030 vrsave: 0x0000000000000000
cr: 0x84004434 xer: 0x0000000020000000 lr:
0x00000000000040fc ctr: 0x0000000000000018
r0: 0x0000000000000018 r1: 0x00000000bffff8d0 r2:
0x0000000000029fbc r3: 0x0000000000301fa0
r4: 0x0000000000005b8f r5: 0x0000000000000001 r6:
0x0000000000000000 r7: 0x0000000000000000
r8: 0x0000000000000000 r9: 0x0000000000000000 r10:
0x0000000000000002 r11: 0x00000000a00061ec
r12: 0x0000000000000018 r13: 0x000000000002a0f4 r14:
0x000000000002a0f4 r15: 0x000000000002a0f4
r16: 0x0000000000000000 r17: 0x000000000002a0f4 r18:
0x0000000000000000 r19: 0x000000000002a0f4
r20: 0x0000000000000000 r21: 0x0000000000000001 r22:
0x0000000000000000 r23: 0x0000000000000000
r24: 0x0000000000000001 r25: 0x00000000000091e0 r26:
0x0000000000301fa0 r27: 0x000000000000d5ec
r28: 0x00000000000961e8 r29: 0x0000000000096288 r30:
0x0000000000005b8f r31: 0x0000000000003db4
Binary Images Description: 0x1000 - 0x28fff dovecot /usr/local/sbin/dovecot 0x8fe00000 - 0x8fe52fff dyld 46.16 /usr/lib/dyld 0x90000000 - 0x901bcfff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x90214000 - 0x90219fff libmathCommon.A.dylib /usr/lib/system/ libmathCommon.A.dylib
You may remember an obscure OS X bug relative to the syslogd
restart. For over a year I've been sending the 'killall' in a
daily.local or else dovecot's log entries would not get written to
mail.log after the syslogd gets restarted. Since I'm using the OS X
launchdaemons, dovecot gets restarted after the 'killall'. Anyway,
for over the year, this crash had never been written to the logs
prior to last night and upgrading to 1.1.11. All continues to work
fine but something has definitely changed since 1.1.10.
B. Bodger
Timo Sirainen wrote:
http://dovecot.org/releases/1.1/dovecot-1.1.11.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.11.tar.gz.sig
I've refreshed the ManageSieve patch for the new release:
http://www.rename-it.nl/dovecot/1.1/dovecot-1.1.11-managesieve-0.10.5.diff.g... http://www.rename-it.nl/dovecot/1.1/dovecot-1.1.11-managesieve-0.10.5.diff.g...
Hopefully this v1.1 release will last a few months. I hope so too :)
Regards,
Stephan
Timo Sirainen skrev:
Hopefully this v1.1 release will last a few months.
Builing on OpenBSD 4.4 (which has an ancient compiler, now I know), I got some warnings. There is one warning not related to this compiler's pointer handling which is worth considering I think:
maildir-sync-index.c:295: warning: `j' might be used uninitialized in this function
In function maildir_sync_mail_keywords, j is assumed to be initialized to 0 I think. It is used in line 339 in the for statement. Changing to for (i = j = 0; removed this warning, and removed my doubts :-)
There is a similar warning for mailbox-list-fs-iter.c, but as far as I can tell the warning is unjustified?
mailbox-list-fs-iter.c:483: warning: `real_path' might be used uninitialized in this function
/Peter
Peter Lindgren http://www.norrskenkonsult.com
On Thu, 2009-02-05 at 21:59 +0100, Peter Lindgren wrote:
Timo Sirainen skrev:
Hopefully this v1.1 release will last a few months.
Builing on OpenBSD 4.4 (which has an ancient compiler, now I know), I got some warnings. There is one warning not related to this compiler's pointer handling which is worth considering I think:
maildir-sync-index.c:295: warning: `j' might be used uninitialized in this function
:(
I actually fixed this already in v1.2 tree, but for some reason not in v1.1 tree.
But since this is only a problem when using >26 keywords and that had already been broken for years, I don't think I'll bother releasing a new version just to fix that.
Anyway, fixed by: http://hg.dovecot.org/dovecot-1.1/rev/4736327a8740
There is a similar warning for mailbox-list-fs-iter.c, but as far as I can tell the warning is unjustified?
mailbox-list-fs-iter.c:483: warning: `real_path' might be used uninitialized in this function
Yes, that can't really happen.
On February 5, 2009 4:14:24 PM -0500 Timo Sirainen tss@iki.fi wrote:
On Thu, 2009-02-05 at 21:59 +0100, Peter Lindgren wrote:
There is a similar warning for mailbox-list-fs-iter.c, but as far as I can tell the warning is unjustified?
mailbox-list-fs-iter.c:483: warning: `real_path' might be used uninitialized in this function
Yes, that can't really happen.
probably should eliminate the warning anyway?
On Feb 7, 2009, at 1:48 AM, Frank Cusack wrote:
On February 5, 2009 4:14:24 PM -0500 Timo Sirainen tss@iki.fi wrote:
On Thu, 2009-02-05 at 21:59 +0100, Peter Lindgren wrote:
There is a similar warning for mailbox-list-fs-iter.c, but as far
as I can tell the warning is unjustified?mailbox-list-fs-iter.c:483: warning: `real_path' might be used uninitialized in this function
Yes, that can't really happen.
probably should eliminate the warning anyway?
Newer gcc versions don't warn about it. I don't bother with all the
warnings from old gccs.
On February 5, 2009 9:59:10 PM +0100 Peter Lindgren peter@norrskenkonsult.com wrote:
maildir-sync-index.c:295: warning: `j' might be used uninitialized in this function
In function maildir_sync_mail_keywords, j is assumed to be initialized to 0 I think. It is used in line 339 in the for statement. Changing to for (i = j = 0; removed this warning, and removed my doubts :-)
Should be for (i = (j = 0);
a = b = ... is not legal, although gcc does accept it.
-frank
On Feb 7, 2009, at 1:47 AM, Frank Cusack wrote:
for (i = j = 0;removed this warning, and removed my doubts :-)
Should be for (i = (j = 0);
a = b = ... is not legal, although gcc does accept it.
Really? I've seen a=b=c like code for a long time. But I can't say
exactly where C99 would allow that. Anyway I'd think parenthesis only
affect precedence ordering, not whether something is allowed or not.
Although there is one example in C99 spec (well, I've only a draft)
that seems to suggest it's legal:
5.1.2.3 Environment 5.1.2.3
double d1, d2;
float f;
d1 = f = expression;
d2 = (float) expressions;
the values assigned to d1 and d2 are required to have been converted
to float.
On Feb 7, 2009, at 1:47 AM, Frank Cusack wrote:
for (i = j = 0;removed this warning, and removed my doubts :-)
Should be for (i = (j = 0);
a = b = ... is not legal, although gcc does accept it.
Really? I've seen a=b=c like code for a long time. But I can't say exactly where C99 would allow that. Anyway I'd think parenthesis only affect precedence ordering, not whether something is allowed or not.
Although there is one example in C99 spec (well, I've only a draft) that seems to suggest it's legal:
5.1.2.3 Environment 5.1.2.3
double d1, d2; float f; d1 = f = expression; d2 = (float) expressions; the values assigned to d1 and d2 are required to have been converted to float.
i = j = 0 is perfectly legal. I just spent about 1/2 hour going through
my collection of C language books, plus a scan through a dozen or so web
pages, and none suggest parens are necessary or even common practice.
With all the warnings turned on, neither gcc nor Sun Studio 12 complain
about the lack of parens. The expression evaluates right to left, and
so long as the left side of the operator is an lvalue it is valid
syntax. See http://docs.hp.com/en/B3901-90007/ch05s03.html for further
information.
Jack
On February 7, 2009 2:19:59 AM -0500 Timo Sirainen tss@iki.fi wrote:
On Feb 7, 2009, at 1:47 AM, Frank Cusack wrote:
for (i = j = 0;removed this warning, and removed my doubts :-)
Should be for (i = (j = 0);
a = b = ... is not legal, although gcc does accept it.
Really? I've seen a=b=c like code for a long time. But I can't say exactly where C99 would allow that. Anyway I'd think parenthesis only affect precedence ordering, not whether something is allowed or not.
Well now, there's lot of code you might see which isn't correct, e.g. the very common #!/bin/sh but the code is actually a bash script.
In this case though, I believe Jack is correct and it is legal. I don't know where I got the idea it was invalid. Well, I do know but I won't embarrass myself further. :)
-frank
On Saturday 07 February 2009 04:02:56 Frank Cusack wrote:
Well now, there's lot of code you might see which isn't correct, e.g. the very common #!/bin/sh but the code is actually a bash script.
Being someone that has to fix this stuff I see A LOT of people improperly writting bash scripts and 99% of the time the bash-isms are not necessary at all.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Feb 7, 2009, at 12:06 PM, Brad wrote:
On Saturday 07 February 2009 04:02:56 Frank Cusack wrote:
Well now, there's lot of code you might see which isn't correct, e.g. the very common #!/bin/sh but the code is actually a bash script.
Being someone that has to fix this stuff I see A LOT of people
improperly writting bash scripts and 99% of the time the bash-isms are not
necessary at all.
Yup, I run across that with some frequency myself. It's pretty
annoying. The basic assumption seems to be that /bin/sh is always bash.
In the 1980s, the annoying assumption was "all the world's a
VAX". Now, it's "all the world's a PC running Linux".
*grumble*
-Dave-- Dave McGuire Port Charlotte, FL
Timo Sirainen wrote:
http://dovecot.org/releases/1.1/dovecot-1.1.11.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.11.tar.gz.sig
- If mail_chroot is set, don't fail at startup in dump-capability.
Now whenever a system user (using passwd passdb/userdb) is trying to read the mail, it tries to chroot without stripping initial chroot specific path components, for example:
Feb 8 13:39:10 hargon dovecot: Fatal: chdir(/home/home/test) failed with uid 2999: No such file or directory
with user 'test' having homedir under /home/test and mail_chroot=/home
Michal Soltys wrote:
Timo Sirainen wrote:
http://dovecot.org/releases/1.1/dovecot-1.1.11.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.11.tar.gz.sig
- If mail_chroot is set, don't fail at startup in dump-capability.Now whenever a system user (using passwd passdb/userdb) is trying to read the mail, it tries to chroot without stripping initial chroot specific path components, for example:
Feb 8 13:39:10 hargon dovecot: Fatal: chdir(/home/home/test) failed with uid 2999: No such file or directory
with user 'test' having homedir under /home/test and mail_chroot=/home
but the entire point of chrooting is _changing_ the root directory.
So it seems quite obvious that you need to strip your homedirs yourself. How else could you otherwise define /home/home/test if you really wanted to do?
-- Udo Rader, CTO http://www.bestsolution.at
Udo Rader wrote:
Michal Soltys wrote:
Timo Sirainen wrote:
http://dovecot.org/releases/1.1/dovecot-1.1.11.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.11.tar.gz.sig
- If mail_chroot is set, don't fail at startup in dump-capability.Now whenever a system user (using passwd passdb/userdb) is trying to read the mail, it tries to chroot without stripping initial chroot specific path components, for example:
Feb 8 13:39:10 hargon dovecot: Fatal: chdir(/home/home/test) failed with uid 2999: No such file or directory
with user 'test' having homedir under /home/test and mail_chroot=/home
but the entire point of chrooting is _changing_ the root directory.
So it seems quite obvious that you need to strip your homedirs yourself. How else could you otherwise define /home/home/test if you really wanted to do?
Dovecot is quite flexible in this regard. From the perspective of userdb
- you can set /./ , or /. at the end of user's directory and dovecot will chroot properly, stripping path before /./ itself.
Or you can return userdb_chroot which can be used with or without /./ - if it's used without, than you have to setup user directories in userdb without chroot-part path. With /./ it's the same as above - dovecot will strip the paths properly itself.
In 1.1rc10, global dovecot.conf's parameter always stripped the paths, regardless if /./ was or wasn't used (it never was mentioned actually). I've made some tests now and it seems it has to be used.
Also it's important to use just /. if you chroot at the end of the path. /./ will confuse dovecot in such case.
Timo - I'll update the wiki page to reflect the current situation, if the current behavior is assumed proper.
Michal Soltys wrote:
Now whenever a system user (using passwd passdb/userdb) is trying to read the mail, it tries to chroot without stripping initial chroot specific path components
That of course applies to any non-explicitly overriden chroot through userdb. Doesn't have to be passwd.
participants (10)
-
Brad
-
Bruce Bodger
-
Dave McGuire
-
Frank Cusack
-
Jack Bailey
-
Michal Soltys
-
Peter Lindgren
-
Stephan Bosch
-
Timo Sirainen
-
Udo Rader