Quoting a.smith@ukgrid.net:

Ok, I just deleted the dovecot index files etc from the mailbox,
when it recreated them all is now looking normal...

When I logged into my mail today this problem has come back :S Can
anyone suggest a cause or anything else I should do? I am correct in thinking that Dovecot normally orders emails by date right????

thanks Andy.

Quoting Timo Sirainen <tss@iki.fi>:

Have you checked if there are any errors in Dovecot logs? There are some reasons why Dovecot might give a new UID to an existing mail. dovecot -n output might also be useful.

Hi Timo,

thanks for the reply. I just checked and the file names are correct
for the mails to be ordered chronologically, so nothing weird going on
there that would cause a prob. I can't see any errors relating to this in the logs, but my logs a
several thousand lines per day so is there any particular error
message I should be looking for? A grep -i err doesn't show anything
interesting...

Here is a the output of dovecot -n:

dovecot -n

2.0.11: /usr/local/etc/dovecot/dovecot.conf

OS: FreeBSD 8.2-RELEASE amd64 zfs

auth_username_format = %Lu disable_plaintext_auth = no dotlock_use_excl = no first_valid_gid = 1000 first_valid_uid = 1000 lock_method = dotlock mail_fsync = always mail_location = maildir:/var/spool/mail/%d/%u mail_nfs_index = yes mail_nfs_storage = yes mail_privileged_group = vmail managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date mmap_disable = yes passdb { args = /usr/local/etc/dovecot/dovecot-sql.conf driver = sql } plugin/fts = squat plugin/fts_squat = partial=4 full=10 protocols = imap pop3 service auth { unix_listener auth-client { mode = 0660 } unix_listener auth-master { mode = 0600 } user = root } service imap { vsz_limit = 1 G } service pop3 { vsz_limit = 1 G } ssl_ca = </usr/local/etc/ssl.crt/ca-bundle.crt ssl_cert = </usr/local/etc/ssl.crt/pop3.crt ssl_key = </usr/local/etc/ssl.key/pop3.key userdb { args = /usr/local/etc/dovecot/dovecot-sql.conf driver = sql } protocol imap { imap_client_workarounds = delay-newmail tb-extra-mailbox-sep mail_plugins = fts fts_squat ssl = yes ssl_cert = </usr/local/etc/ssl.crt/imap.crt ssl_key = </usr/local/etc/ssl.key/imap.key } protocol pop3 { pop3_client_workarounds = outlook-no-nuls oe-ns-eoh pop3_uidl_format = %08Xu%08Xv ssl = yes ssl_cert = </usr/local/etc/ssl.crt/pop3.crt ssl_key = </usr/local/etc/ssl.key/pop3.key } protocol lda { sendmail_path = /usr/local/sbin/exim }

thanks Andy.

Quoting Timo Sirainen <tss@iki.fi>:

Try grepping for "Warning" also. I usually put error logs to a different file. That file should stay empty (except for Dovecot stop messages).

Hi, I don't have a dovecot log specified in the config, so I believe
everything goes to syslog which I think all ends up in either maillog
or messages. I don't see anything in there with "Warning".

...

mail_location = maildir:/var/spool/mail/%d/%u mail_nfs_index = yes mail_nfs_storage = yes

Are you using NFS? With just one server or more? What NFS server?

In this case, no I'm not using NFS. The server on which I'm seeing
this problem has the maildir data on a local ZFS file system. I have a
sort of poor mans cluster where I can run all the services on one of
two servers which may or may not use NFS, but as mentioned in this
instance there is no NFS to worry about.

thanks Andy.

Quoting Timo Sirainen <tss@iki.fi>:

You could try saving a backup of dovecot-uidlist periodically and when this happens again, see what exactly changed in the file.

Well actually I have hourly/weekly/monthly ZFS snapshots of all data
so I can do this now. Here I can see that the UID changed between week
13 and 14 of 2011:

./.zfs/snapshot/WEEK13_2011/ukgrid.net/a.smith/dovecot-uidlist:1815
W5772 S5627 :1238145250.H86871P67126.mx1.ukgrid.net:2,RS ./.zfs/snapshot/WEEK14_2011/ukgrid.net/a.smith/dovecot-uidlist:40723
W5772 :1238145250.H86871P67126.mx1.ukgrid.net

I believe this was due to an upgrade from Dovecot 1.2 to 2.0. Its the
only change I can see of the UID in 2011 apart from when I deleted the
dovecot-uidlist last Thursday. The incorrect ordering could have been
occuring since the upgrade to 2.0 but I just didn't notice it. I was
particularly worried about it as we have a long time issue with
blackberry users being resent large chunks of email and I was
wondering if this was the cause...

The issue did reoccur after deleting the dovecot-uidlist last Friday,
in that I had very old messages being listed in the top hundred or so
emails. Unfortunately I didn't make a note of the which messages these
were and all seems to be being listed correctly currently. I am now armed with the knowledge to investigate this if it happens again.

One last thing, you asked previously if I used NFS and I said that in
this case I wasn't. We do have NFS and we do want to use it under some
circumstances with Dovecot, both server and client are FreeBSD 8.2,
are there any known issues with that in conjunction with Dovecot?

thanks Andy.

On 2011-05-17 10:51 AM, Timo Sirainen wrote:

On 17.5.2011, at 13.55, a.smith@ukgrid.net wrote:

...

One last thing, you asked previously if I used NFS and I said that in this case I wasn't. We do have NFS and we do want to use it under some circumstances with Dovecot, both server and client are FreeBSD 8.2, are there any known issues with that in conjunction with Dovecot?

As long as a user's mails are accessed simultaneously by more than 1 server, it works fine. If you use more than one server, you can use http://wiki2.dovecot.org/Director to implement this easily.

I'm almost certain Timo meant to say, 'As long as any 1 users emails are NOT accessed simultaneously by more than 1 server, it works fine.'

The NFS problems happen when more than one server accesses the same users mailstore simultaneously.

At least, I hope I understand this issue correctly...

--

Best regards,

Charles