mailing list archives

meli community discussions

⚠️ if something does not work as intended when interracting with the mailing lists,
reach out Github mirror Gitea repo @epilys:matrix.org

[Imap-protocol] Gmail LIST-EXTENDED bug

E-mail headers
From: Michael M Slusarz <slusarz@curecanti.org>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:55 -0000
Message-ID: 20150723130430.Horde.SA97i23HR6ui9hH7OsaY6OS@bigworm.curecanti.org permalink / raw / eml / mbox 
A Gmail IMAP protocol bug that was reported to me and has been verified.

Gmail supports LIST-EXTENDED, at least in the account I tested with.   
However, this command fails:

* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN  
X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ENABLE MOVE CONDSTORE ESEARCH  
UTF8=ACCEPT LIST-EXTENDED LIST-STATUS
a OK slusarz@gmail.com authenticated (Success)
b LIST () "" (*)
b BAD Could not parse command


This is a legal LIST command if LIST-EXTENDED is available, per RFC 5258:

    list =      "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat
                [SP list-return-opts]
    list-select-opts =  "(" [
                  (*(list-select-opt SP) list-select-base-opt
                   *(SP list-select-opt))
                / (list-select-independent-opt
                   *(SP list-select-independent-opt))
                ] ")"
                ; Any number of options may be in any order.
                ; If a list-select-mod-opt appears, then a
                ; list-select-base-opt must also appear.
                ; This allows these:
                ; ()
                ; (REMOTE)
                ; (SUBSCRIBED)
                ; (SUBSCRIBED REMOTE)
                ; (SUBSCRIBED RECURSIVEMATCH)
                ; (SUBSCRIBED REMOTE RECURSIVEMATCH)
                ; But does NOT allow these:
                ; (RECURSIVEMATCH)
                ; (REMOTE RECURSIVEMATCH)
    mbox-or-pat =  list-mailbox / patterns
    patterns =  "(" list-mailbox *(SP list-mailbox) ")"


michael
Reply
E-mail headers
From: nicolson@google.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:55 -0000
Message-ID: CACU8CfTAgfJXZ4VNZqNXZGnFtmiyNh1hwjuYUbQjkjciqxmOew@mail.gmail.com permalink / raw / eml / mbox 
*sigh*, so you're saying we're not supporting the mailbox pattern list?
I'll look into it.

On Thu, Jul 23, 2015 at 12:04 PM, Michael M Slusarz <slusarz@curecanti.org>
wrote:

> A Gmail IMAP protocol bug that was reported to me and has been verified.
>
> Gmail supports LIST-EXTENDED, at least in the account I tested with.
> However, this command fails:
>
> * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN
> X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ENABLE MOVE CONDSTORE ESEARCH
> UTF8=ACCEPT LIST-EXTENDED LIST-STATUS
> a OK slusarz@gmail.com authenticated (Success)
> b LIST () "" (*)
> b BAD Could not parse command
>
>
> This is a legal LIST command if LIST-EXTENDED is available, per RFC 5258:
>
>    list =      "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat
>                [SP list-return-opts]
>    list-select-opts =  "(" [
>                  (*(list-select-opt SP) list-select-base-opt
>                   *(SP list-select-opt))
>                / (list-select-independent-opt
>                   *(SP list-select-independent-opt))
>                ] ")"
>                ; Any number of options may be in any order.
>                ; If a list-select-mod-opt appears, then a
>                ; list-select-base-opt must also appear.
>                ; This allows these:
>                ; ()
>                ; (REMOTE)
>                ; (SUBSCRIBED)
>                ; (SUBSCRIBED REMOTE)
>                ; (SUBSCRIBED RECURSIVEMATCH)
>                ; (SUBSCRIBED REMOTE RECURSIVEMATCH)
>                ; But does NOT allow these:
>                ; (RECURSIVEMATCH)
>                ; (REMOTE RECURSIVEMATCH)
>    mbox-or-pat =  list-mailbox / patterns
>    patterns =  "(" list-mailbox *(SP list-mailbox) ")"
>
>
> michael
>
> _______________________________________________
> 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/20150723/d1d84c1b/attachment.html>
Reply
E-mail headers
From: nicolson@google.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:55 -0000
Message-ID: CACU8CfQvtX7PmGc3-A02qsx6s6Md-=BE-arwEtNZmDNLMEA4pg@mail.gmail.com permalink / raw / eml / mbox 
We can probably fix this in a week or so. Is it causing big problems for
any clients to have LIST-EXTENDED enabled with this flaw? If it's causing
serious pain we could turn off LIST-EXTENDED until it's fixed.

On Thu, Jul 23, 2015 at 12:23 PM, Jamie Nicolson <nicolson@google.com>
wrote:

> *sigh*, so you're saying we're not supporting the mailbox pattern list?
> I'll look into it.
>
> On Thu, Jul 23, 2015 at 12:04 PM, Michael M Slusarz <slusarz@curecanti.org
> > wrote:
>
>> A Gmail IMAP protocol bug that was reported to me and has been verified.
>>
>> Gmail supports LIST-EXTENDED, at least in the account I tested with.
>> However, this command fails:
>>
>> * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN
>> X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ENABLE MOVE CONDSTORE ESEARCH
>> UTF8=ACCEPT LIST-EXTENDED LIST-STATUS
>> a OK slusarz@gmail.com authenticated (Success)
>> b LIST () "" (*)
>> b BAD Could not parse command
>>
>>
>> This is a legal LIST command if LIST-EXTENDED is available, per RFC 5258:
>>
>>    list =      "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat
>>                [SP list-return-opts]
>>    list-select-opts =  "(" [
>>                  (*(list-select-opt SP) list-select-base-opt
>>                   *(SP list-select-opt))
>>                / (list-select-independent-opt
>>                   *(SP list-select-independent-opt))
>>                ] ")"
>>                ; Any number of options may be in any order.
>>                ; If a list-select-mod-opt appears, then a
>>                ; list-select-base-opt must also appear.
>>                ; This allows these:
>>                ; ()
>>                ; (REMOTE)
>>                ; (SUBSCRIBED)
>>                ; (SUBSCRIBED REMOTE)
>>                ; (SUBSCRIBED RECURSIVEMATCH)
>>                ; (SUBSCRIBED REMOTE RECURSIVEMATCH)
>>                ; But does NOT allow these:
>>                ; (RECURSIVEMATCH)
>>                ; (REMOTE RECURSIVEMATCH)
>>    mbox-or-pat =  list-mailbox / patterns
>>    patterns =  "(" list-mailbox *(SP list-mailbox) ")"
>>
>>
>> michael
>>
>> _______________________________________________
>> 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/20150723/3de6b8c6/attachment.html>
Reply
E-mail headers
From: slusarz@curecanti.org
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:55 -0000
Message-ID: 20150723204653.Horde.nTSGq462CvKEHJ8L-R7hEVB@bigworm.curecanti.org permalink / raw / eml / mbox 
Quoting Jamie Nicolson <nicolson@google.com>:

> We can probably fix this in a week or so. Is it causing big problems for
> any clients to have LIST-EXTENDED enabled with this flaw? If it's causing
> serious pain we could turn off LIST-EXTENDED until it's fixed.

Can't speak for anyone else, but this doesn't really affect us.  We  
fallback to RFC 3501 compliant LIST commands if a LIST-EXTENDED  
command fails, so this is simply adding additional round-trips and/or  
additional processing on the client side.

michael
Reply
E-mail headers
From: nicolson@google.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:55 -0000
Message-ID: CACU8CfSvckoaP41iaEGB5UygzH6=0de1xV1monxmUS=k4gyAmA@mail.gmail.com permalink / raw / eml / mbox 
This should be fixed now. Thanks for reporting it.

On Thu, Jul 23, 2015 at 7:46 PM, Michael M Slusarz <slusarz@curecanti.org>
wrote:

> Quoting Jamie Nicolson <nicolson@google.com>:
>
> We can probably fix this in a week or so. Is it causing big problems for
>> any clients to have LIST-EXTENDED enabled with this flaw? If it's causing
>> serious pain we could turn off LIST-EXTENDED until it's fixed.
>>
>
> Can't speak for anyone else, but this doesn't really affect us.  We
> fallback to RFC 3501 compliant LIST commands if a LIST-EXTENDED command
> fails, so this is simply adding additional round-trips and/or additional
> processing on the client side.
>
> michael
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150803/622e6e7d/attachment.html>
Reply