Red Hat Bugzilla – Bug 181288
Message: NO Access denied for GETACL on INBOX (ACL "a" required)
Last modified: 2018-04-11 14:02:17 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20060202 Fedora/1.0.7-1.2.fc4 Firefox/1.0.7
Description of problem:
If Thunderbird or Mozilla/IMAP connects to a courier-imap server with per user
disabled shared folders, a message box occurs with following contents: NO
Access denied for GETACL on INBOX (ACL "a" required)
I filed already the same bug at mozilla.org, but no one cares about since a month.
Version-Release number of selected component (if applicable):
thunderbird-1.0.7-1.1.fc4 mozilla-1.7.12-1.5.2 (also thunderbird 1.5)
Steps to Reproduce:
1. Configure server side: courier-imap version 4.0.6 with per user disabled
shared folders by e.g.:
2. IMAP login with Thunderbird
3. Select a folder
Actual Results: Message box occurs: NO Access denied for GETACL on INBOX (ACL "a" required)
Expected Results: No such message box
I had some discussions with the courier-imap author resulting that it is
perhaps more a problem in the IMAP client than in the server implementation.
For tracking this more down, I catched packets with ngrep:
With disabled shared folders:
T client:1341 -> server:143 [AP]
A00011 MYRIGHTS INBOX..
T server:143 -> client:1341 [AP]
* MYRIGHTS "INBOX" "cdilrsw"..A00011 OK MYRIGHTS completed...
T client:1340 -> server:143 [AP]
A00003 GETACL INBOX..
T server:143 -> client:1340 [AP]
A00003 NO Access denied for GETACL on INBOX (ACL "a" required)..
With shared folders per user enabled:
T server:143 -> client:1347 [AP]
* MYRIGHTS "INBOX" "acdilrsw"..A00011 OK MYRIGHTS completed...
T client:1346 -> server:143 [AP]
A00003 GETACL INBOX..
T server:143 -> client:1346 [AP]
* ACL "INBOX" "owner" "acdilrsw"..A00003 OK GETACL completed...
Note that MYRIGHTS shows now an additional "a".
courier-imap author told me that an IMAP client cannot assume that it has
administrative rights on any mailbox, even INBOX. And removing the ACL string
from the capability string before login probably won't help because clients
could read the server's capabilities prior to logging in, and assume they
remain the same.
Also the GETACL command requires the administrative right, the "a" ACL. This
check is correct, because this operation requires ACL "a" privileges, which
client don't have when shared support is disabled
BTW: Mulberry shows the same message, if "Details" are requested from an INBOX.
Why doesn't the client check for the "a" flag of MYRIGHTS and drop GETACL, if
Same issue with thunderbird-18.104.22.168-1.fc6
A first working solution created by developer is available now:
We believe that it is more approriate to let it be resolved upstream. Red Hat
will continue to track the issue in the centralized upstream bug tracker, and
will review any bug fixes that become available for consideration in future updates.
Thank you for the bug report.