version: 1.0.2 imap_client_workarounds = outlook-idle And I've no problem with OE 6.0. I've been testing with imap since I read your first post, and there have not been any disconnections.

I don't know about OE2003.

/Bachman Sergey A. Kobzar skrev:

Hi Jeff,

Did you try play with imap_client_workarounds options?

I think this must help you:

outlook-idle: Outlook and Outlook Express never abort IDLE command, so if no mail arrives in half a hour, Dovecot closes the connection. This is still fine, except Outlook doesn't connect back so you don't see if new mail arrives.

Wednesday, August 1, 2007, 3:12:17 AM, you wrote:

...

I have been using Dovecot for an IMAP server for a few years now,
with no hitch. Even using Outlook 2K/2K3 as a client.

...

Yesterday, I had a user experience the 'Negative UIDs' issue spoken
of here: http://wiki.dovecot.org/Clients/NegativeUIDs

...

I performed all of the steps mentioned in this article, and it seemed like it would work properly the first time the user checked their
email, and then after that, they would get this error again.

...

I checked to see what the latest stable version of Dovecot was, and
decided to upgrade. I was at 0.99.11-8 and the latest stable rpm for
my distro was 1.0.2-2.

...

The upgrade went fine. Or so I thought.

...

I am now getting the following message on all Outlook Clients:

...

"Your IMAP Server closed the connection....this can occur if the
connection is idle for too long"

...

I have scoured the Internet for this error and have come up with many suggestions, none of which have worked. I have increased Outlook's
timeout period to the full 10 minutes, and I have disabled SELinux.
None of this seems to have worked.

...

Is there anyone out there who has actually had this issue and
resolved it? Can you please help?

...

Thanks,

...

Jeff Ramsey MIS Administrator TMI Forest Products, Inc. jefframsey@tubafor.com 360.477.0738

On Aug 1, 2007, at 2:26 AM, Timo Sirainen wrote:

On Tue, 2007-07-31 at 17:12 -0700, Jeff Ramsey wrote:

...

I am now getting the following message on all Outlook Clients:

"Your IMAP Server closed the connection....this can occur if the connection is idle for too long"

What does Dovecot show in logs as the disconnect reason?

This sounds like the IDLE problem that outlook-idle workaround avoids, but that's the default so I'd think you haven't disabled it.

I've got the outlook-idle workaround turned on. I am using this line
in the /etc/dovecot.conf:

imap_client_workarounds = outlook-idle

Dovecot does not show any reason for the disconnect. It just shows
that the user logged out:

Aug 1 08:09:44 imap dovecot: imap-login: Login: user=<jefframsey>,
method=PLAIN, rip=::ffff:10.11.254.52, lip=::ffff:65.174.242.66 Aug 1 08:09:44 imap dovecot: IMAP(jefframsey): Disconnected: Logged out Aug 1 08:10:06 imap dovecot: imap-login: Login: user=<geoff>,
method=PLAIN, rip=::ffff:10.10.254.148, lip=::ffff:65.174.242.66 Aug 1 08:10:13 imap dovecot: imap-login: Login: user=<QUINAULT- donnaanderson>, method=PLAIN, rip=::ffff:10.200.254.121, lip=::ffff: 65.174.242.66 Aug 1 08:10:13 imap dovecot: imap-login: Login: user=<QUINAULT- donnaanderson>, method=PLAIN, rip=::ffff:10.200.254.121, lip=::ffff: 65.174.242.66 Aug 1 08:10:52 imap dovecot: IMAP(QUINAULT-donnaanderson):
Disconnected: Logged out Aug 1 08:10:52 imap dovecot: IMAP(QUINAULT-donnaanderson):
Disconnected: Logged out

I have read that this means that the client was the one that
disconnected, but that does not make sense, because with 0.99.x, I
did not have this issue. And I did not change anything in my Outlook
clients. All I have changed is upgrading Dovecot.

Since my initial post, I have noticed this in my log file as well:

Aug 1 08:13:42 imap dovecot: auth(default): userdb(johnfowler,::ffff: 65.174.242.248): user not found from userdb Aug 1 08:13:42 imap dovecot: imap-login: Internal login failure:
user=<johnfowler>, method=PLAIN, rip=::ffff:65.174.242.248,
lip=::ffff:65.174.242.66 Aug 1 08:13:50 imap dovecot: imap-login: Login: user=<johnfowler>,
method=PLAIN, rip=::ffff:65.174.242.248, lip=::ffff:65.174.242.66

This does not happen all of the time when a person logs in, in fact I
have not heard of a single person having a login failure, or at least
nobody has told me they got a message about an improper login or
failed password or anything like that so far. The one thing I can
think of is maybe the authentication methods have changed for Dovecot
from 0.99.x to 1.0.2. I use Winbind to authenticate my Active
Directory users to my linux boxen for all of their services, and
Dovecot is no exception. Maybe something has changed in the /etc/ pam.d folder. I have not heard of anyone having any authentication
errors at this point, however, my own computer, which uses Mac Mail
2.1.1 as a client, has in fact been throwing these errors this
morning, a couple of times an hour:

The server error encountered was: The user name and password
specified in Mail preferences were not accepted by the server.

So far, I have not had any error about username and/or password from
any of my Outlook users, just this one Mac client. As soon as I click
on 'Go Online' at the error screen, the error goes away, and
everything is fine for a 5 to 10 minutes, then I'll see it again. And
no, it does not happen every time my client syncs folders to IMAP.
More like one out of 10 times, and really random.

Has anything changed in the way that Dovecot handles authentication
that may be causing this issue? The way that (I think) PAM handles
authentication from Winbind is first it tries local accounts, and
then if they fail, it tries Winbind, so if the local username is not
found, it could explain why it is giving this error:

Aug 1 08:13:42 imap dovecot: auth(default): userdb(johnfowler,::ffff: 65.174.242.248): user not found from userdb Aug 1 08:13:42 imap dovecot: imap-login: Internal login failure:
user=<johnfowler>, method=PLAIN, rip=::ffff:65.174.242.248,
lip=::ffff:65.174.242.66

Then, when Winbind auth is tried, the authentication succeeds, and I
get:

Aug 1 08:13:50 imap dovecot: imap-login: Login: user=<johnfowler>,
method=PLAIN, rip=::ffff:65.174.242.248, lip=::ffff:65.174.242.66

So, I can see that the Winbind auth is working, but perhaps Dovecot
is sending the client an auth failed after the local auth fails and
before the Winbind auth succeeds.

Thanks for the suggestions so far, unfortunately I've already tried
the outlook-idle workaround. Maybe I should just downgrade to 0.99.x
again. Are there any known issues with a downgrade?

Jeff Ramsey MIS Administrator TMI Forest Products, Inc. jefframsey@tubafor.com 360.477.0738

-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

On Aug 1, 2007, at 9:47 AM, Timo Sirainen wrote:

On 1.8.2007, at 18.43, Jeff Ramsey wrote:

...

Since my initial post, I have noticed this in my log file as well:

Aug 1 08:13:42 imap dovecot: auth(default): userdb (johnfowler,::ffff:65.174.242.248): user not found from userdb Aug 1 08:13:42 imap dovecot: imap-login: Internal login failure:
user=<johnfowler>, method=PLAIN, rip=::ffff:65.174.242.248,
lip=::ffff:65.174.242.66

I suppose this is the problem then. Outlook stupidly keeps
reconnecting to server all the time, so if one reconnection fails I
guess this problem happens.

So this "johnfowler" really should exist in your userdb? You could
set auth_debug=yes and then see what is logged before that error.
Also could you post your dovecot -n output?

Output of dovecot -n:

# 1.0.2: /etc/dovecot.conf login_dir: /var/run/dovecot/login login_executable(default): /usr/libexec/dovecot/imap-login login_executable(imap): /usr/libexec/dovecot/imap-login login_executable(pop3): /usr/libexec/dovecot/pop3-login mail_executable(default): /usr/libexec/dovecot/imap mail_executable(imap): /usr/libexec/dovecot/imap mail_executable(pop3): /usr/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/lib/dovecot/imap mail_plugin_dir(imap): /usr/lib/dovecot/imap mail_plugin_dir(pop3): /usr/lib/dovecot/pop3 auth default: passdb: driver: pam userdb: driver: passwd

And yes, issuing a 'getent passwd' command shows all of my users from
the /etc/passwd file, and then all of the Active Directory users,
including johnfowler.

I set auth_debug = yes. Here is an example to compare to the previous
one with johnfowler, this one with QUINAULT-ileneyoung as the
username; (QUINAULT is a trusted Active Directory domain, so I have
to prefix the username with the DOMAIN for this user.)

Aug 1 11:58:47 imap dovecot: auth(default): pam(QUINAULT- ileneyoung,::ffff:10.200.254.110): lookup service=dovecot Aug 1 11:58:47 imap dovecot: auth(default): client out: OK
1 user=QUINAULT-ileneyoung Aug 1 11:58:47 imap dovecot: auth(default): master in: REQUEST
3 12173 1 Aug 1 11:58:47 imap dovecot: auth(default): passwd(QUINAULT- ileneyoung,::ffff:10.200.254.110): lookup Aug 1 11:58:47 imap dovecot: auth(default): master out: USER
3 QUINAULT-ileneyoung system_user=QUINAULT-ileneyoung
uid=16777352 gid=16777248 home=/home/QUINAULT/ileneyoung Aug 1 11:58:47 imap dovecot: imap-login: Login: user=<QUINAULT- ileneyoung>, method=PLAIN, rip=::ffff:10.200.254.110, lip=::ffff: 65.174.242.66 Aug 1 11:58:51 imap dovecot: auth(default): client in: AUTH
1 PLAIN service=IMAP lip=::ffff:65.174.242.66
rip=::ffff:10.200.254.110 resp=<hidden> Aug 1 11:58:51 imap dovecot: auth(default): pam(QUINAULT- ileneyoung,::ffff:10.200.254.110): lookup service=dovecot Aug 1 11:58:51 imap dovecot: auth(default): client out: OK
1 user=QUINAULT-ileneyoung Aug 1 11:58:51 imap dovecot: auth(default): master in: REQUEST
4 12186 1 Aug 1 11:58:51 imap dovecot: auth(default): passwd(QUINAULT- ileneyoung,::ffff:10.200.254.110): lookup Aug 1 11:58:51 imap dovecot: auth(default): passwd(QUINAULT- ileneyoung,::ffff:10.200.254.110): unknown user Aug 1 11:58:51 imap dovecot: auth(default): userdb(QUINAULT- ileneyoung,::ffff:10.200.254.110): user not found from userdb Aug 1 11:58:51 imap dovecot: auth(default): master out:
NOTFOUND 4 Aug 1 11:58:51 imap dovecot: imap-login: Internal login failure:
user=<QUINAULT-ileneyoung>, method=PLAIN, rip=::ffff:10.200.254.110,
lip=::ffff:65.174.242.66 Aug 1 11:59:06 imap dovecot: auth(default): client in: AUTH
1 PLAIN service=IMAP lip=::ffff:65.174.242.66
rip=::ffff:65.174.242.239 resp=<hidden>

Perhaps this sheds some light on the matter? Why is it trying to
authenticate the user again at 11:58:51 when there was no disconnect
after 11:58:47? And why is it failing? My guess on why it is failing
is because the Active Directory Server cannot respond fast enough to
handle the second request, after already handling the first, but I am
just guessing.

Thanks,

Jeff Ramsey MIS Administrator TMI Forest Products, Inc. jefframsey@tubafor.com 360.477.0738

-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

On Aug 1, 2007, at 12:10 PM, Timo Sirainen wrote:

I think the problem has to do with NSS. It probably failed with some error, but since unfortunately getpwnam() interface doesn't support reporting errors, Dovecot just assumed that the user didn't exist.

I can't think of why this would work any differently with Dovecot v0.99.x.

I think you should rather get rid of userdb passwd and configure
Dovecot to use userdb ldap to connect directly to your AD.

Using / not using nscd might also help.

I think going to userdb ldap may be a great long term solution,
however I'll need to setup an offline computer to configure and test
it on before I could run it live.

Is there any way that I can just downgrade back to 0.99.x to see if
this issue is in fact caused by a difference between the two
versions? Will downgrading cause any known issues? If I could just
get this working like it was before the upgrade to 1.0.2-2, I'd have
enough time to setup and test userdb ldap.

Jeff Ramsey MIS Administrator TMI Forest Products, Inc. jefframsey@tubafor.com 360.477.0738

-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

On Thu, 2007-08-02 at 12:50 -0700, Jeff Ramsey wrote:

On Aug 1, 2007, at 12:10 PM, Timo Sirainen wrote:

...

...

Aug 1 11:58:51 imap dovecot: auth(default): passwd(QUINAULT- ileneyoung,::ffff:10.200.254.110): lookup Aug 1 11:58:51 imap dovecot: auth(default): passwd(QUINAULT- ileneyoung,::ffff:10.200.254.110): unknown user .. I did the downgrade back to 0.99.11-8.EL4, which I realize is not

On Wed, 2007-08-01 at 12:05 -0700, Jeff Ramsey wrote: truly 0.99.x, it's got some 1.0.? updates inserted from Red Hat.

Anyhow, I did not get anymore messages about 'user unknown'
immediately after the downgrade. However, I was still getting a few
'IMAP Server disconnected' errors in my Outlook clients. So, on a
hunch I ran a diff command between the default 0.99.11-8.EL4 conf
file and my old, known working 0.99.11-8.EL4 conf file, restored from
a backup, and I noticed that even though I was not using the POP3
protocol at all, I still have the outlook-pop3-no-nuls and the oe6- fetch-no-newmail workarounds enabled, along with the outlook-idle
workaround. So, I added those two workarounds to the default config,
and it is working again. No 'IMAP Server disconnected' errors all day
long.

In 0.99.11-8.EL4, could this outlook-pop3-no-nuls be solving this
issue, even though I am using IMAP protocol, not POP3?

No, that setting doesn't do anything for IMAP. Also none of those settings affect the "unknown user" error, so maybe 0.99 is somehow lucky in not generating those. Perhaps setting blocking=yes to userdb passwd args would help.

Since in 1.0.2, the workarounds are on a separate conf line for POP3
and IMAP, is there an equivalent workaround for Outlook with IMAP?
The wiki mentions a workaround called 'outlook-no-nuls'. Will that
one work with 1.0.2 under the IMAP workarounds line? And am I being
realistic that this may be my issue?

The outlook-no-nuls only fixes Outlook completely hanging in case it receives a NUL byte with POP3 protocol. There's no such problem with IMAP.

On Thu, 2007-08-09 at 11:01 -0700, Jeff Ramsey wrote:

...

No, that setting doesn't do anything for IMAP. Also none of those settings affect the "unknown user" error, so maybe 0.99 is somehow
lucky in not generating those. Perhaps setting blocking=yes to userdb passwd args would help.

Perhaps dovecot communicates with PAM in a different way from 0.99 to
1.0.2? I don't know how else to explain it. Literally, the only time
I've gotten a report of Outlook's 'IMAP server disconnected' message
since the downgrade is when a user who was on a remote VPN connection
left Outlook open and let his computer go into hibernation for like
an hour. I'd expect dovecot to close that connection in that instance.

So you're using PAM + nss_ldap. I guess that can easily be the problem. http://wiki.dovecot.org/AuthDatabase/Passwd