April 2008 - dovecot - dovecot.org

[Dovecot] deliver: handling of quota_full_tempfail and -e
by Ulrich Zehl 04 May '08

04 May '08

Hi, while testing out dovecot 1.1, I found that when you set quota_full_tempfail = yes in dovecot.conf and use the deliver -e command line flag, no deferral reason is printed, thus breaking my fancy quota_exceeded_message. This appears to be because of the if() block in lines 1003-1009 in src/deliver/deliver.c, and should be easily fixable (if it is indeed a bug, and not intended behavior). However, I shied away from creating a patch because either there is a mismatch between the documentation and deliver's actual behavior, or I misunderstood the code (likely, since I'm not really a C programmer). The lines in question (in src/deliver/deliver.c) read: | 1003 if (error != MAIL_ERROR_NOSPACE || | 1004 getenv("QUOTA_FULL_TEMPFAIL") != NULL) { Does this mean that the corresponding block gets executed whenever quota_full_tempfail is set? If so, setting it transforms all errors into TEMPFAILs, and not only those relating to quota/space issues. I think dovecot-example.conf should at least mention this it's inteded; otherwise, the code should be changed (I'm not completely sure what Timo's intensions are, so I won't comment on possible solutions). Regards, Ulrich PS: All line numbers are taken from rev 080dd4d2fd94, which was the most recent at the time of writing.

4 3

[Dovecot] Replication protocol design
by Timo Sirainen 03 May '08

03 May '08

I'll probably be implementing multi-master replication this summer. My previous thoughts about it are here: http://dovecot.org/list/dovecot/2007-December/027284.html Below is a description of how the replication protocol will probably work. It should work just as well for master-slave and multi-master setups. Comments welcome. I'll write later a separate mail about how it'll be implemented to Dovecot. Goals ----- 1. If a single (or configurable number of) server dies, no mails must be lost that have been reported to IMAP/SMTP clients as being successfully stored. 2. Must be able to automatically recover from a server desynchronization, such as: - server has been offline for a long time - some mail files have been manually added/deleted - corrupted data/mail files if they're noticed 3. In multi-master setup if the link between servers die, the servers must be able to proceed autonomously (kind of conflicts with goal 1 though). When the link comes back, the changes are replicated as soon as possible. 4. Normal IMAP commands must not be able to cause desynchronization between servers. For example making conflicting flag changes simultaneously in two servers must not result in the servers having different flags. 5. Must perform well with at least 3 servers in a multi-master setup, preferrably still with tens of servers. 6. Latency shouldn't be increased noticeably when using servers distributed into 3 or more data centers. Must be usable over high-latency links (in optimistic async mode). 7. In normal operation send minimal incremental changes. Protocol -------- There are two major parts in the protocol: Handling the normal incremental changes and fixing desynchronization. Originally I thought that maybe the changes could be sent using the same format as Dovecot's transaction logs, but now I'm beginning to think that it's probably not that good idea. The code reuse potential is quite minimal and the format would still have to be extended in several ways so that it won't be directly compatible anyway. So I'm thinking the protocol could be something text-based. The main benefit is that text-based protocols are easier to debug. Stream compression should drop most of the extra overhead if bandwidth is a problem. The exact on-wire protocol anyway doesn't matter in the design that's discussed below. The commands have tags similar to IMAP commands, because some commands may have to be forwarded to other servers and it may take a while to get a reply. During the wait the server may process other commands. Mailbox master -------------- Each mailbox has a single master server selected. In multi-master setups the master server may be moved by having the destination server simply request it from the current master. The current master must then give it up. If link is lost to the current master, one of the remaining servers will become the new master within the remaining servers. Each server must be connected to the current master server. Since each mailbox can have a different master server, this typically means all servers are connected to each others. However it's possible to create setups where server connects to only one other server, which in turn connect to more servers. This is useful if there are bandwidth bottlenecks between some servers. This kind of a situation can also happen if in a network A-B-C the link A-C dies, but A-B and B-C continues to work. Because of this all commands must be able to function in a way that the server proxies them to the current master, instead of failing the command and trying to make it the caller's problem to resend the command to the actual master. When the cluster starts up, a single server is selected as the root master for all mailboxes. If a server doesn't know who the current mailbox master is, it asks from the root. All servers cache the currently known mailbox masters to avoid constant requests to the root. If the root server dies, another server is selected as the root. Because the new root doesn't know what masters have been requested (and asking all of them from all servers would just waste bandwidth), all the servers are expected to flush their master caches and drop their own master status. The new root doesn't respond to any requests before all servers have notified that they've dropped being a master. The master status doesn't have to be at mailbox level granularity. It could just as well be configured to move at user, domain or even global level. Perhaps this could be done dynamically, so that higher granularity is used when the master is beginning to change too often between servers. Mailbox ID ---------- Mailbox IDs are session-specific numbers dynamically assigned for user+mailbox+UIDVALIDITY combinations. All connections have different mailbox IDs. Also send and receive directions have different IDs. This allows the sender to easily replace existing IDs to point to new mailboxes without causing any confusion. MBOX: - Mailbox ID - User name - Mailbox name - Mailbox UIDVALIDITY - Mailbox UIDNEXT - Mailbox message count If the receiver finds out it has a different UIDVALIDITY, the mailbox requires a full resync. Message count and UIDNEXT may also be used to determine if replication servers are out of sync. Requesting master status ------------------------ MASTER-MOVE: - Mailbox ID - [Destination SID] (if forwarding) The command is sent to the last known master for the mailbox. The server will keep forwarding the command until it reaches the current master. During the forwarding other servers may want to request something from the master. These requests must be delayed by the forwarding servers until the move is finished. Saving messages --------------- SAVE: - Mailbox IDs - Received date - [IMAP UID] (only if we're the master) - Global UID (stays the same when copying the message) - Message text Reply: - [IMAP UID] (only if not specified in parameters) - [Current mailbox master SID] (if it was moved) If current server is not the master, the SAVE is sent to the master which gives the message its UID. The master server then replicates the message to other servers with the UID parameter set. The mailbox master may have already changed by the time server receives a save request. If server receives a SAVE without IMAP UID parameter, it's responsible for finding out the new mailbox master and sending a new SAVE request to it. Once the new master replies with the IMAP UID, the server can reply to the original SAVE request, also providing the new master SID so the future requests can be sent there directly. To be sure the message doesn't get lost, the server should not reply OK to the IMAP/SMTP client until it has received a reply from SAVE. Copying messages ---------------- COPY: - Source mailbox ID - Destination mailbox ID - Source IMAP UID - Global UID - [Destination IMAP UID] (only if we're the master) - Destination received date Reply: - [Destination IMAP UID] (only if not specified in parameters) - [Current mailbox master SID] (if it was moved) Source mailbox ID + source IMAP UID identifies the message to be copied. It's expected to contain the given global UID (which is just an extra sanity check). Otherwise it works the same way as SAVE. Since the message already exists, it's probably not necessary to wait for a reply before replying OK to originating IMAP client. Expunging messages ------------------ EXPUNGE: - Mailbox ID - UID range (No reply) Expunges also have to be sent via master server (the same way as SAVE) to avoid COPY command failing in some servers because it was just expunged. Changing message flags ---------------------- STORE: - Mailbox ID - UID range - Added flags/keywords - Removed flags/keywords - [Current modseq] (master sends) - [Highest modseq of the messages before this change] (non-master sends) - [flag: this is a CONDSTORE STORE UNCHANGEDSINCE] (non-master may send) [Reply: - UIDs where STORE was rejected to (if CONDSTORE flag was used) ] Stores also have to be sent via master server to avoid flag desynchronization. Master first checks if it has higher modseqs in the messages. Then it applies all the changes and forwards the changes to other servers. For messages that had higher initial modseqs their flags are sent to the server sending the STORE to fix a potential desync. If CONDSTORE flag is set, the change is rejected for messages that had a higher modseq. Non-masters shouldn't reply to a STORE UNCHANGEDSINCE command before the change has been replicated to master and the rejections have been processed. Mailbox synchronization ----------------------- If a mailbox is determined to have changed externally (e.g. network connection down for too long, causing replication logs to get full) the mailbox state needs to be synchronized between servers. SYNC: - UIDVALIDITY - UIDNEXT - Message count - For each message: - UID - Global UID - Modseq - Flags and keywords - Received date Reply: - (Sync finished) Receiving server compares the parameters with its own mailbox state. If it finds previously unseen global UIDs, their message texts are requested: FETCH: - Mailbox ID - UID Reply: - Message text SAVE, EXPUNGE and STORE commands are used to synchronize the mailbox. A special case is when two servers have been saving messages independently from each others. In this case it's possible that the servers have used the same UIDs for different messages (different global UIDs). These need to be resolved by giving both conflicting UIDs new unused UIDs, otherwise IMAP clients may show them as wrong messages from their caches. FIXME: If the other server had expunged a conflicting UID it still should be given a new UID. How do we find out this has happened?

4 13

[Dovecot] [RFC] FreeBSD port for dovecot 1.1 series
by Xin LI 02 May '08

02 May '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have put together a preliminary patchset for dovecot 1.1 at: http://people.freebsd.org/~delphij/misc/dovecot-1.1-rc4.diff My intention is to repocopy the current dovecot port to dovecot11 and make changes on the latter. In this version of patchset, I have intentionally removed the following chunk of change which by default allows gid=0 users to log in. %%% @@ -333,6 +338,7 @@ ~ # belongs to supplementary groups with non-valid GIDs, those groups are ~ # not set. ~ #first_valid_gid = 1 +first_valid_gid = 0 ~ #last_valid_gid = 0 ~ # Maximum number of running mail processes. When this limit is reached, %%% Please let me know if you want more features, have comments, etc., for the FreeBSD port. I am subscribed to this list but I would appreciate if you could use 'Reply all' which will give me more opportunity to get your e-mail from the thousands I receive :) Cheers, - -- Xin LI <delphij(a)delphij.net> http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgY420ACgkQi+vbBBjt66CKNACfdGlItaGCo88W4ZdlLjkZ+Dlb ug8AoJkp9z9nMzwU3K/LLpzOKwD2KDXK =UzzN -----END PGP SIGNATURE-----

3 2

[Dovecot] new auth connection (for ever)
by Evaggelos Balaskas 02 May '08

02 May '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everybody, I have a little problem, when i am trying to read an email via imap my thunderbird is trying (for ever) to read it. My dovecot tells me : dovecot: Apr 29 22:47:23 Error: IMAP(ebalaskas): FETCH for mailbox oreilly UID 24 got too little data: 2041 vs 2471 dovecot: Apr 29 22:47:24 Error: IMAP(ebalaskas): FETCH for mailbox oreilly UID 24 got too little data: 2041 vs 2471 dovecot: Apr 29 22:47:24 Error: IMAP(ebalaskas): FETCH for mailbox oreilly UID 24 got too little data: 2041 vs 2471 dovecot: Apr 29 22:47:25 Error: IMAP(ebalaskas): FETCH for mailbox oreilly UID 24 got too little data: 2041 vs 2471 dovecot: Apr 29 22:47:25 Error: IMAP(ebalaskas): FETCH for mailbox oreilly UID 24 got too little data: 2041 vs 2471 dovecot: Apr 29 22:47:25 Error: IMAP(ebalaskas): FETCH for mailbox oreilly UID 24 got too little data: 2041 vs 2471 dovecot: Apr 29 22:47:26 Error: IMAP(ebalaskas): FETCH for mailbox oreilly UID 24 got too little data: 2041 vs 2471 dovecot: Apr 29 22:47:26 Error: IMAP(ebalaskas): FETCH for mailbox oreilly UID 24 got too little data: 2041 vs 2471 dovecot: Apr 29 22:47:27 Error: IMAP(ebalaskas): FETCH for mailbox oreilly UID 24 got too little data: 2041 vs 2471 dovecot: Apr 29 22:47:27 Error: IMAP(ebalaskas): FETCH for mailbox oreilly UID 24 got too little data: 2041 vs 2471 ... dovecot: Apr 29 22:47:27 Info: IMAP(ebalaskas): Disconnected: Disconnected dovecot: Apr 29 22:47:27 Info: auth(default): new auth connection: pid=19349 dovecot: Apr 29 22:47:27 Info: auth(default): new auth connection: pid=19350 dovecot: Apr 29 22:47:27 Info: auth(default): new auth connection: pid=19351 dovecot: Apr 29 22:47:27 Info: auth(default): new auth connection: pid=19352 dovecot: Apr 29 22:47:27 Info: auth(default): new auth connection: pid=19353 dovecot: Apr 29 22:47:27 Info: auth(default): new auth connection: pid=19354 ... It's seems that the for the specific mail the dovecot tries to reconnect for EVER. But why ? Why i cant read this specific mail ? i have more than 72.000 but in some messages i get problems like that. And there are not corrupted (the messages, it's an oreilly newsletter mail for god shake :p ). Any ideas ? i think this is relative to Authentication Cache options. dovecot 1.0.13 $ dovecot -n base_dir: /usr/local/var/run/ log_path: /var/log/dovecot.log info_log_path: /var/log/dovecot.info.log protocols: imap listen: *:143 ssl_disable: yes disable_plaintext_auth: no login_dir: /usr/local/var/run//login login_executable: /usr/local/libexec/dovecot/imap-login login_greeting: Hi buddy, have an account ? max_mail_processes: 512 verbose_proctitle: yes first_valid_uid: 1000 last_valid_uid: 5000 mail_privileged_group: mail mail_location: maildir:/var/mail/folders/%u:INDEX=/var/mail/index/%u:CONTROL=/var/mail/control/%u mbox_read_locks: dotlock fcntl imap_client_workarounds: tb-extra-mailbox-sep auth default: cache_size: 10240 cache_ttl: 18000 verbose: yes debug: yes debug_passwords: yes passdb: driver: passwd-file args: /usr/local/etc/dovecot.passdb userdb: driver: passwd-file args: /usr/local/etc/dovecot.passdb socket: type: listen master: path: /usr/local/var/run/dovecot-auth-master mode: 432 user: dovecot group: mail PS: Btw timo this is the only one problem i have from the very start with dovecot (almost 2 years) Sorry for bad English ! Evaggelos Balaskas - http://ebalaskas.gr Unix System Engineer Informatics Engineer Technological Education -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIF4GGWIK+Pe9twhoRAvW3AJ9C01bRQkbF7vGdmzc5yorzmSLxEACgo7YE kB2QtWrkf8l+qIWpOKk70C4= =PlnJ -----END PGP SIGNATURE-----

2 2

[Dovecot] Where to find 1.1 RPM for CentOS 4?
by Patrick 30 Apr '08

30 Apr '08

Hiya, I'm trying to find an rpm for the 1.1 version, since it appears to work better with NFS. Does anyone have a link to the i386 version? Thanks in advance. - Patrick

4 6

[Dovecot] dovecot-1.0.3: Backtrace:/usr/local/libexec/dovecot/imap
by Ralf Hildebrandt 30 Apr '08

30 Apr '08

GNU gdb 6.7.1-debian Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1". Reading symbols from /lib/i686/cmov/libdl.so.2...Reading symbols from /usr/lib/debug/lib/i686/cmov/libdl-2.7.so...done. done. Loaded symbols for /lib/i686/cmov/libdl.so.2 Reading symbols from /lib/i686/cmov/libc.so.6...Reading symbols from /usr/lib/debug/lib/i686/cmov/libc-2.7.so...done. done. Loaded symbols for /lib/i686/cmov/libc.so.6 Reading symbols from /lib/ld-linux.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...done. done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/local/lib/dovecot/imap/lib10_quota_plugin.so...done. Loaded symbols for /usr/local/lib/dovecot/imap/lib10_quota_plugin.so Reading symbols from /usr/local/lib/dovecot/imap/lib11_imap_quota_plugin.so...done. Loaded symbols for /usr/local/lib/dovecot/imap/lib11_imap_quota_plugin.so Reading symbols from /usr/local/lib/dovecot/imap/lib11_trash_plugin.so...done. Loaded symbols for /usr/local/lib/dovecot/imap/lib11_trash_plugin.so Reading symbols from /usr/local/lib/dovecot/imap/lib20_mail_log_plugin.so...done. Loaded symbols for /usr/local/lib/dovecot/imap/lib20_mail_log_plugin.so Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Core was generated by `/usr/local/libexec/dovecot/imap'. Program terminated with signal 6, Aborted. #0 0xb7f97424 in __kernel_vsyscall () #0 0xb7f97424 in __kernel_vsyscall () #1 0xb7e64ef5 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb7e66871 in abort () from /lib/i686/cmov/libc.so.6 #3 0x080aebea in i_internal_panic_handler ( fmt=0x80bea9c "file %s: line %d (%s): assertion failed: (%s)", args=0xbfdb2944 "�}\f\bk") at failures.c:403 #4 0x080aeafc in i_panic ( format=0x80bea9c "file %s: line %d (%s): assertion failed: (%s)") at failures.c:183 #5 0x0809d23a in mail_transaction_log_view_set (view=0x929e2a0, min_file_seq=0, min_file_offset=26588, max_file_seq=1, max_file_offset=2280, type_mask=MAIL_TRANSACTION_EXPUNGE) at mail-transaction-log-view.c:107 #6 0x08097ce2 in view_sync_set_log_view_range (view=0x928db88, type_mask=<value optimized out>) at mail-index-view-sync.c:103 #7 0x08098279 in mail_index_view_sync_begin (view=0x0, sync_mask=<value optimized out>, ctx_r=0x929e280) at mail-index-view-sync.c:132 #8 0x08086ec4 in index_mailbox_sync_init (box=0x9287740, flags=<value optimized out>, failed=false) at index-sync.c:156 #9 0x0806af41 in maildir_storage_sync_init (box=0x9287740, flags=<value optimized out>) at maildir-sync.c:1557 #10 0x08063f10 in imap_sync_init (client=0x92872f0, box=0x9287740, imap_flags=0, flags=MAILBOX_SYNC_FLAG_FAST) at imap-sync.c:46 #11 0x0806404b in cmd_sync (cmd=0x9287334, flags=MAILBOX_SYNC_FLAG_FAST, imap_flags=0, tagline=0x80be9b3 "OK Fetch completed.") at imap-sync.c:246 #12 0x0805997f in cmd_fetch_finish (ctx=0x9289fc8) at cmd-fetch.c:103 #13 0x08059cca in cmd_fetch (cmd=0x9287334) at cmd-fetch.c:173 #14 0x0805cbe0 in cmd_uid (cmd=0x9287334) at cmd-uid.c:19 #15 0x0805d16f in client_handle_input (cmd=0x9287334) at client.c:344 #16 0x0805d1fc in client_handle_input (cmd=0x9287334) at client.c:398 #17 0x0805d89f in _client_input (context=0x92872f0) at client.c:441 #18 0x080b4a37 in io_loop_handler_run (ioloop=0x92849b0) at ioloop-epoll.c:203 #19 0x080b3cac in io_loop_run (ioloop=0x92849b0) at ioloop.c:329 #20 0x080658ec in main (argc=) at main.c:290 -- Ralf Hildebrandt (Ralf.Hildebrandt(a)charite.de) snickebo(a)charite.de Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de Windows has detected that a gnat has farted near your computer. Press any key to reboot.

1 0

[Dovecot] How dovecot deal with the request to leave posts on the server?
by Ilan Shalif 30 Apr '08

30 Apr '08

Me just request to direction to the documentation of the mechanism of dovecot. Specificly about the mechanism dovecot deal with the request to leave posts on the server, the duration, and the finishing of this mode. (I know I can mark the approptiate places in the mail client (Thunderbird) Ilan Shalif

2 1

[Dovecot] Avelsieve 1.9.7 and Dovecot/TLS
by Michael Firnau 30 Apr '08

30 Apr '08

Hi, i'm installing a new mail server for our faculty and want to use the squirrelmail plugin 'avelsieve' (1.9.7). As documented on the dovecot wiki there is a problem in the STARTTLS code and i found a solution (that works for my installation): i've traced the server output in 'get_response' and instead of a script list i saw "IMPLEMENTATION". So i took a look at the file 'managesieve.lib.php' and the STARTTLS code: /* If we allow STARTTLS, use it */ if($this->capabilities['starttls'] === true && function_exists('stream_socket_enable_crypto') === true) { fputs($this->fp,"STARTTLS\r\n"); $starttls_response = $this->line=fgets($this->fp,1024); if(stream_socket_enable_crypto($this->fp, true, STREAM_CRYPTO_METHOD_TLS_CLIENT) == false) { $this->error=EC_UNKNOWN; $this->error_raw = "Failed to establish TLS connection."; return false; } else { $this->loggedin = true; // RFC says that we need to ask for the capabilities again $this->sieve_get_capability(); $this->loggedin = false; } } With my limited time and debugging possibilities i've found that the dovecot managesieve server seems to send capability lines 'automagically'. I've added a few "debugging" lines /* If we allow STARTTLS, use it */ if($this->capabilities['starttls'] === true && function_exists('stream_socket_enable_crypto') === true) { fputs($this->fp,"STARTTLS\r\n"); $starttls_response = $this->line=fgets($this->fp,1024); if(stream_socket_enable_crypto($this->fp, true, STREAM_CRYPTO_METHOD_TLS_CLIENT) == false) { $this->error=EC_UNKNOWN; $this->error_raw = "Failed to establish TLS connection."; return false; } else { $this->loggedin = true; $starttls_response = $this->line=fgets($this->fp,1024); $errormsg .= _("MFI fgets ") . $starttls_response . '<br>'; print_errormsg($errormsg); // RFC says that we need to ask for the capabilities again $this->sieve_get_capability(); $this->loggedin = false; } } and could read MFI fgets "IMPLEMENTATION" "dovecot" what will throw the following 'sieve_get_capability' out of sync. Then i've added a second 'fgets' and received: MFI fgets "SASL" "PLAIN" Then i've added a third 'fgets' and received: MFI fgets "SIEVE" "fileinto reject envelope vacation imapflags notify subaddress relational comparator-i;ascii-numeric regex" Then i've added a fourth 'fgets' and received: MFI fgets OK "TLS negotiation successful." Now the protocol should be in sync again and after removing the lines $errormsg .= _("MFI 1 fgets ") . $starttls_response . '<br>'; print_errormsg($errormsg); i could load my scripts back. So, adding four lines reading $starttls_response = $this->line=fgets($this->fp,1024); $starttls_response = $this->line=fgets($this->fp,1024); $starttls_response = $this->line=fgets($this->fp,1024); $starttls_response = $this->line=fgets($this->fp,1024); solved the problem. I know this is not a sound "fix", but i hope to help you with this. One addendum: a "debugging" using my errormsg-printout of the output from /* If we allow STARTTLS, use it */ if($this->capabilities['starttls'] === true && function_exists('stream_socket_enable_crypto') === true) { fputs($this->fp,"STARTTLS\r\n"); $starttls_response = $this->line=fgets($this->fp,1024); resulted in the response: MFI fgets OK "Begin TLS negotiation now." what looks proper to me, but the negotiation makes the server send the four lines mentioned above. Cheers

2 1

[Dovecot] Broken Header uidvalidity problem after upgrade
by Robert Henjes 30 Apr '08

30 Apr '08

Hi, we use a current Debian etch distribution as basis for our servers, which are running within a vmware server environment. Our current configuration consists of a dovecot server with imap enabled and a ldap based authentication. Mails are stored using the Maildir format on a central nfs store. We do not use any virtual mailboxes. Since upgrading from dovecot version 1.0.rc15 (debian stable) to 1.0.13 (debian etch-backport) we got the following error logs. Excerpt from mail.err: Apr 21 12:04:38 servera deliver(usera): /var/mail/Maildir/usera/dovecot-uidlist: Broken header (uidvalidity = 0, next_uid=9) Apr 21 15:37:50 servera deliver(userb): /var/mail/Maildir/userb/dovecot-uidlist: Broken header (uidvalidity = 0, next_uid=16) Apr 23 10:37:17 servera dovecot: IMAP(userc): /var/mail/Maildir/userc/.Sent/dovecot-uidlist: Broken header (uidvalidity = 0, next_uid=2) Apr 25 17:00:17 servera dovecot: IMAP(userd): /var/mail/Maildir/userd/dovecot-uidlist: Broken header (uidvalidity = 0, next_uid=8) I did already some mailinglist reviews. They confirmed in some way the problem, but there is still no explanation where it comes from, and how it can be solved or if it may affect the proper operation of the system. Here are some links with a short comment, which are related to this problem: http://www.dovecot.org/list/dovecot/2007-September/025541.html This post also uses nfs, but pam for authentication, error message is exactly the same as in our case. http://www.dovecot.org/list/dovecot/2007-July/024001.html Version upgrade from 1.0.0 to one above, also problems with uidvalidity. They described, that it happens only once for each user after upgrading. This is similar to our observations. No user complains as well ;). So it would be only of interest if it is so. http://wiki.dovecot.org/Clients/NegativeUIDs The number for uidvalidity is zero, so it is non-negative. But maybe it is correlated with these hints. From my point of view, there could be some problems with time synchronization as well between nfs server and dovecot server machine. But we checked this and they differ never more than 2 seconds. In total we are running two servers in parallel, each has it's own userspace, all accounts are strictly separated. One server is running the rc15 version, the other (more experimental) is running the backport 1.0.13. The described problem occurs only on the 1.0.13 server, which was previously updated. All other configurations are exaclty the same. Any hints? Best regards, Robert -- Dipl.-Inform. Robert Henjes University of Wuerzburg, Institute of Computer Science, Department of Distributed Systems (Informatik III), Am Hubland, 97074 Wuerzburg, Germany henjes(a)informatik.uni-wuerzburg.de Tel: +49 931 888-6652 Fax: +49 931 888-6632

2 5

[Dovecot] fourat wants to keep up with you on Twitter
by fourat 30 Apr '08

30 Apr '08

To find out more about Twitter, visit the link below: http://twitter.com/i/8859b2431664c01a1adfe2051a644a79b4cc1689 Thanks, -The Twitter Team About Twitter Twitter is a unique approach to communication and networking based on the simple concept of status. What are you doing? What are your friends doing—right now? With Twitter, you may answer this question over SMS, IM, or the Web and the responses are shared between contacts.

1 0