[Dovecot] mbox format and UIDVALIDITY
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
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
Le 2 juil. 09 à 18:12, Timo Sirainen a écrit :
On Jul 1, 2009, at 5:48 PM, Axel Luttgens wrote:
- OK [UIDVALIDITY 1] UIDs valid
Hmm. 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.
Hello Timo,
Anxiously awaiting your verdict. But please try to have a peaceful
week end before going further; we all guess you need some rest, don't
you? :-)
TIA, Axel
PS: I'm still stuck with my global ACLs problem (cf. the thread
"System users, mbox format and global ACLs"). Does someone have a
clue? Just a config problem? Or deeper causes? Anyway, I'll try to
investigate further tomorrow. ;-)
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.
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.
Many thanks! Axel
participants (2)
-
Axel Luttgens
-
Timo Sirainen