September 2011 - dovecot

[Dovecot] [PATCH] Bad boundary check in client_find_namespace
by Christoph Bussenius 09 Feb '12

09 Feb '12

Hi, while trying to investigate the bug I reported last week, I found that there is a broken boundary check in client_find_namespace in src/imap/imap-commands-util.c. The code is: /* make sure two hierarchy separators aren't next to each others */ for (p = storage_name+1; *p != '\0'; p++) { if (p[0] == ns->real_sep && p[-1] == ns->real_sep) { client_send_tagline(cmd, "NO Invalid mailbox name."); return NULL; } } The loop iterates over the string storage_name starting from its second byte. However, the string may be "". This is the case if you select the root of a namespace, like in "SELECT shared" or "SELECT shared/user1". In that case, the code will read past the end of the buffer from random memory until it finds a zero byte or a duplicate separator. This would fix it: diff -ru dovecot-2.0.15.orig/src/imap/imap-commands-util.c dovecot-2.0.15/src/imap/imap-commands-util.c --- dovecot-2.0.15.orig/src/imap/imap-commands-util.c 2011-08-02 12:29:37.000000000 +0200 +++ dovecot-2.0.15/src/imap/imap-commands-util.c 2011-09-26 18:33:16.121917759 +0200 @@ -81,7 +81,9 @@ } /* make sure two hierarchy separators aren't next to each others */ - for (p = storage_name+1; *p != '\0'; p++) { + for (p = storage_name; *p != '\0'; p++) { + if (p == storage_name) + continue; if (p[0] == ns->real_sep && p[-1] == ns->real_sep) { client_send_tagline(cmd, "NO Invalid mailbox name."); return NULL; Cheers, Christoph Bußenius -- Christoph Bußenius Rechnerbetriebsgruppe der Fakultäten Informatik und Mathematik TU München +49 89-289-18519 <> Raum 00.05.055 <> Boltzmannstr. 3 <> Garching

3 2

[Dovecot] 2.0.14 doveadm proxy list segfault
by Tom Pawlowski 09 Feb '12

09 Feb '12

Hi Timo, Periodic segfaults with doveadm proxy list: root@director1:~) doveadm proxy list doveadm(root): Error: LIST failed: Disconnected Segmentation fault (core dumped) Sometimes it's just the 'LIST failed' error, other times it's the error with the segfault. Usually the first attempt to call it works, subsequent attempts fail. I've attached a strace log of it in action. -- Tom Pawlowski OIT-CSS System Administrator office: Hill 147 email: tompru(a)jla.rutgers.edu phone: (732) 445-2634

2 1

[Dovecot] movming mail out of alt storage
by Micah Anderson 31 Jan '12

31 Jan '12

I moved some mail into the alt storage: doveadm altmove -u johnd(a)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'. thanks! micah --

3 5

[Dovecot] compressed mboxes very slow
by kjonca＠o2.pl 29 Jan '12

29 Jan '12

I have some archive mails in gzipped mboxes. I could use them with dovecot 1.x without problems. But recently I have installed dovecot 2.0.12, and they are slow. very slow. Creating index files takes about 10 minutes for ~20M file with 560 messages for bzipped mbox, for gzipped is little better but still unusable :( Stracing dovecot process shows that every ~ 20 messages it rereads complete mbox file. Am I doing something wrong? KJ -- http://modnebzdury.wordpress.com/2009/10/01/niewiarygodny-list-prof-majewsk…

4 13

[Dovecot] mail_max_userip_connections=10
by Tom Clark 12 Dec '11

12 Dec '11

Hi, A couple of questions rather than a problem for once! We've got our Dovecot server running smoothly now apart from our MD. He's having problems with mail_max_userip_connections. He has 3 (Phone/Laptop/Tablet) items that all connect to the server at about the same time. Which means he's frequently running over the max_userip_connections. My questions are: Is there anyway of whitelisting an IP so that it can ignore mail_max_userip_connections=10? What should we set mail_max_userip_connections too realistically? 10 seems a bit low? Thanks Tom

6 10

[Dovecot] [PATCH] SCRAM-SHA-1 authentication
by Florian Zeitz 23 Nov '11

23 Nov '11

Hy, over the last days I have implemented SCRAM-SHA-1 in Dovecot's 2.1 branch. It does not do SCRAM-SHA-1-PLUS, but should be extendable enough to introduce it later. There are some checks for the message format which (assuming the client acts correclty) are not strictly necessary during parsing. This is partially in the hope that it might aid client implementers, partially because it (IMHO) improves readability when checking against the RFC. Also errors found in this way could be sent to the client, this is however strictly OPTIONAL in the RFC, for now they are just logged. Some of the variable names are rather long. This is in order to have them match the terms introduced in the RFC, again I expect it to help readability (maybe my recent Objective-C programming showing though). I do feel somewhat insecure about my usage of some lib functions. Hopefully no API has been abused too much. I also note that there are a lot of fields in the scram_auth_request struct. I think they are all there for a reason, however feel free to prove me wrong. Attached is a hg export. It also includes a hmac-sha1 implementation, an adaption off of the hmac-md5 implementation already in Dovecot. I guess those should eventually be merged into a hash-independent hmac implementation, but I figured this would have to do for now. The implementation has been tested against GNU SASL and does appear to work fine. (The command line was `gsasl -m SCRAM-SHA-1 -a user -p pass --imap host` for those curious) Regards Florian "Florob" Zeitz

3 5

[Dovecot] Glued-together private namespaces
by Mark Moseley 16 Nov '11

16 Nov '11

I've been goofing with this all day with 2.0.15 and I'm starting to realize that either a) I'm not that smart, b) it's been so long since I messed with namespaces that I'm going about it completely wrong, or c) it's just not possible. I haven't posted 'doveconf -n' and other details, because mainly I'm just looking for 'yes, this is possible' or 'no, you're smoking crack' before posting further details. At this point, it's all maildir and moving to mdbox, while highly desirable in the future, is not possible in the near- to medium-term. I'm trying to glue a namespace underneath INBOX: namespace INBOX { type = private separator = . prefix = INBOX. # Yes, this used to be on Courier inbox = yes list = yes hidden = no subscriptions = yes location = maildir:~/Maildir } namespace archive { type = private separator = . prefix = INBOX.Archives. inbox = no list = children subscriptions = yes location = maildir:~/Maildir-Archive } I've tried putting namespace archive's 'prefix' as just "Archives", but Tbird doesn't seem to see this namespace, regardless of how much I futz with the imap settings in tbird. With the above setup, it actually seems to work correctly (provided ~/Maildir-Archive exists), though I'm sure a big gotcha is waiting in the wings. I can move messages around, create subfolders, subscribe to folders in ~/Maildir-Archive). The only thing I can't seem to get working is quotas. With my password_query like: password_query = ... CONCAT( '*:bytes=', "1M" ) AS 'userdb_quota_rule', \ CONCAT( '*:messages=10' ) AS 'userdb_quota_rule2', \ CONCAT( 'INBOX.Archives:bytes=+4900M' ) AS 'userdb_quota_rule3', \ CONCAT( 'INBOX.Archives:messages=+3900' ) AS 'userdb_quota_rule4' ... only the default quota seems to be in place for any subfolder of INBOX.Archives and for INBOX.Archives itself, i.e. *:bytes still applies to INBOX.Archives. The debug log show that: Debug: Quota root: name=User quota backend=maildir args= Debug: Quota rule: root=User quota mailbox=* bytes=1048576 messages=0 Debug: Quota rule: root=User quota mailbox=* bytes=1048576 messages=10 Debug: Quota rule: root=User quota mailbox=INBOX.Archives bytes=+5138022400 messages=0 Debug: Quota rule: root=User quota mailbox=INBOX.Archives bytes=+5138022400 messages=+3900 These are wildly stupid quotas but they're just there to test. With INBOX already at capacity (byte-wise; only set to a meg), copying large messages inside INBOX.Archives fails (only copying a 800k message but the quota should be 5gig now). Again, before I post configs, I'm just curious if what I'm trying to do isn't remotely possible, or that I'm approaching this entirely wrongly. Thanks!

2 6

[Dovecot] Managing public folder ACL files
by Keith Edmunds 14 Nov '11

14 Nov '11

We have a customer with a large public folder hierarchy. They occasionally make requests to have the public folder ACLs changed; for example: "please give user X access to all public folders" (that's nearly 1700 folders). Worse: "please give user Y access to all sales folders" (there are 1450 sales folders). The problem is that there are (naturally) spaces in the folder names, which makes command line manipulation challenging. We've ended up with some astonishingly hacky Python scripts that enter each folder starting with (for example) ".sales" and replacing the dovecot-acl file to try to fulfil the above requests. One day our script are going to get it wrong, or requests will become more complex ("give X access all sales/CustA folders, Y access to all sales/CustB folders, and Z access to all sales folders). There must be a Better Way. How do others manage divergent ACLs within large public folder hierarchies? Thanks, Keith

5 4

[Dovecot] LDAP expired password
by roberto palmarin 10 Nov '11

10 Nov '11

hi all, I'm using postfix, LDAP, dovecot and horde for webmail. user and password information is stored in LDAP. I'm attempting to get password aging working properly and am not having much luck. even if password has expired user can login, can i tell dovecot to control the LDAP field shadowexpired? or is there some other way to check properly that the password is expired before allowing the user log in? thank's /roby

4 5

[Dovecot] dsync with quotas
by Micah Anderson 05 Nov '11

05 Nov '11

I have been working on converting people from courier maildir -> dovecot mdbox and during some of the dsync runs I'm seeing the quota_exceeded_message be printed as an Error: dsync(<user>): Error: Can't save message to mailbox INBOX: You are over quota. To avoid losing mail, immediately empty your Trash and Sent folders and \ delete emails with large attachments. dsync(<user>): Info: INBOX: Couldn't keep all uids^M Its possible the user was over quota on the originating courier side, but I would still like to migrate their mail proprely to mdbox, but it seems like being over quota is inhibiting that. Are the quota calculations including both the maildir files as well as the converted mdbox files, resulting in a double counting? I'm not entirely sure if the messages above indicate that the migration failed for that user or not, so I've been manually increasing their quota, then redoing the dsync mirror until it works properly. I wonder if it would be better if I turned off quota entirely during migration so I don't run into this problem? thanks, micah --

2 2