493209 - problem with rights imap folder, can't delete messages

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[eudes]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
Build Identifier: 20090302

in a imap account, if a folder had all rights except "x", he can't delete messages from this folder (http://www.courier-mta.org/maildiracl.html)

In normal time, he can't remove/rename the folder, but can delete messages inside the folder, there is no problem with outlook for exemple.

thanks

Reproducible: Always

Steps to Reproduce:
1. in courier-imap, file courierimapacl for a specific folder had: owner aceilrstw
2. receive a message in this folder (folder Spam for exemple)
3. try to delete message, you can't

Comment 1

[Ludovic Hirlimann [:Usul]]

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.0.10)
> Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
> Build Identifier: 20090302

Eudes is that the build identifier for Thunderbird ? Could you follow the instructions at https://wiki.mozilla.org/MailNews:Logging and provide us with an imap log when you reproduce the problem ?

Comment 2

[eudes]

ok i see what is the problem, but i don't understand
in debug, i have :
5536[49a5548]: 4a162f8:imap.cisneo.fr:S-INBOX.Spam:CreateNewLineFromSocket: * ACL "INBOX.Spam" "owner" "acilrsw"

but, in server i have aceilrsw !!!
if i test with outlook express or microsoft, i can delete messages

Comment 3

[David :Bienvenu]

the log is just showing what the server is telling us. Are we asking for the right user? 

It may be that we're respecting the ACL, and OE is not, and trying the delete anyway.

Comment 4

[eudes]

nop,
see it :
telnet 91.193.56.5 143
a001 LOGIN [e-mail] ***

a002 SELECT INBOX.Spam
* FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent)
* OK [PERMANENTFLAGS (\* \Draft \Answered \Flagged \Deleted \Seen)] Limited
* 1 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1242386707] Ok
* OK [MYRIGHTS "aceilrstw"] ACL
a002 OK [READ-WRITE] Ok


and it's the good account
5292[4797950]: 

47ab7a8:imap.cisneo.fr:NA:ProcessCurrentURL:imap://[e-mail]:143/select%3E%5EINBOX:  = currentUrl

Comment 5

[David :Bienvenu]

so we get one response when we do an ACL command, and a different one when we select the folder? Do we ever ask for MYRIGHTS explicitly in the protocol log?

I doubt that we're parsing the unsolicited MYRIGHTS response when we select the folder, but I can look.

Comment 6

[eudes]

yep, strange :)

5660[4798248]: 47aef50:imap.cisneo.fr:A:SendData: 3 select "INBOX.Spam"

5660[4798248]: ReadNextLine [stream=459f260 nb=60 needmore=0]
5660[4798248]: 47aef50:imap.cisneo.fr:A:CreateNewLineFromSocket: * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent)

5660[4798248]: ReadNextLine [stream=459f260 nb=77 needmore=0]
5660[4798248]: 47aef50:imap.cisneo.fr:A:CreateNewLineFromSocket: * OK [PERMANENTFLAGS (\* \Draft \Answered \Flagged \Deleted \Seen)] Limited

5660[4798248]: ReadNextLine [stream=459f260 nb=12 needmore=0]
5660[4798248]: 47aef50:imap.cisneo.fr:A:CreateNewLineFromSocket: * 1 EXISTS

5660[4798248]: ReadNextLine [stream=459f260 nb=12 needmore=0]
5660[4798248]: 47aef50:imap.cisneo.fr:A:CreateNewLineFromSocket: * 0 RECENT

5660[4798248]: ReadNextLine [stream=459f260 nb=34 needmore=0]
5660[4798248]: 47aef50:imap.cisneo.fr:A:CreateNewLineFromSocket: * OK [UIDVALIDITY 1242386707] Ok

5660[4798248]: ReadNextLine [stream=459f260 nb=33 needmore=0]
5660[4798248]: 47aef50:imap.cisneo.fr:A:CreateNewLineFromSocket: * OK [MYRIGHTS "aceilrstw"] ACL

5660[4798248]: ReadNextLine [stream=459f260 nb=22 needmore=0]
5660[4798248]: 47aef50:imap.cisneo.fr:A:CreateNewLineFromSocket: 3 OK [READ-WRITE] Ok

5660[4798248]: 47aef50:imap.cisneo.fr:S-INBOX.Spam:SendData: 4 myrights "INBOX.Spam"

5660[4798248]: ReadNextLine [stream=459f260 nb=35 needmore=0]
5660[4798248]: 47aef50:imap.cisneo.fr:S-INBOX.Spam:CreateNewLineFromSocket: * MYRIGHTS "INBOX.Spam" "acilrsw"

5660[4798248]: ReadNextLine [stream=459f260 nb=26 needmore=0]
5660[4798248]: 47aef50:imap.cisneo.fr:S-INBOX.Spam:CreateNewLineFromSocket: 4 OK MYRIGHTS completed.

5660[4798248]: 47aef50:imap.cisneo.fr:S-INBOX.Spam:SendData: 5 getacl "INBOX.Spam"

5660[4798248]: ReadNextLine [stream=459f260 nb=38 needmore=0]
5660[4798248]: 47aef50:imap.cisneo.fr:S-INBOX.Spam:CreateNewLineFromSocket: * ACL "INBOX.Spam" "owner" "acilrsw"

5660[4798248]: ReadNextLine [stream=459f260 nb=24 needmore=0]
5660[4798248]: 47aef50:imap.cisneo.fr:S-INBOX.Spam:CreateNewLineFromSocket: 5 OK GETACL completed.



if you need a account test, reply to me :)

Comment 7

[David :Bienvenu]

OK, that looks like a server bug - we get one set of rights from the unsolicited response (which I believe we do parse), but we get a separate set of rights from the explicit myrights command.

On the client side, there's no need for us to issue the myrights command if the server already told us about our rights in the SELECT response - that would work around the server issue. If you gave me a test account, I could try to fix that.

Thx!

Comment 8

[eudes]

i sent email test to you mail account bienvenu at nventure.com, is that right?

Comment 9

[David :Bienvenu]

yes, thx, I've received the info - I'll let you know how it goes.

Comment 10

[David :Bienvenu]

Attachment: proposed fix

This should fix it - if we get an unsolicited MYRIGHTS response (unsolicited is a term from the IMAP RFC meaning we didn't explicitly request the info), remember it. An unsolicited response won't have the folder name, apparently, since it's in the context of a SELECT statement.

Comment 11

[eudes]

ok,

the patch will be present in the next version of thunderbird?

regards

Comment 12

[Ludovic Hirlimann [:Usul]]

(In reply to comment #11)
> ok,
> 
> the patch will be present in the next version of thunderbird?

If it gets review  and superreview before we ship , it will

Comment 13

[eudes]

oh ok

thanks you very much

Comment 14

[Mark Banner (:standard8)]

Comment on attachment 377726 [details] [diff] [review]
proposed fix

r/sr=Standard8

Comment 15

[David :Bienvenu]

fix checked in, will be in tomorrow's nightly build.