[Dovecot] POP users complaining about multiple copies of mail
Hello,
We just switched from UW to Dovecot for our mail server. The transition went smoothly, except we have some users complaining about their email clients re-downloading mail or getting multiple copies of emails. When we go into their accounts, we only see one copy of the email, so I'm assuming there's something odd in the communication between their client and us that's causing the mail to get downloaded repeatedly.
The clients that we've heard about are Outlook and one called "Goldmine".
Has anyone run across this before? Scanning the archives didn't show me anything. This is Dovecot 1.2.12-1ubuntu8 on Ubuntu 10.10. Here's my config:
# 1.2.12: /etc/dovecot/dovecot.conf # OS: Linux 2.6.35.4-rscloud x86_64 Ubuntu 10.10 log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap imaps pop3 pop3s managesieve ssl_ca_file: /etc/ssl/certs/ca.pem ssl_cert_file: /etc/ssl/certs/wildcard.skiltech.com.pem ssl_key_file: /etc/ssl/private/wildcard.skiltech.com.key disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login login_executable(managesieve): /usr/lib/dovecot/managesieve-login mail_privileged_group: mail mbox_write_locks: fcntl dotlock mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_executable(managesieve): /usr/lib/dovecot/managesieve mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 mail_plugin_dir(managesieve): /usr/lib/dovecot/modules/managesieve imap_client_workarounds(default): outlook-idle delay-newmail imap_client_workarounds(imap): outlook-idle delay-newmail imap_client_workarounds(pop3): imap_client_workarounds(managesieve): pop3_enable_last(default): no pop3_enable_last(imap): no pop3_enable_last(pop3): yes pop3_enable_last(managesieve): no pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh pop3_client_workarounds(managesieve): lda: postmaster_address: postmaster mail_plugins: sieve quota_full_tempfail: yes deliver_log_format: msgid=%m: %$ rejection_reason: Your message to <%t> was automatically rejected:%n%r auth default: mechanisms: plain login passdb: driver: pam userdb: driver: passwd socket: type: listen client: path: /var/spool/postfix/private/dovecot-auth mode: 432 user: postfix group: postfix plugin: sieve: ~/.dovecot.sieve sieve_dir: ~/sieve
On Tue, 2010-11-16 at 12:33 -0500, H. Wade Minter wrote:
The clients that we've heard about are Outlook and one called "Goldmine".
Has anyone run across this before? Scanning the archives didn't show me anything.
I've heard it several times, and it's always been Outlook. It just seems to go nuts when server changes. No one who has complained about this has ever come back to say if they managed to fix it somehow.
My guess: recreate the account in Outlook and hope for best.
On Tue, 2010-11-16 at 17:40 +0000, Timo Sirainen wrote:
I've heard it several times, and it's always been Outlook. It just seems to go nuts when server changes. No one who has complained about this has ever come back to say if they managed to fix it somehow.
My guess: recreate the account in Outlook and hope for best.
Oh, the other possibility of course: You seem to be using mbox format? If the message's IMAP UIDs change, the POP3 UIDL changes and the messages get redownloaded.
You should at least explicitly set mail_location setting so Dovecot doesn't use autodetection. Also look for Dovecot errors in log file.
On Nov 16, 2010, at 12:43 PM, Timo Sirainen wrote:
On Tue, 2010-11-16 at 17:40 +0000, Timo Sirainen wrote:
I've heard it several times, and it's always been Outlook. It just seems to go nuts when server changes. No one who has complained about this has ever come back to say if they managed to fix it somehow.
My guess: recreate the account in Outlook and hope for best.
Oh, the other possibility of course: You seem to be using mbox format? If the message's IMAP UIDs change, the POP3 UIDL changes and the messages get redownloaded.
You should at least explicitly set mail_location setting so Dovecot doesn't use autodetection. Also look for Dovecot errors in log file.
I've just gone in and set mail_location
root@bunning:~# dovecot -n | grep mail_loc mail_location: maildir:~/Maildir
Is there anything I need to do about the mbox/UIDL issue? Config variables to tweak?
--Wade
On Tue, 2010-11-16 at 12:47 -0500, H. Wade Minter wrote:
I've just gone in and set mail_location
root@bunning:~# dovecot -n | grep mail_loc mail_location: maildir:~/Maildir
What, you're using maildir after all? Then you should remove this setting:
mail_privileged_group = mail
Is there anything I need to do about the mbox/UIDL issue? Config variables to tweak?
If you're using Maildir, there's almost no chance of UIDLs changing. You could of course manually log in and check:
telnet localhost 110 user foo pass bar uidl
Save the output -> look at it again after user redownloaded mails -> compare the output to see if it had changed (besides the intentional message deletions and new messages).
On Nov 16, 2010, at 12:57 PM, Timo Sirainen wrote:
On Tue, 2010-11-16 at 12:47 -0500, H. Wade Minter wrote:
I've just gone in and set mail_location
root@bunning:~# dovecot -n | grep mail_loc mail_location: maildir:~/Maildir
What, you're using maildir after all? Then you should remove this setting:
mail_privileged_group = mail
Is there anything I need to do about the mbox/UIDL issue? Config variables to tweak?
If you're using Maildir, there's almost no chance of UIDLs changing. You could of course manually log in and check:
telnet localhost 110 user foo pass bar uidl
Save the output -> look at it again after user redownloaded mails -> compare the output to see if it had changed (besides the intentional message deletions and new messages).
Yes, I'm using Maildir, sorry. I've removed that mail_privileged_group setting (I think I had it set when I was testing some migration FROM mbox).
The UIDL seems to be staying the same, so maybe the answer is having them delete/recreate their Outlook POP accounts?
participants (2)
-
H. Wade Minter
-
Timo Sirainen