Bug 181288 - Message: NO Access denied for GETACL on INBOX (ACL "a" required)
Message: NO Access denied for GETACL on INBOX (ACL "a" required)
Product: Fedora
Classification: Fedora
Component: thunderbird (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
Depends On:
  Show dependency treegraph
Reported: 2006-02-12 16:29 EST by Peter Bieringer
Modified: 2018-04-11 14:02 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-17 11:08:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 319535 None None None Never

  None (edit)
Description Peter Bieringer 2006-02-12 16:29:24 EST
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)

How reproducible:

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

Additional info:

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]
T server:143 -> client:1341 [AP]
 * MYRIGHTS "INBOX" "cdilrsw"..A00011 OK MYRIGHTS completed...
T client:1340 -> server:143 [AP]
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]
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
Comment 1 Peter Bieringer 2006-12-18 07:44:18 EST
Same issue with thunderbird-
Comment 2 Peter Bieringer 2006-12-21 15:46:24 EST
A first working solution created by developer is available now:
Comment 3 Matěj Cepl 2007-05-17 11:08:23 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.