154 lines
3.3 KiB
Plaintext
154 lines
3.3 KiB
Plaintext
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>
|