133 lines
5.0 KiB
Plaintext
133 lines
5.0 KiB
Plaintext
MBOX-Line: From blong at google.com Thu May 2 13:03:39 2013
|
|
To: imap-protocol@u.washington.edu
|
|
From: Brandon Long <blong@google.com>
|
|
Date: Fri Jun 8 12:34:51 2018
|
|
Subject: [Imap-protocol] Unsure paternity
|
|
In-Reply-To: <1367451626.16110.140661225409245.52FEA78F@webmail.messagingengine.com>
|
|
References: <5180559B.4010000@gmail.com>
|
|
<1367371210.5033.140661224967997.4E7EBBE1@webmail.messagingengine.com>
|
|
<CABa8R6ueUB9hMMcAWGpuz9RoWyOC-LX=GX8Ls8++iUhxPUHD-Q@mail.gmail.com>
|
|
<1367451626.16110.140661225409245.52FEA78F@webmail.messagingengine.com>
|
|
Message-ID: <CABa8R6vZuhwEkDn-conxb1Jdg3V2sMG9wVqjasu-9E-z5WNx+g@mail.gmail.com>
|
|
|
|
So, we have some stuff on our support pages, and more in the product forums.
|
|
|
|
https://support.google.com/mail/answer/78761?hl=en&ref_topic=1668982
|
|
|
|
This page lists things we don't support or known bugs we have no plans to
|
|
fix.
|
|
|
|
Actually listing all known bugs, we don't really have a mechanism for doing
|
|
that. We have some bugs that we intend to fix, but they keep getting
|
|
de-prioritized. We have others which we assume only affect a small number
|
|
of very specific cases. This particular one was a global leak that got
|
|
worse over time as we have more users doing the very special things that
|
|
caused it (ie, the attributes for system folders were supposed to be
|
|
immutable and then copied to the user, but instead updates were going
|
|
directly to the global copy, but so \HasChildren was showing up for any
|
|
system folder where someone had a child of that system folder... the
|
|
original bug description implied it only happened if a user first created a
|
|
sub-folder and then deleted it).
|
|
|
|
I think the only Google products which use a user visible bug database are
|
|
those that are open sourced, such as Chrome and Android. Even then, that
|
|
then requires another level of thinking (is this bug public or not, is this
|
|
data in the bug should be public or not) which is how Chrome has to think,
|
|
and Android is worse since they use both the internal and external bug
|
|
database. And seeing how people pile onto the public bugs who don't really
|
|
understand what's going on... that doesn't sound fun.
|
|
|
|
Anyways, the fix should be live in a week or two.
|
|
|
|
Brandon
|
|
|
|
|
|
On Wed, May 1, 2013 at 4:40 PM, Bron Gondwana <brong@fastmail.fm> wrote:
|
|
|
|
> **
|
|
> 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 <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
|
|
> brong@fastmail.fm
|
|
>
|
|
>
|
|
>
|
|
>
|
|
>
|
|
> --
|
|
> Bron Gondwana
|
|
> brong@fastmail.fm
|
|
>
|
|
>
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130502/0f148c1d/attachment.html>
|