My base concern may be illustrated with the help of that simple telnet
session:
# telnet 127.0.0.1 imap
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
AUTH=PLAIN] Dovecot ready.
a1 login testuser ******
a1 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID
ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE
CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC
ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH] Logged in
a2 list "" %
* LIST (\NoInferiors \UnMarked) "/" "Sent"
* LIST (\HasNoChildren \UnMarked) "/" "INBOX"
a2 OK List completed.
a3 create new1
a3 OK Create completed.
a4 create new2
a4 OK Create completed.
a5 select new1
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)]
Flags permitted.
* 0 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1] UIDs valid
* OK [UIDNEXT 1] Predicted next UID
* OK [HIGHESTMODSEQ 1]
a5 OK [READ-WRITE] Select completed.
a6 select new2
* OK [CLOSED]
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)]
Flags permitted.
* 0 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1] UIDs valid
* OK [UIDNEXT 1] Predicted next UID
* OK [HIGHESTMODSEQ 1]
a6 OK [READ-WRITE] Select completed.
a7 unselect
a7 OK Unselect completed.
a8 delete new1
a8 OK Delete completed.
a9 delete new2
a9 OK Delete completed.
a10 logout
* BYE Logging out
a10 OK Logout completed.
Connection closed by foreign host.
During the whole telnet session, both files "new1" and
"new2" remained
empty (i.e. no pseudo-message written to them), no uidvalidity-related
helper file seems to have been created and no uidvalidity-related
function seems to have been called.
And clearly, both mailboxes "new1" and "new2" have received
the same
UIDVALIDITY.
Those UIDVALIDITYs appear to be persistent; messages may be added to
and deleted from those mailboxes, those mailboxes may be renamed...
their UIDVALIDITY remain unchanged and equal to 1.
In fact, any additional mailbox is created with that unique and
persistent UIDVALIDITY of 1.
Is this supposed to behave that way?
(note that I quickly tried with dovecot 1.1.16 and could observe the
same behavior)
TIA,
Axel
# 1.2.rc7: /usr/local/etc/dovecot.conf
# OS: Darwin 9.7.0 i386
protocols: pop3 imap
ssl: no
disable_plaintext_auth: no
login_dir: /usr/local/var/run/dovecot/login
login_executable(default): /usr/local/dovecot-1.2.rc7/libexec/dovecot/
imap-login
login_executable(imap): /usr/local/dovecot-1.2.rc7/libexec/dovecot/
imap-login
login_executable(pop3): /usr/local/dovecot-1.2.rc7/libexec/dovecot/
pop3-login
mail_max_userip_connections(default): 4
mail_max_userip_connections(imap): 4
mail_max_userip_connections(pop3): 10
first_valid_uid: 2001
mail_location: mbox:~/_mailboxes:INBOX=~/_mailboxes/inbox:CONTROL=~/
_mboxesctrl
mail_debug: yes
mbox_read_locks: flock
mbox_write_locks: flock dotlock
mail_executable(default): /usr/local/dovecot-1.2.rc7/libexec/dovecot/
imap
mail_executable(imap): /usr/local/dovecot-1.2.rc7/libexec/dovecot/imap
mail_executable(pop3): /usr/local/dovecot-1.2.rc7/libexec/dovecot/pop3
mail_plugin_dir(default): /usr/local/dovecot-1.2.rc7/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/dovecot-1.2.rc7/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/local/dovecot-1.2.rc7/lib/dovecot/pop3
pop3_lock_session(default): no
pop3_lock_session(imap): no
pop3_lock_session(pop3): yes
pop3_uidl_format(default): %08Xu%08Xv
pop3_uidl_format(imap): %08Xu%08Xv
pop3_uidl_format(pop3): %08Xv%08Xu
auth default:
debug: yes
passdb:
driver: pam
args: *
userdb:
driver: passwd
Going further with my question... ;-)
It stemmed from that consideration (and related ones) of RFC3501:
2.3.1.1. Unique Identifier (UID) Message Attribute
A 32-bit value assigned to each message, which when used with the
unique identifier validity value (see below) forms a 64-bit value
that MUST NOT refer to any other message in the mailbox or any
subsequent mailbox with the same name forever. [...]
Assuming the behavior shown by Dovecot isn't related to a bad config
of mine (see my previous post) but really indicates a slight
oversight, I quickly and dirtily added some lines in the code of
function mbox_mailbox_create().
The resulting binary seems to behave correctly (this is with
dovecot-1.2.0).
But I must sure be overlooking something, or? Not only because I
perhaps dangerously make use of some functions beyond what they are
intended for, but also wrt the overall logics of Dovecot.
Anyway, here's my attempt:
/* create the mailbox file */
fd = open(path, O_RDWR | O_CREAT | O_EXCL, 0660);
if (fd != -1) {
/* A shameless adaptation of mbox_write_pseudo() from:
src/lib-storage/index/mbox/mbox-storage.c */
#include "str.h"
#include "mbox-from.h"
#include "message-date.h"
#include "write-full.h"
#include "hostpid.h"
string_t *str;
/* Let's prepare the pseudo message, without trying to be
clever wrt the
uidvalidity value: just make use of the current time. */
str = t_str_new(1024);
str_printfa(str,
"%s"
"Date: %s\n"
"From: Mail System Internal Data
<MAILER-DAEMON@%s>\n"
"Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL
DATA"
"\nMessage-ID: <%s@%s>\n"
"X-IMAP: %u %010u\n"
"Status: RO\n"
"\n"
"This text is part of the internal format of your mail
folder, and is not\n"
"a real message. It is created automatically by the mail
system software.\n"
"If deleted, important folder data will be lost, and it
will be re-created\n"
"with the data reset to initial values.\n"
"\n",
mbox_from_create("MAILER_DAEMON", ioloop_time),
message_date_create(ioloop_time),
my_hostname,
dec2str(ioloop_time), my_hostname,
(uint32_t)ioloop_time, 0
);
/* Write the message to the mailbox file; in case of problem,
just try
to revert to the original behavior by truncating the file
(i.e. no
pseudo message at all). */
if (pwrite_full(fd, str_data(str), str_len(str), 0) < 0) {
i_info("mbox_mailbox_create(): failed to write pseudo
message to %s(%d)", path, errno);
/* Should a failure here be considered fatal? */
if (ftruncate(fd, 0) < 0)
i_info("mbox_mailbox_create(): failed to truncate
file %s(%d)", path, errno);
}
/* OK, it should now be safe to rely on Dovecot's ability to
build the
indexes and to correctly recognize the pseudo message. */
(void)close(fd);
return 0;
}
In the hope this may prove useful as a skeleton for a better code,
should a better handling of the UIDVALIDITY with the mbox format be
considered useful,
Axel
On Jul 1, 2009, at 5:48 PM, Axel Luttgens wrote:> * OK [UIDVALIDITY 1] UIDs validHmm. Wonder when that got broken. It used to work, but yes, I can reproduce it with v1.2 too. I'll take a look at it in a few days.
On Wed, 2009-07-01 at 17:48 +0200, Axel Luttgens wrote:> In fact, any additional mailbox is created with that unique and > persistent UIDVALIDITY of 1.Fixed: http://hg.dovecot.org/dovecot-1.2/rev/568ddefd7c18 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://dovecot.org/pipermail/dovecot/attachments/20090707/fc0ae454/attachment.bin
Le 7 juil. 09 ? 22:04, Timo Sirainen a ?crit :> On Wed, 2009-07-01 at 17:48 +0200, Axel Luttgens wrote: >> In fact, any additional mailbox is created with that unique and >> persistent UIDVALIDITY of 1. > > Fixed: http://hg.dovecot.org/dovecot-1.2/rev/568ddefd7c18Many thanks! Axel