- dovecot - dovecot.org

[dovecot] KMail?
by Joakim Ryden 07 May '03

07 May '03

Hey everyone - is anyone else having problems with Dovecot and KMail? I'm having trouble seeing my INBOX using KMail (Maildir format on the server), though all subfolders show up as normal. I suspect the problem is with KMail as all the other mail clients I've tested seem to have no such problems, they see INBOX *and* subfolders just fine, just wanted to see if anyone could confirm this behaviour? --Jo

2 1

[dovecot] dovecot and squirrelmail
by Warren Togami 07 May '03

07 May '03

Is anyone using squirrelmail with dovecot? After a few minor tweaks squirrelmail seems to work great, but I can't seem to get rid of the "./" folder. SquirrelMail implements some workaround hacks for specific IMAP server quirks. The default setting is: $imap_server_type = 'uw'; What settings do you folks use? Thanks, Warren Togami warren(a)togami.com

2 1

[dovecot] 0.99.9.1 - Runaway imap-login process
by Warren Togami 07 May '03

07 May '03

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 32116 dovecot 19 0 1464 1464 1212 R 99.9 0.1 60:58 0 imap-login service dovecot stop ps -ef |grep imap-login |grep -v grep dovecot 32116 1 98 01:27 ? 01:01:33 imap-login /etc/dovecot.conf: auth_userdb = passwd uth_passdb = pam I think this was triggered while I attempted to login to IMAP with the this dovecot configuration without adding an "imap" entry to /etc/pam.d/ (auth fails). When I attempt to strace -p this runaway process, it strangely displays nothing. kill was able to get rid of it. After I added an appropriate /etc/pam.d/imap entry, auth works and I didn't see this runaway process. This is a RH9 chroot server instance running within Linux virtual server with security contexts kernel. (Think of it as a theoretically unbreakable chroot.) Any tips on what I can do to get some debugging information out of this? Thanks, Warren Togami warren(a)togami.com

2 1

[dovecot] Re: 0.99.9.1 OpenBSD and mbox
by Alvaro Munoz-Aycuens Mtnz. 07 May '03

07 May '03

Hi all, Now it works, these are the parameters I touched, the rest remains pretty the same as the example conf: #default_mail_env =mbox:~/mail/:INBOX=/var/mail/%u #mailbox_check_interval = 1 #mbox_locks = fcntl Anyway seems that HUP doesn't fully gets dovecot to reread conf file and restart, better to use SIGUSR1?, by the way how I disable dotlocking in case I want to try. Regards Alvaro Timo Sirainen wrote: > > Right. You'd have to either disable dotlocking or make /var/mail > world-writable and sticky. Currently there's no other ways around this. > >

2 1

[dovecot] 0.99.9.1
by Timo Sirainen 05 May '03

05 May '03

Some bugfixes: v0.99.9.1 2003-05-03 Timo Sirainen <tss(a)iki.fi> - Messages having lines longer than 8192 bytes caused problems. - There was some problems when opening a mbox first time that had been empty for a while. - Didn't compile with OpenBSD. - POP3 server crashed sometimes instead of printing error message. - If cached IMAP envelope contained literals, SEARCHing in it wrote errors to log file. For example if subject contained highascii, '"' or '\' characters this happened.

3 2

[dovecot] 0.99.9 released
by Timo Sirainen 05 May '03

05 May '03

As promised yesterday :) BTW. I just found libsqlora8 library yesterday and I've been playing with Oracle mail storage support. Shouldn't take too long to get it working. And the NEWS file once more: v0.99.9 2003-04-28 Timo Sirainen <tss(a)iki.fi> * WARNING: mbox rewriting works now faster, but it's less likely to notice external message flag changes (it wasn't perfect before either). This also means that if you're not using index files, Dovecot may not notice changes made by another Dovecot process. This will be fixed later. + Message UIDs are now permanently stored outside index files. Deleting indexes is now possible without any kind of data loss and in-memory indexes are now usable. + mbox rewriting leaves extra space into X-Keywords header. It's shrinked or grown when updating message flag headers to avoid rewriting the rest of the file. + imap-login and pop3-login can now be started from inetd. Privilege separation is still used, so it executes dovecot and dovecot-auth processes which are left on the background. + PostgreSQL authentication support, patch by Alex Howansky - Large multiline headers (over 8kB) broke Dovecot before. Now they're parsed one line at a time and we try to avoid reading them fully into memory. - SEARCH OR was broken - Partial BODY[] fetches were broken - Timezones were still set wrong when parsing dates - Using non-synchronized literals (LITERAL+) broke APPEND - Renaming maildir subfolders inserted extra "." in the middle. - Subfolders were a bit broken with maildir - Invalid PLAIN auth request crashed auth process.

2 3

[dovecot] 0.99.9.1 OpenBSD and mbox
by Alvaro Munoz-Aycuens Mtnz. 03 May '03

03 May '03

Hi, compiled perfectly, so the patch of course work ;), but seems that I had the conf a bit broken, because he doesn't read the new messages in /var/mail/user, does the line: #default_mail_env = mbox:~/Mail:INBOX=/var/mail/username look good?, I also tryed with %h instead of username, the rest of the conf is pretty standard, I can create folders and so on. Regards Alvaro

3 3

[dovecot] Problems fetching messages.
by Ian Kumlien 03 May '03

03 May '03

Hi, I have problems reading some mail with the latest version of dovecot. I use maildir etc but it all worked before... It seems like dovecot sends something that throws Evolution off the track since the actual information is sent, but in a broken form it seems. I also get some odd chars (this is raw tcp packet decoding): "ïêa-è "ïêc-è* FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. * 609 EXISTS * 0 RECENT * OK [UIDVALIDITY 1049995962] UIDs valid * OK [UIDNEXT 1044] Predicted next UID A10891 OK [READ-WRITE] Select completed. "ïêc-î "ïêc-î* 609 FETCH (UID 1043) A10892 OK Fetch completed. "ïêg-î* 498 FETCH (UID 646 BODY[] {3434} eturn-Path: <-----email-------> etc... Any clues? -- Ian Kumlien <pomac(a)vapor.com>

2 1

[dovecot] Corrupted index
by Mark E. Mallett 03 May '03

03 May '03

Hi- Still getting a bunch of these: Apr 30 13:45:23 mercury mem[11056]: pop3(user1): Corrupted index file /users/78/user1/Maildir/.INBOX/.imap.index: used_file_size larger than real file size (4032 vs 1608) and the occasional: Apr 30 13:08:53 mercury mem[13507]: pop3(user2): Corrupted index file (in-memory index for /users/e0/user2/Maildir): Filename mismatch for UID 1: 1051720748.28556.mercury.mv.net vs 1051715695.29601.mercury.mv.net Most of the time (but not always) the .imap* files are relatively old and apparently created by the test5 or older recent release. The errors persist in the logs until I manually remove the .imap* files, which are subsequently recreated upon the next access (without the error being logged, at least not right away). I had the impression that a "Corrupted index file" would cause the index files not to be used, and in fact recreated. Apparently not? If there is an error that causes the .imap* files to be ignored, shouldn't those files be removed? mm

2 1

[dovecot] Message causing pop3 crash
by Mark E. Mallett 03 May '03

03 May '03

Hi- Found a message that will generate a pop3 coredump when using mbox format. It seems to do with the fact that it has a mime part with a line that's 10,000 bytes long. However, that doesn't seem to be the only factor. Adjusting the size of the mail header seems to cause different kinds of crashes. I'll avoid attaching the message here but I've put it at http://www.mv.com/users/mem/x/badmail Reproducing it here on a BSD/OS system involves something like: (login to a virgin account or one you don't care about) % wget http://www.mv.com/users/mem/x/badmail % rm -rf .imap % MAIL=mbox:`pwd`/badmail % limit coredump 10m % /usr/local/libexec/dovecot/pop3 quit at which point you should get some errors and/or a coredump. You may need to do it twice (i.e. let it create the .imap/ index structure first). If you can't make it happen I can send along more info. -mm- (and yes, this was a real mail message, albeit a spam, except that I simplified it some and replaced all of the content with "x" characters)

2 1