65 lines
2.6 KiB
Plaintext
65 lines
2.6 KiB
Plaintext
MBOX-Line: From blong at google.com Wed Mar 8 11:07:13 2017
|
|
To: imap-protocol@u.washington.edu
|
|
From: Brandon Long <blong@google.com>
|
|
Date: Fri Jun 8 12:34:55 2018
|
|
Subject: [Imap-protocol] Strange behavior of Dwarf IMAP
|
|
In-Reply-To: <7e831cbb-da19-6e45-5990-1c8a641bb00c@brokersys.com>
|
|
References: <c5f4fa80-5df3-b937-6039-757128711c2a@comaxis.com>
|
|
<7e831cbb-da19-6e45-5990-1c8a641bb00c@brokersys.com>
|
|
Message-ID: <CABa8R6sBy8R8t0ZObq4ONz1XWzvGHOTL4_v1sGAbPfHoQQDerw@mail.gmail.com>
|
|
|
|
Is technically in spec, as in they can send as many untagged fetch
|
|
responses as they want.
|
|
|
|
Probably not what they intended or anyone wants, though.
|
|
|
|
Brandon
|
|
|
|
On Mar 8, 2017 8:31 AM, "Jonathan Guthrie" <jguthrie@brokersys.com> wrote:
|
|
|
|
> It doesn't appear to be part of Gnome, that is it doesn't appear to be
|
|
> part of the Gnome desktop environment, but rather a commercial Slovakian
|
|
> enterprise called "Gnome ltd". It also appears that the latest version is
|
|
> 5 years old, with no known defects or similar in their documentation page.
|
|
>
|
|
> With that said, it looks like an error to me. You can't get the source
|
|
> code without jumping through hoops, so I can't look at it to see what it's
|
|
> doing. At least, I'm not willing to jump through the hoops.
|
|
>
|
|
> On 3/7/2017 6:44 PM, Jeff McKay wrote:
|
|
>
|
|
>> I am dealing with a customer's IMAP server, which identifies itself as
|
|
>> Dwarf 2.0.0 (part of Gnome I guess) that seems to be acting
|
|
>> strangely. My code sends this command:
|
|
>>
|
|
>> A746 FETCH 1 (FLAGS UID INTERNALDATE BODY.PEEK[])
|
|
>>
|
|
>> I expect to get back a single message, however after the last line of the
|
|
>> first message, I then get the line:
|
|
>>
|
|
>> * 2 FETCH (FLAGS (\Seen) UID 2290456508 INTERNALDATE "20-Jan-2017
|
|
>> 07:55:29 -0500" BODY[] {76009}
|
|
>>
|
|
>> and on and on... In other words it just keeps blasting messages at me,
|
|
>> beyond the single message I asked for. I've never seen this
|
|
>> behavior before with any other server. At first I thought it was some
|
|
>> screw up in my lower level tcp code, but I am quite certain that
|
|
>> I never sent out a FETCH 2 command, so how could I be getting message 2,
|
|
>> 3, etc.?
|
|
>>
|
|
>> _______________________________________________
|
|
>> Imap-protocol mailing list
|
|
>> Imap-protocol@u.washington.edu
|
|
>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
|
>>
|
|
>
|
|
>
|
|
> _______________________________________________
|
|
> Imap-protocol mailing list
|
|
> Imap-protocol@u.washington.edu
|
|
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
|
>
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20170308/91644aeb/attachment.html>
|