MBOX-Line: From brong at fastmail.fm  Wed May  1 16:40:26 2013
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Fri Jun  8 12:34:50 2018
Subject: [Imap-protocol] Unsure paternity
In-Reply-To: <CABa8R6ueUB9hMMcAWGpuz9RoWyOC-LX=GX8Ls8++iUhxPUHD-Q@mail.gmail.com>
References: <5180559B.4010000@gmail.com>
	<1367371210.5033.140661224967997.4E7EBBE1@webmail.messagingengine.com>
	<CABa8R6ueUB9hMMcAWGpuz9RoWyOC-LX=GX8Ls8++iUhxPUHD-Q@mail.gmail.com>
Message-ID: <1367451626.16110.140661225409245.52FEA78F@webmail.messagingengine.com>

It would be rather cool if you had somewhere you could publish a list
of known differences between your implementation and the standard...
not quite as good as working, but hey :)



I'm finally at the point where I have the cycles to fix some long
standing bugs in LIST-EXT handling in Cyrus - we have a problem that
the mailbox listing the subscriptions listing are different databases,
and we choose to iterate one or the other, but not both, meaning we
miss some recursivematch cases.



Looking forward to finding time to play with your CONDSTORE stuff too.
I'm really liking the power of MODSEQ to save bandwidth.



Bron.



On Thu, May 2, 2013, at 07:18 AM, Brandon Long wrote:

Would you believe its been a recognized bug since 2010 but we thought
it only applied if the user specifically had deleted the subfolder?
And the broken code has existed since we originally supported
HasChildren in 2007.

*sigh*

I have a fix in process.

Brandon



On Tue, Apr 30, 2013 at 6:20 PM, Bron Gondwana <[1]brong@fastmail.fm>
wrote:





On Wed, May 1, 2013, at 09:36 AM, David Barchiesi wrote:

> I was analyzing the response produced by LISTing Gmails mailboxes and

> came across something similiar:

>

> * LIST (\HasChildren \HasNoChildren \Trash) "/" "[Gmail]/Trash"

>

> According to RFC 3348 [1]:

> "It is an error for the server to return both a \HasChildren and a

> \HasNoChildren attribute in a LIST response. ".

> Could anyone explain what is going on here?



Well, a bug obviously.  It's not just you either, here's my gmail
account

complete LIST response (XLIST is identical, and LIST-EXTENDED doesn't
seem

to be supported at all)



. list "" *

* LIST (\HasNoChildren) "/" "INBOX"

* LIST (\HasNoChildren) "/" "Personal"

* LIST (\HasNoChildren) "/" "Receipts"

* LIST (\HasNoChildren) "/" "Travel"

* LIST (\HasNoChildren) "/" "Work"

* LIST (\Noselect \HasChildren) "/" "[Gmail]"

* LIST (\HasChildren \HasNoChildren \All) "/" "[Gmail]/All Mail"

* LIST (\HasNoChildren \Drafts) "/" "[Gmail]/Drafts"

* LIST (\HasChildren \HasNoChildren \Important) "/" "[Gmail]/Important"

* LIST (\HasChildren \HasNoChildren \Sent) "/" "[Gmail]/Sent Mail"

* LIST (\HasChildren \HasNoChildren \Junk) "/" "[Gmail]/Spam"

* LIST (\HasChildren \HasNoChildren \Flagged) "/" "[Gmail]/Starred"



* LIST (\HasChildren \HasNoChildren \Trash) "/" "[Gmail]/Trash"

. OK Success



Brandon - any idea when this crept in?  I haven't played with gmail's
IMAP

for a while, but I don't remember seeing it before.



Bron.

--

  Bron Gondwana

  [2]brong@fastmail.fm






--
Bron Gondwana
brong@fastmail.fm

References

1. mailto:brong@fastmail.fm
2. mailto:brong@fastmail.fm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130502/efc25833/attachment.html>
