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