[Dovecot] Workaround for outlook UIDL handling bug ??

[Nikolaus Gerstmayr]

Scenario: Using Dovecot 0.99.10.9 as pop3 server.
With delete on retrival off.

clients: outlook*

Problem: Everytihng work perfectly, except that outlooks keeps 
re-downloading SOME mail over and over. Though it already got them.
No obvious pattern which, but only a small percentage.

First of I looked at dovecots UIDLs.
Initialy I thought it's broken (see my previous thread) 
Sorry for even thinking that, it's ok, my bad :)
Rather, outlooks UIDL handling seems to be very broken :(

But I think I found an easy workaround.

Dovecots UIDLS seem to be

timestamp.message#

eg.

1 1093990148.1
2 1093990148.2
3 1093990148.3
4 1093990148.4
5 1093990148.5
6 1093990148.6
7 1093990148.7
8 1093990148.8
9 1093990148.9
10 1093990148.10
11 1093990148.11
12 1093990148.12

The problems started with #10

-> Asumption: outlook falsy only takes a fixed numbers of chars to hold the
UIDL, the rest ist ignored. Perhaps only the first 13 or so.

What I did is reversing the order in UIDL generation.
Instead of

timestamp.message# ->
message#.timestamp.

Seems to work perfectly.

Well, a bit too early too tell if it really works.
Need to wait a couple of days and see if the problem re-appears or not.

The only thing I'm 100% sure is that outlooks UIDL handling is broken.

BTW: very nice source code.
Very easy to follow, took me 5 minutes to find the correct .c and routine.

In /pop3/command.c, 
list_uids() all I changed is

... mail->seq, client->uidvality, mail->uid to
 mail->seq, mail->uid, client->uidvality.
(2 times)

If anyone is interested, I'll keep you informed if the problem is really
gone with this mini-patch.