wasm-demo/demo/ermis-f/imap-protocol/cur/1600095028.22671.mbox:2,S

36 lines
3.1 KiB
Plaintext

MBOX-Line: From jkt at flaska.net Sat Jun 8 05:38:04 2013
To: imap-protocol@u.washington.edu
From: =?iso-8859-1?Q?Jan_Kundr=E1t?= <jkt@flaska.net>
Date: Fri Jun 8 12:34:51 2018
Subject: [Imap-protocol] Re: UW-IMAPD and its interpretation of ESEARCH
In-Reply-To: <20130608061048.GE3533@arlut.utexas.edu>
References: <b046c657-52ae-4aae-98bd-3bd9e4937cce@flaska.net>
<20130608061048.GE3533@arlut.utexas.edu>
Message-ID: <f1f1d4ce-8645-429d-b45c-ceceb9750ddc@flaska.net>
On Saturday, 8 June 2013 08:10:48 CEST, Jonathan Abbey wrote:
> http://github.com/jonabey/panda-imap
Assuming your github username is with double Bs, the offending code is likely found at https://github.com/jonabbey/panda-imap/blob/master/src/imapd/imapd.c#L939 . I'm not sure whether I'm interpreting it correctly, it's a foreign code with a very different style than I'm used to.
That code appears to be broken on a fourth read or so :) -- it iterates over all messages and if a particular sequence of messages matches, it will output the result as min:max. That is, however, the exact problem here -- the code does not check whether the range of UIDs assigned to these messages has any holes within. In other words, the code produces correct results for SEARCH RETURN ..., but fails for UID SEARCH RETURN ... because the UIDs, unlike sequence numbers, are not guaranteed to be consecutive.
This is consistent with the output of `git blame` which suggests that the code in question comes from commit 199adc96 which is marked as "imap-2006i.tar.Z" in your repository. The capability advertised by the user's server says 2007e.404, and that version is still affected.
You can easily check this yourself. Create new mailbox, append three messages, remove the middle one and send `UID SEARCH RETURN (ALL) ALL`. If you get back something like "1,3", the code is OK, if you get "1:3", it's wrong.
I do not dare writing a patch for that code -- the assumption that one could get away with acting as if the client knew which UIDs exist and which are gone is a big one. The loop at line 952 looks like the obvious problem (it shall check for a consecutive range of UIDs, but only if the command is the UID variant of ESEARCH...), but more changes might be needed. Well, I've had enough C for now :).
On an unrelated topic -- I've noticed that you're using "|" as a quote indicator. This breaks clients which respect the long-standing convention (more or less also codified in RFC 3676 [1] -- yes, your MUA doesn't do format=flowed, but it's still useful for clients to safely detect a quoted text) that quotes are always done by ">". I was wondering if there was a particular reason for this setting, or whether it just happened to be a system-wide settings on your machine.
Yes, I *could* change the format=flowed decoder in Trojita so that it supports non-standard quoting options, but this is the first mail I've read since adding that feature four months ago, so I'm hoping that sticking with language of that RFC still has a chance of working.
With kind regards,
Jan
[1] http://tools.ietf.org/html/rfc3676
--
Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/