6.0.0-git
2020-11-24

[#5657] UID ( X-UID ) > 0x80000000 misinterpreted unsigned numbers
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 2007-08-22 (4843 days ago)
Due
Updated 2007-11-21 (4752 days ago)
Assigned 2007-08-22 (4843 days ago)
Resolved 2007-08-22 (4843 days ago)
Milestone
Patch No

History
2007-11-21 03:08:55 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.
2007-11-21 01:45:22 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.)
2007-08-23 09:54:54 ivan (dot) dolezal (at) vsb (dot) cz Comment #5 Reply to this comment
2007-08-23 09:53:23 ivan (dot) dolezal (at) vsb (dot) cz Comment #4 Reply to this comment
The problem was reported as http://bugs.php.net/42394 .
2007-08-22 18:13:10 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.
2007-08-22 15:52:31 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.
2007-08-22 07:32:52 ivan (dot) dolezal (at) vsb (dot) cz Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 3. High
Summary ⇒ UID ( X-UID ) > 0x80000000 misinterpreted unsigned numbers
Queue ⇒ IMP
New Attachment: negative_x-uid_dump.txt Download
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.

Saved Queries