Tickets :: [#5657] UID ( X-UID ) > 0x80000000 misinterpreted unsigned numbers

6.0.0-beta1

7/26/25

Summary	UID ( X-UID ) > 0x80000000 misinterpreted unsigned numbers
Queue	IMP
Queue Version	4.1.4
Type	Bug
State	Not A Bug
Priority	2. Medium
Owners
Requester	ivan.dolezal (at) vsb (dot) cz
Created	08/22/2007 (6548 days ago)
Due
Updated	11/21/2007 (6457 days ago)
Assigned	08/22/2007 (6548 days ago)
Resolved	08/22/2007 (6548 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

11/21/2007 03:08:55 AM	Michael Slusarz	Comment #7	Reply to this comment
Is there a way Horde could test for this problem, and report an error to the user if PHP misbehaves? The current behavior is for messages with a UID above 2^31 to just not show up (but the number of unread messages displayed next to the folder name is correct). How could we test for it? If these UID are out of range, it is causing issues in the c-client module - well before we can do anything about it.

11/21/2007 01:45:22 AM	horde (at) phroggy (dot) com	Comment #6	Reply to this comment
Is there a way Horde could test for this problem, and report an error to the user if PHP misbehaves? The current behavior is for messages with a UID above 2^31 to just not show up (but the number of unread messages displayed next to the folder name is correct). Mozilla Thunderbird and Apple Mail both have the same bug. Mozilla is working on fixing it (bug 223942). I reported it to Apple as bug 5608502; they haven't responded yet. (For the record: the reason you're likely to encounter this bug is, your IMAP server stores mail folders in mbox format, using an X-UID header to store the UID, and your MTA is not set up to strip X-UID headers from incoming messages, so when a spammer sends you a message with a fake X-UID header, the IMAP server has to trust it because it doesn't know better. This is a huge problem even if this signed integer bug is fixed, because someone could send you a message with an "X-UID: 4294967295" header; if you're using the mbox format, you MUST set your MTA to strip these headers on incoming messages: Status, X-Status, X-Keywords, X-UID, X-IMAP, X-IMAPbase.)

08/23/2007 09:54:54 AM	ivan (dot) dolezal (at) vsb (dot) cz	Comment #5	Reply to this comment
reported as http://bugs.php.net/42394 .

08/23/2007 09:53:23 AM	ivan (dot) dolezal (at) vsb (dot) cz	Comment #4	Reply to this comment
The problem was reported as http://bugs.php.net/42394 .

08/22/2007 06:13:10 PM	Michael Slusarz	Comment #3 State ⇒ Not A Bug	Reply to this comment
Unless I'm missing something, there is no way we can handle this in IMP. It'd have to be fixed in the PHP imap extension. Agreed. And a bit concerning that FUD is being thrown our way from the uw-imap lists.

08/22/2007 03:52:31 PM	Chuck Hagenbuch	Comment #2 State ⇒ Feedback Priority ⇒ 2. Medium	Reply to this comment
Unless I'm missing something, there is no way we can handle this in IMP. It'd have to be fixed in the PHP imap extension.

08/22/2007 07:32:52 AM	ivan (dot) dolezal (at) vsb (dot) cz	Comment #1 Priority ⇒ 3. High State ⇒ Unconfirmed New Attachment: negative_x-uid_dump.txt Queue ⇒ IMP Summary ⇒ UID ( X-UID ) > 0x80000000 misinterpreted unsigned numbers Type ⇒ Bug	Reply to this comment
Horde misinterprets big X-UIDs as signed instead of unsigned 32bit integers, producing requests that can not be fulfilled by an IMAP server, resulting in fatal error reported to a user as "Requested message not found." when trying to open this mail. Enclosed you will find a tcpdump of such a conversation between IMP and UW IMAP. See also http://mailman1.u.washington.edu/pipermail/imap-use/2007-March/000200.html , but PITA of me and the vice dean is not the spam case but regular mail.