Re-fixed.

Changes have been made in Git for this ticket:

Bug #10079: Re-fix ACLs on RFC 2086 servers

  2 files changed, 8 insertions(+), 2 deletions(-)
http://git.horde.org/horde-git/-/commit/43ec7cbb2f31a4bd920eae4b8879950877a8ffc3

+1 using courier-imap

Changes have been made in Git for this ticket:

Revert "Bug #10079: Only expand virtual rights on RFC 2086 servers"
This reverts commit 5e53976de51be1bce1079a111f62ebb5de82275d.

  1 files changed, 1 insertions(+), 13 deletions(-)
http://git.horde.org/horde-git/-/commit/6f8fc4369fc4bc492f8249f37bf726453169ce3a

This broke IMP again with the original issue of this ticket, I can no 
longer delete messages.

Changes have been made in Git for this ticket:

Bug #10079: Only expand virtual rights on RFC 2086 servers

  1 files changed, 13 insertions(+), 1 deletions(-)
http://git.horde.org/horde-git/-/commit/5e53976de51be1bce1079a111f62ebb5de82275d

Changes have been made in Git for this ticket:

Bug #10079: More ACL fixes

  3 files changed, 51 insertions(+), 27 deletions(-)
http://git.horde.org/horde-git/-/commit/da1e75b8b8fa5d7eb3004c035b1183575e4a4442

Works fine again.

Let's try this.

Changes have been made in Git for this ticket:

Bug #10079: Fix ACL parsing on RFC 2086 server implementations
Also, Fix setACL() for Socket driver (was always doing replace instead
of add/remove).

  7 files changed, 96 insertions(+), 50 deletions(-)
http://git.horde.org/horde-git/-/commit/2228ada1510551617ebe5cad3b5e546fc2c750dd

OK - this makes things better then.  We leave it to the method that 
actually sends the rights string to the server to determine which 
string to use.

In my defense, I'm not the only one who thinks that the ACL 
specification is crap though:

http://mailman2.u.washington.edu/pipermail/imap-protocol/2010-November/001338.html

Nevermind - this won't work.  We lose the ability to selectively 
disable the components of a virtual right on 4314 servers.

We're going to have to return different rights strings based on 
whether the server supports 4314 or not.  Sigh.

Actually, looking at my Cyrus version and the capability response, 
this doesn't matter at all in this case. I'm still running 2.2.x which 
doesn't implement 4314 yet, which should be discovered by the fact 
that the RIGHTS capability is missing, or in other words it doesn't 
include texk which is required to notify about 4314 capabilities. You 
couldn't know this of course because the capability response was 
missing from my logs.

The more I think about this, the more I am convinced that this is 
broken behavior.  ACLs should not be treated differently based on 
which mailbox you are in - either ALL mailboxes on a server support 
RFC 4314 or NONE of them should.

That being the case, we need to workaround this broken behavior.  See 
if this commit fixes things; it attempts to auto-detect the RFC 
standard used in a mailbox.

Changes have been made in Git for this ticket:

Bug #10079: Workaround broken ACL server implementations

  4 files changed, 77 insertions(+), 31 deletions(-)
http://git.horde.org/horde-git/-/commit/7d12eab7e9dd9b6e6eecfca0da6c03e3125debde

So in your example:

(1305381018,4323) S: * MYRIGHTS INBOX.horde.cvs lrswipcda

We need to treat this as: lrswipa

Since this user is missing the 't' right:

    t - delete messages (set or clear \DELETED flag via STORE, set
        \DELETED flag during APPEND/COPY)

they don't have delete message access in that mailbox.  And in this 
case, we can't auto-detect if a server is returning RFC 2086-compliant 
rights or RFC 4314 compliant-rights since, according to your 
explanation, they are returning both (so we can't CAPABILITY sniff for 
RIGHTS=).

Directly from RFC 4314:

    (*)  Clients conforming to this document MUST ignore the virtual "d"
         and "c" rights in MYRIGHTS, ACL, and LISTRIGHTS responses.

Thus, c and d rights need to be ignored.  Not really sure how to work 
around this.

Not necessarily. Cyrus is still using 2086 ACLs if those were 
generated (i.e. the mailbox created) with a Cyrus version that didn't 
support 4314. ACLs are not automatically updated when updating Cyrus, 
but only if the ACL is explicitely changed, using the newer Cyrus 
version.

This is only an issue with deprecated RFC 2086 IMAP installations.

Trying to delete to trash folder gets me an error message that the 
folder is read-only. This is the relevant ACL checking from the IMAP 
logs:

(1305381018,2285) S: * OK neo Cyrus IMAP4 
v2.2.13-Debian-2.2.13-19ubuntu4 server
  ready
(1305381018,2312) C: [LOGIN Command - username: jan]
(1305381018,2330) S: 1 OK User logged in
(1305381018,2356) C: 2 EXAMINE INBOX.horde.cvs
(1305381018,2726) S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen 
NonJunk J
unk $NotJunk $Junk)
(1305381018,2731) S: * OK [PERMANENTFLAGS ()]
(1305381018,2732) S: * 19 EXISTS
(1305381018,2734) S: * 0 RECENT
(1305381018,2735) S: * OK [UIDVALIDITY 991562206]
(1305381018,2736) S: * OK [UIDNEXT 94136]
(1305381018,2737) S: 2 OK [READ-ONLY] Completed
(1305381018,2908) C: 3 UID SORT (DATE) US-ASCII ALL
(1305381018,3229) S: * SORT 69762 69775 69778 70496 75382 75383 75384 
76595 82258 82259 84297 87437 88016 88926 90035 91220 94037 94134 94135
(1305381018,3237) S: 3 OK Completed (19 msgs in 0.000 secs)
(1305381018,3455) C: 4 SELECT INBOX.horde.cvs
(1305381018,3933) S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen 
NonJunk Junk $NotJunk $Junk)
(1305381018,3939) S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 
\Deleted \Seen NonJunk Junk $NotJunk $Junk \*)]
(1305381018,3943) S: * 19 EXISTS
(1305381018,3945) S: * 0 RECENT
(1305381018,3947) S: * OK [UIDVALIDITY 991562206]
(1305381018,3948) S: * OK [UIDNEXT 94136]
(1305381018,3949) S: 4 OK [READ-WRITE] Completed
(1305381018,3992) C: 5 MYRIGHTS INBOX.horde.cvs
(1305381018,4323) S: * MYRIGHTS INBOX.horde.cvs lrswipcda
(1305381018,4338) S: 5 OK Completed