- dovecot - dovecot.org

[Dovecot] dovecot-auth hangs with IO leak
by Alan Tam 16 Mar '05

16 Mar '05

Hi dovecot, I am using the debian dovecot packages on a system running LDAP. My /etc/pam.d/common-* looks like this, which simply means try /etc/passwd first, and try LDAP using the same password if it is failed. account [success=1 default=ignore] pam_unix.so account required pam_ldap.so use_first_pass account required pam_permit.so auth [success=1 default=ignore] pam_unix.so auth required pam_ldap.so use_first_pass auth required pam_permit.so session [success=1 default=ignore] pam_unix.so session required pam_ldap.so use_first_pass session required pam_mkhomedir.so skel=/etc/skel umask=0002 session required pam_permit.so When many LDAP users login, /var/log/auth.log shows many (expected) error like: (note "pam_unix") Feb 3 18:16:15 eta dovecot-auth: (pam_unix) authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=127.0.0.1 Feb 3 18:16:19 eta dovecot-auth: (pam_unix) check pass; user unknown After recent upgrades from probably 0.99.10 to 0.99.13, these lines begin to appear in /var/log/mail.log: Feb 3 16:31:00 eta dovecot-auth: Login process has too old (123s) requests, killing it. Feb 3 16:31:00 eta dovecot-auth: Login process has too old (124s) requests, killing it. And some more like this, which shows the problem: Feb 3 16:45:23 eta dovecot-auth: I/O leak: 0x8054940 (13) Feb 3 16:45:23 eta dovecot-auth: I/O leak: 0x8054940 (14) Feb 3 16:45:23 eta dovecot-auth: I/O leak: 0x8054940 (15) The problem can be solved by changing /etc/pam.d/dovecot to: auth required pam_ldap.so account required pam_ldap.so session required pam_mkhomedir.so skel=/etc/skel umask=0002 session required pam_ldap.so This change means PAM not fail auth for /etc/passwd again. I think dovecot has some problem dealing with the pam_unix + pam_ldap configuration. Do you have any idea? I am Cc-ing this message to the corresponding bug in Debian BTS. -- Regards, Alan

2 2

[Dovecot] Bit of a Newbie Question
by Jud 16 Mar '05

16 Mar '05

Apologies in advance - I'm sure there's something quite obvious I'm not doing correctly, but since I'm unable to resolve the problem myself.... I've installed Dovecot 99.14 on FreeBSD-CURRENT using the Dovecot FreeBSD port. My "network" consists of a cable modem connected to a router which is in turn connected (only) to my computer. My ISP assigns a dynamic IP address. I have ddclient set up to sync the dynamic IP to my hostname and MX via dyndns.org. Local operations (local delivery via Postfix or copying/moving/deleting with Thunderbird) work fine. Mail delivery from remote machines does not seem to work via either IMAP or IMAP-SSL. (That is, test e-mails I send from this [Fastmail] account to my local IMAP server never reach their destination.) Enabling port forwarding on my router for ports 993 and 143 has made no difference. What should I be doing to make this work correctly? Jud

5 7

[Dovecot] Strange behaviour with moving mail
by Remy Zandwijk 15 Mar '05

15 Mar '05

Hi All, Sorry to bother you again. I am not too familiar with IMAP yet, so maybe I am asking stupid questions. Here goes anyway: In our (Dovecot 1.0-stable) setup, we have two namespaces: the default namespace, which location is '/var/mailstore/1%u/%u' and the "Mailstorage" namespace, which location is '~/.Mailstorage/'. Now we create a folder called 'Test' in the default namespace and the "Mailstorage" namespace. As far as I know this is possible and not a strange thing to do. When moving an email from the first 'Test' folder to the other 'Test' folder, it appears that everything works like expected, but when refreshing the mailbox, the message is still in the original folder. This happens with a number of different mailclients (which are configured with an empty namespace setting). I guess Dovecot doesn't look at the namespace in which the mail folder is. Is this a Dovecot bug or is this normal behaviour? Best regards, Remy B.T.W: When moving the mail, this is the IMAP conversation: 00029 UID COPY 4 TEST * 2 EXISTS * 2 RECENT 00029 OK Copy completed. 00030 UID STORE 4 +Flags.silent (\Deleted) 00030 OK Store completed.

2 3

[Dovecot] Is it possible to regenerate the index files?
by Joakim Verona 15 Mar '05

15 Mar '05

Is it possible to regenerate the index files, on other conditions than the mbox file being read? For instance, it would be nice if I could regenerate the index for a specific mbox whenever procmail delivers mail to it. If theres no existing solution, would it be possible to make a small script with something like "nc" that could send an imap command to dovecot, so that dovecot would rebuild its index for that mbox? If so, which imap command triggers an index rebuild? -- Joakim Verona www.verona.se

2 5

[Dovecot] Visibility of .subscriptions and .customflags
by justin 15 Mar '05

15 Mar '05

Hi, I upgraded to test65 from 0.99 (mostly to get the namespace feature) and now it seems my .subscriptions and .customflags are showing up as mail folders in my IMAP client (Eudora). If I try and open those folders, of course I get an error. How can I configure dovecot so that these aren't displayed to my IMAP client? I looked through about 6 months of acrhives and couldn't find it mentioned anywhere. Thanks.

2 1

[Dovecot] logging
by F. Even 15 Mar '05

15 Mar '05

I'm curious about exactly what this means in my log: Mar 13 10:56:20 cerebus dovecot: imap-login: Disconnected [130.94.242.20] Mar 13 10:56:51 cerebus last message repeated 177 times Mar 13 10:57:32 cerebus last message repeated 179 times Now...does Dovecot ONLY log the names of users on successful attempts? Is this "Disconnected" log entry an indication someone ran a username/password attack against the imap server and failed to authenticate? If so, is there any way to make this a little more verbose, so I can perhaps see what names, etc. the annoying idiot is throwing against my server....? Thanks.

2 1

[Dovecot] (no subject)
by Gabriel Granger 15 Mar '05

15 Mar '05

Hi All, Bit the bullet last night and switched off UW-IMAP and turned on Dovecot. With any migration I've got some teething problems and hoping someone might be able to point me in the right direction. I tested the system using apple's Mail.app which worked fine, no problems at all, but it seems that most of my users are getting problems, i suspect Mail.app is hiding these messages from me. All my users are using ThunderBird 1.0 lastest stable release. Some messages in their IMAP folders are producing the following error. The current command did not succeed. The mail server responded: Error in IMAP command UID: Invalid BODY[_] parameter: Missing '>' in '<16384.-14781>'. it occurs on the same messages in the users email client but happens randomly, it does not stop you from viewing the message, its just pops up with this error. I'm current using IMAP over SSL and using mbox not maildir for IMAP Any ideas or hep would be great as I'd rather not have to roll back out to UW-IMAP Gabe

6 16

Re: [Dovecot] aha! (was apple mail vs. v0.99)
by sean finney 15 Mar '05

15 Mar '05

hey timo, On Tue, Mar 15, 2005 at 07:32:35PM +0200, dovecot-request(a)dovecot.org wrote: > From: Timo Sirainen <tss(a)iki.fi> > > i set: > > > > mailbox_check_interval = 0 > > This has been the default since 0.99.5 which was released over 2 years > ago. How old version are you using? :) Or had you changed the default? i had indeed changed the default, thinking that it would be a nice feature to turn on. when the problem first surfaced, i immediately thought of this option. however, since the problem was that applemail wasn't seing the new mail, and this was an option to notify the client that there *was* new mail, i guess common sense got the better of me and i forgot this was something i had changed... > > mailbox_idle_check_interval = 0 > > This shouldn't matter because OSX Mail doesn't use IDLE. Probably better > idea to turn it back on or clients using IDLE don't see new mails (I > think?) aha. well then i'll have to try turning that back on :) thanks, sean

1 0

[Dovecot] corrupted inboxes
by Josh Burley 15 Mar '05

15 Mar '05

Hi all, Two users on our system have recently had trouble reading their inbox, and it seems to be a result of their inbox getting corrupted. In the most recent case, their Mailbox file (in /home/eric/Mailbox in this case), has the following as the first line: cnw.igmg-- Here's a piece of the logs below... if you look for "eric", there's a successfully delivery, followed a bit later by a POP attempt by "eric" that returns that the Mailbox isn't in mbox format. Any ideas? .josh Mar 11 14:59:04 core postfix/local[8203]: 27D18279857E: to=<eric(a)kuci.org>, relay=local, delay=0, status=sent (delivered to mailbox) Mar 11 14:59:04 core postfix/qmgr[7238]: 27D18279857E: removed Mar 11 14:59:06 core postfix/smtpd[8199]: disconnect from user-0c8gg6h.cable.mindspring.com[24.136.64.209] Mar 11 14:59:13 core pop3-login: Login: gtt [::ffff:67.120.76.169] Mar 11 14:59:18 core postfix/smtpd[7575]: connect from webhost2.ethr.net[208.37.25.24] Mar 11 14:59:18 core postfix/smtpd[7575]: setting up TLS connection from webhost2.ethr.net[208.37.25.24] Mar 11 14:59:18 core postfix/smtpd[7575]: TLS connection established from webhost2.ethr.net[208.37.25.24]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Mar 11 14:59:18 core postfix/smtpd[7575]: 242E2279857E: client=webhost2.ethr.net[208.37.25.24] Mar 11 14:59:18 core postfix/cleanup[8201]: 242E2279857E: message-id=<bb165712392a2b4375d6da0efa3c046c(a)www.ethr.net> Mar 11 14:59:18 core postfix/qmgr[7238]: 242E2279857E: from=<nobody(a)webhost2.ethr.net>, size=1527, nrcpt=1 (queue active) Mar 11 14:59:18 core postfix/cleanup[8201]: 6F63A2798580: message-id=<bb165712392a2b4375d6da0efa3c046c(a)www.ethr.net> Mar 11 14:59:18 core postfix/local[8203]: 242E2279857E: to=<r-ethr(a)kuci.org>, relay=local, delay=0, status=sent (forwarded as 6F63A2798580) Mar 11 14:59:18 core postfix/qmgr[7238]: 6F63A2798580: from=<nobody(a)webhost2.ethr.net>, size=1653, nrcpt=1 (queue active) Mar 11 14:59:18 core postfix/smtpd[7575]: disconnect from webhost2.ethr.net[208.37.25.24] Mar 11 14:59:18 core postfix/qmgr[7238]: 242E2279857E: removed Mar 11 14:59:18 core postfix/smtp[8250]: setting up TLS connection to blade.butterzone.net Mar 11 14:59:18 core postfix/smtp[8250]: verify error:num=19:self signed certificate in certificate chain Mar 11 14:59:18 core postfix/smtp[8250]: Peer verification: CommonName in certificate does not match: tloin.butterzone.net != blade.butterzone.net Mar 11 14:59:18 core postfix/smtp[8250]: Peer certficate could not be verified Mar 11 14:59:18 core postfix/smtp[8250]: 6F63A2798580: to=<r(a)butterzone.net>, orig_to=<r-ethr(a)kuci.org>, relay=blade.butterzone.net[208.37.27.136], delay=0, status=sent (250 Ok: queued as 4783AC2C130) Mar 11 14:59:18 core postfix/qmgr[7238]: 6F63A2798580: removed Mar 11 14:59:23 core pop3(eric): File isn't in mbox format: /home/eric/Mailbox Mar 11 14:59:24 core pop3-login: Login: eric [::ffff:128.195.131.49] Mar 11 14:59:24 core pop3(eric): File isn't in mbox format: /home/eric/Mailbox Mar 11 14:59:24 core pop3(eric): File isn't in mbox format: /home/eric/Mailbox Mar 11 14:59:24 core pop3(eric): Couldn't open INBOX: Internal error occured. Refer to server log for more information. [2005-03-11 14:59:24] Mar 11 14:59:49 core pop3-login: Login: eric [::ffff:128.195.131.49] Mar 11 14:59:49 core pop3(eric): File isn't in mbox format: /home/eric/Mailbox Mar 11 14:59:49 core pop3(eric): File isn't in mbox format: /home/eric/Mailbox Mar 11 14:59:49 core pop3(eric): Couldn't open INBOX: Internal error occured. Refer to server log for more information. [2005-03-11 14:59:49] Mar 11 14:59:53 core imap-login: Login: jeanie [::ffff:128.195.131.2] Mar 11 14:59:58 core last message repeated 5 times

2 4

Re: [Dovecot] aha! (was apple mail vs. v0.99)
by sean finney 15 Mar '05

15 Mar '05

hello! On Mon, Mar 14, 2005 at 11:08:39PM +0200, dovecot-request(a)dovecot.org wrote: > From: "Dominik 'Rathann' Mierzejewski" <D.Mierzejewski(a)icm.edu.pl> > > According to RFC3501 (is this the right one?), NOOP can be used to check > for new mail, but it doesn't say that the server should return status > data every time NOOP is issued. i think the problem is that when the server asynchronously reports to the client that there's new mail apple mail gets confused. then noop doesn't report new mail. also, it seems that this is also the cause of apple mail having to re-download the entire mailbox every time it checks for new mail. > From: Timo Sirainen <tss(a)iki.fi> > > How did you disable them? I think enabling oe6-fetch-no-newmail > workaround should help. i set: mailbox_check_interval = 0 mailbox_idle_check_interval = 0 which did the trick (i already had all the client workarounds enabled). thanks, sean

3 2