Re: [Imap-protocol] Unsure paternity

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 <[email protected]> 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 <[email protected]> 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
>    [email protected]
>
>
>
>
>
> --
>  Bron Gondwana
>  [email protected]
>
>

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol