[Dovecot] patch for UID 0 problem
Hi all,
attached you'll find a patch for cmd-thread.c which addresses a problem with certain clients in conjunction with the use of the UID THREAD REFS command:
TAG5 UID THREAD REFS us-ascii SINCE 14-May-2011
- THREAD (0)(246)(247)(248)(249)(250)(252)(253)(254)(255)(256)(257)(258)(259)(260)(261)(262)(263)(264)(265)(266)(267)(268) TAG5 OK Thread completed.
The first UID delivered (0) is invalid, some clients - @mail for instance - then try to fetch the invalid UID 0 subsequently and run into problems.
The patch actually disables the return of (0) and seems to work for us. Please review and - if OK - incorporate it in the next version.
Best Regards Kai
-- Kai Arif - System Administrator Inter.net Germany GmbH Knesebeckstraße 59-61 10719 Berlin Germany
Fon +49 30 25430 0 Fax +49 30 25430 499 arif@team.de.inter.net www.de.inter.net
Legal-Information: Inter.net Germany GmbH, HRB #79136, Amtsgericht Berlin Charlottenburg, UST-IdNr:: DE 813 165 159 FA für Körperschaften I Berlin, Geschäftsführer: Jörn Lubkoll
Zuständige Regulierungsbehörde: Bundesnetzagentur Chemnitz, Liselotte-Herrmann-Str. 20a, 09127 Chemnitz, Registriernummer: 06/164
On 14.11.2011, at 11.51, Kai Arif wrote:
attached you'll find a patch for cmd-thread.c which addresses a problem with certain clients in conjunction with the use of the UID THREAD REFS command:
TAG5 UID THREAD REFS us-ascii SINCE 14-May-2011
- THREAD (0)(246)(247)(248)(249)(250)(252)(253)(254)(255)(256)(257)(258)(259)(260)(261)(262)(263)(264)(265)(266)(267)(268) TAG5 OK Thread completed.
The first UID delivered (0) is invalid, some clients - @mail for instance - then try to fetch the invalid UID 0 subsequently and run into problems.
Yes, it is. It should never happen.
The patch actually disables the return of (0) and seems to work for us. Please review and - if OK - incorporate it in the next version.
Could you instead send me such a mailbox where you can reproduce this problem? Probably sending dovecot.index, dovecot.index.log and dovecot.index.thread files would be enough. None of those contain any sensitive information.
participants (2)
-
Kai Arif
-
Timo Sirainen