This reordering also appears to needlessly cause new pop3 UIDL's to be
created in certain cases too; for example:
courierimapuiddb
1727 1268763912.M544686P12485V0000000000000805I02DD03CD_79,S=8529
1731 1268763915.M68112P12485V0000000000000805I02DD03D1_83,S=1176
1732 1268763915.M376124P12485V0000000000000805I02DD03D3_84,S=3861
courierpop3dsizelist
1268763912.M544686P12485V0000000000000805I02DD03CD_79,S=8529:2,S 8727
60522:1130193397
1268763915.M376124P12485V0000000000000805I02DD03D3_84,S=3861:2,RS 3946
60523:1130193397
1268763915.M68112P12485V0000000000000805I02DD03D1_83,S=1176:2,RS 1209
60524:1130193397
In this example the 1268763915.M68..._83 file gets a new UIDL assigned
to it; however if I go in and manually insert the entry into the
dovecot-uidlist file then everything works fine apart from the two
entries get flipped around (but the UIDL's are preserved correctly). I'm
assuming this is actually a bug as from my understanding it's always
worse to create a new pop3 UIDL than to change the ordering.
Mark
05-01-2011 17:28, Mark Zealey yazmış:
Hi there,
I've just been experimenting with the latest
courier-dovecot-migrate.pl script and I notice that it favours keeping
pop3 UIDL ordering rather than IMAP UID preservation. There is this
comment (line 312):
# POP3 clients may want to get POP3 UIDLs in the same order always.
# Preserve the order even if it causes IMAP UIDs to change.
Does anyone have details as to which clients this actually causes a
problem with? If it's some really old software then perhaps we'd
prefer to keep the imap UID's the same but change the POP3 UIDL
ordering (not the UIDL numbering though of course)
Thanks,
Mark
