Closed Bug 377900 Opened 14 years ago Closed 14 years ago
RFC 4314 IMAP ACL delete rights are not honored
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20070309 Firefox/18.104.22.168 Build Identifier: Thunderbird 22.214.171.124 (X11/20070326) Working with Thunderbird 126.96.36.199 on cyrus 2.2.13 works well with RFC 2086 ACLs. But working on cyrus 2.3.8 with RFC 4314 ACLs makes it impossible to delete mails since the "Delete Message" context menu is greyed out. The cyrus in question announces the following capabilities: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=PLAIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE IDLE LISTEXT LIST-SUBSCRIBED X-NETSCAPE URLAUTH It seems that Thunderbird 188.8.131.52 does not recognize the "RIGHTS=kxte" part, since all the mailboxes in question are set to "Full Control" for the owner. It was no problem with 1.5.0.x to work on cyrus 2.3.x releases with rfc 4314 ACLs so far. Reproducible: Always Steps to Reproduce: 1. access an IMAP account on a server with RFC 4314 ACLs. 2. try to delete a message with "del" or via context menu 3. Actual Results: unable to delete messages Expected Results: the ability to delete messages;-)
As you write down full CAPABILTY of new cyrus 2.3.8, problem looks to be clear. But IMAP protocol log is very helpful for developers to analyze problem. Get NSPR log, and attach log file to this bug thru "Add an attachment" link, please. ( mime-type="text/plain" if file size is accepted. ) http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap http://www.mozilla.org/projects/netlib/http/http-debugging.html "export(or setenv) NSPR_LOG_MODULES imap:5" is sufficient, I think.
In this log you'll see access to imap.univie.ac.at (cyrus 2.2.x) which works fine and access to mail.sproing.at (cyrus 2.3.x) which makes troubles since deleting messages is impossible. The log includes a full session from start of thunderbird until closing it after an initial check of all 4 mailboxes (1 at imap.univie.ac.at, 3 at mail.sproing.at).
Attachment #262097 - Attachment mime type: text/plain → application/x-gzip
(In reply to comment #2) > IMAP Log Difference of CAPABILTY response. mail.sproing.at imap.univie.ac.at (Cyrus IMAP4 v2.3.8-Sproing-5) (Cyrus IMAP4 Murder v2.2.13) IMAP4 IMAP4 IMAP4rev1 IMAP4rev1 ACL ACL ANNOTATEMORE ANNOTATEMORE AUTH=CRAM-MD5 --- BINARY BINARY CATENATE --- CHILDREN CHILDREN CONDSTORE --- ID --- IDLE IDLE LIST-SUBSCRIBED --- LISTEXT --- LITERAL+ --- MAILBOX-REFERRALS MAILBOX-REFERRALS MULTIAPPEND MULTIAPPEND NAMESPACE NAMESPACE NO_ATOMIC_RENAME NO_ATOMIC_RENAME QUOTA QUOTA RIGHTS=kxte --- SASL-IR --- SORT SORT SORT=MODSEQ --- STARTTLS --- THREAD=ORDEREDSUBJECT THREAD=ORDEREDSUBJECT THREAD=REFERENCES THREAD=REFERENCES UIDPLUS UIDPLUS UNSELECT UNSELECT URLAUTH --- X-NETSCAPE X-NETSCAPE
(Correction of Comment #3) Listing in Comment #3 was incorrect(some lost by my edit miss). Sorry for spam. CAPABILITY response (corrected and shortened) - mail.sproing.at (Cyrus IMAP4 v2.3.8-Sproing-5) - imap.univie.ac.at (Cyrus IMAP4 Murder v2.2.13) (Both of mail.sproing.at and imap.univie.ac.at) IMAP4 IMAP4rev1 ACL ANNOTATEMORE BINARY CHILDREN ID IDLE LITERAL+ MAILBOX-REFERRALS MULTIAPPEND NAMESPACE NO_ATOMIC_RENAME QUOTA SORT STARTTLS THREAD=ORDEREDSUBJECT THREAD=REFERENCES UIDPLUS UNSELECT X-NETSCAPE (imap.univie.ac.at only) none (mail.sproing.at only) AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN CATENATE CONDSTORE LIST-SUBSCRIBED LISTEXT RIGHTS=kxte SASL-IR SORT=MODSEQ URLAUTH
(In reply to comment #0) > Build Identifier: Thunderbird 184.108.40.206 (X11/20070326) > But working on cyrus 2.3.8 with RFC 4314 ACLs makes it impossible to delete > mails since the "Delete Message" context menu is greyed out. >(snip) > It was no problem with 1.5.0.x to work on cyrus 2.3.x releases with rfc 4314 > ACLs so far. Can you test with latest-trunk nightly(under development Tb 3.0)? (Test with new profile/account of mail.sproing.at only is recommended.)
I downloaded http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/thunderbird-3.0a1.en-US.linux-i686.tar.bz2 I created a new unix account with clean profile, but no difference. tb3.0a1(timestamp 18-Apr-2007 03:48) wont let me delete mails on cyrus 2.3.x, too. Do you need additional log files? I can provide you an IMAP Account at mail.sproing.at for debugging purposes, too. If that's an option please contact me directly.
(In reply to comment #6) > I created a new unix account with clean profile, but no difference. tb3.0a1 > (timestamp 18-Apr-2007 03:48) wont let me delete mails on cyrus 2.3.x, too. Thanks for your quick test and good data to analyze problem. > Do you need additional log files? Sorry but I'm not a developer, then I can't analyze your problem, but I think problem is clear, cyrus 2.3.8 with rfc 4314 ACLs doesn't work after Tb 2.0 or later. Please wait for analysis by developers. I think sufficient data for initial analysis has been provided by you.
I did some further research and it seems that it's the fault from cyrus 2.3.x since RFC 4314 requires the server to return "c" and "d" flags for compatibility. RFC4313: "When any of the "delete" member rights is set in a list of rights, the server MUST also include the "d" right when returning the list in a MYRIGHTS or ACL response. This is to enable older clients conforming to RFC 2086 to work with newer servers. (*)" and "(*) Clients conforming to this document MUST ignore the virtual "d" and "c" rights in MYRIGHTS, ACL, and LISTRIGHTS responses." cyrus does this for "MYRIGHTS" eg.: -1262507120[c59ae28]: c4b60a0:mail.sproing.at:S-INBOX:CreateNewLineFromSocket: * MYRIGHTS INBOX lrswipkxtecda but cyrus fails to return them on "GETACL" eg.: -1262507120[c59ae28]: c4b60a0:mail.sproing.at:S-INBOX:CreateNewLineFromSocket: * ACL INBOX mashgmx lrswipkxtea If you confirm my thoughts I'll open a bugreport at cyrus bugzilla and this bug can be closed.
Wolfgang, you may be right. It's certainly worth asking the cyrus folks. I would think myrights would override, though.
I've found the part in cyrus source already and will try to fix it tonight. I'll report back if I'm successfull proofing my thoughts;-)
OK, I think this is just because we don't treat 't' as meaning delete is allowed - we still just look at 'd'. I would think for compatibility, the server should also return 'd' in the acl, but if we parsed 't' correctly, that would fix it as well, I think.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #8) > it's the fault from cyrus 2.3.x (Off-topic) Another fault(or not-so-good-setup) maybe exists on mail.sproing.at, although I believe it has no relation to this bug's issue. Following is a page found by Google search with "RIGHTS=kxte Cyrus" (third one when my search). http://email@example.com/msg00037.html This page says "LIST-EXTENDED is added and is default in future", but there is no LIST-EXTENDED in CAPABILITY response from mail.sproing.at in your log (old LISTEXT is found). Let mail.sproing.at know about this.
treat 't' as delete rights in folder... I'm going to file a separate bug for fully supporting RFC 4314
Assignee: mscott → bienvenu
Status: NEW → ASSIGNED
Attachment #262146 - Flags: superreview?(mscott)
Attachment #262146 - Flags: superreview?(mscott) → superreview+
Ok, I patched cyrus to provide the right (full) answer to "getacl" as required by RFC 4314 and it works like a charm now with Thunderbird 2.x+! . getacl INBOX * ACL INBOX mash lrswipkxtecda anyone p . OK Completed . myrights INBOX * MYRIGHTS INBOX lrswipkxtecda So I'll report this issue to the cyrus devs, too.
(In reply to comment #12) > (Off-topic) > Another fault(or not-so-good-setup) maybe exists on mail.sproing.at, although I > believe it has no relation to this bug's issue. > Following is a page found by Google search with "RIGHTS=kxte Cyrus" (third one > when my search). > http://firstname.lastname@example.org/msg00037.html > This page says "LIST-EXTENDED is added and is default in future", but there is > no LIST-EXTENDED in CAPABILITY response from mail.sproing.at in your log (old > LISTEXT is found). Hmmm, this one is addressed in https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2875 but it seems a major feature enhancement and was put in cyrus 2.4 tree. > Let mail.sproing.at know about this. I'm the bofh at mail.sproing.at ;-)
I've checked my client fix in on the trunk.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment on attachment 262146 [details] [diff] [review] possible fix might be nice to get this for the next . release
Attachment #262146 - Flags: approval220.127.116.11?
Comment on attachment 262146 [details] [diff] [review] possible fix approved for 18.104.22.168, a=dveditz for release-drivers
Attachment #262146 - Flags: approval22.214.171.124? → approval126.96.36.199+
client-side fix landed on the 2.0 branch - if you want to, you can try a nightly 2.0 build from tomorrow to see if this fixes it for you...
14 years ago
sorry, can't test anymore since cyrus 2.3.8 wont let me set "invalid" ACLs and I've already fixed/reset them all.
David, so it should be fixed when downloaded now? Mine is still not working (cyrus 2.3.8), however my delete was initially working when I installed at the beginning of May. I was moving some folders around and making a couple other changes in thunderbird, not sure exactly what triggered it because it took a while to notice but something caused my delete to no longer work. It must have made a change in imap because I tried installing thunderbird on other machines and my delete just will not work, except in thunderbird 1.5.
(In reply to comment #24) > Mine is still not working (cyrus 2.3.8), however my delete was initially working > when I installed at the beginning of May. > my delete just will not work, except in thunderbird 1.5. To Sean: Did you get IMAP protocol log and confirm that your problem is this bug? Trunk? 1.8 build? Which build worked at the beginning of May? Which build doesn't work currently? One in next library? http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/ http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8/
(In reply to comment #25) > (In reply to comment #24) > > Mine is still not working (cyrus 2.3.8), however my delete was initially working > > when I installed at the beginning of May. > > my delete just will not work, except in thunderbird 1.5. > > To Sean: > Did you get IMAP protocol log and confirm that your problem is this bug? > Trunk? 1.8 build? Which build worked at the beginning of May? Which build > doesn't work currently? One in next library? > http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/ > http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8/ > Sorry I don't have time to read all of this but I think it may have been a different bug. Now my delete button is working for both versions listed above and the stable release that wasn't working previously. I wasn't trying any of the builds before, I was using the stable release from the main site at the beginning of May. Thunderbird 2.0 did trigger a change with Thunderbird to imap that caused the delete to no longer function, regardless of trying the stable 2.0 on other machines. It was resolved by installing 1.5 and using my box, it undid whatever changes 2.0 made to my imap box. Now it works all around, as it did for almost a month now with 2.0. If I can figure out what caused that I'll let you guys know, wierd is all I can conclude at this point.
Running 188.8.131.52, bug is still there here is example how reproduce it. Enabled move Junk messages when marked as Junk, TB tried to move message to junk but it doesn't have such rights.
I'm running Thunderbird-184.108.40.206 and using Courier-IMAP-4.1.3 (not Cyrus) and have the same problem: I've set ACL rights to "eilrstw" to some-folder, which relatively means that I should be able to mark messages from some-folder as deleted, but I should not be able to delete some-folder itself. If I select a message in some-folder, the DEL key doesn't respond and the delete-button in the context-menu is grayed out. It doesn't matter if I configure the delete-button to "Move message to trash" or "Mark as deleted". But, when I configure the delete-button to "Mark as deleted", and I manually move the message from some-folder to the trashcan, the message is marked as deleted! So the server correctly allows me to mark the message from some-folder as deleted (as the 't' in the ACL describes). When I select some-folder itself, the delete-button is not grayed out. When I press it the folder disappears. I don't think this should happen. But when I take a look at the subscribe-list, some-folder is still there. I can subscribe to it, and all is ok. So the server correctly prevents me from deleting some-folder (as lack of 'x' in the ACL describes).
Addition: I see I was incorrect about Thunderbird-220.127.116.11 and the problem with deleting folders. What I reported was tested with Thunderbird-18.104.22.168. When I try to delete some-folder (ACL "eilrstw"), Thunderbird-22.214.171.124 correctly tells me access is denied because ACL 'x' is missing. I'm extremely sorry for misreporting that :( I did discover something else: - Like I said, when including the ACL 't' I can't mark messages as deleted. - If I include the ACL 'x' I can't mark messages as deleted (as expected). - But if I include them both (ACL "xt") I *can* mark messages deleted. This makes me think Thunderbird-126.96.36.199 needs both 'x' and 't' in order to allow the deletion of messages. This isn't correct, only 't' should be enough. PS: I've also tested this with Thunderbird-3.0a1pre, same results as Thunderbird-188.8.131.52
You need to log in before you can comment on or make changes to this bug.