Justin writes:
Sam Varshavchik wrote:Justin Murdock writes:I'm sorry, I don't understand.Justin Murdock writes:I'm running the v 3.0.8 of the standalone Courier imap server.
Shouldn't Courier be returning those of the "x", "e" and "t" flags that are set in this case?
"maildiracl -compute ...... user=me" returns lret, but myrights returns lr. Bug?
There are no e and t rights in ACL1.
If you are using the ACL1 API, use the d flag.
If you are using the ACL2 API, use the full set of flags.
The manual entry suggests that maildiracl uses ACL2.
The server lists ACL2=UNION in its capability, so I guess it uses ACL2.
The server also lists "ACL" in its capability string. The server understands both versions of the protocol.
The working draft says "A client may determine the set of rights granted to the logged-in user for a given mailbox by using the MYRIGHTS command."
Why then does "maildiracl -compute ...... user=me" return the ACL2 result "lret", but when I'm logged into the server as "me" 'r1 MYRIGHTS "#shared.user.folder"' only returns "lr"?
Am I missing something obvious?
"MYRIGHTS" is an ACL1 command. The draft actually refers to the "LIST(MYRIGHTS)" command.
I note they've "fixed" the "c" flag to be "k" and "x"
They didn't really "fix" anything. They just broke more things, and called it a "fix".
If you're messing with maildiracl, you have to know which clients you will be dealing with.I though the point of having backwards compatability was that you didn't?
ACL2 is not backwards compatible with ACL1.
How do I cause the server to return ACL2 rights?
Use the ACL2 "LIST(MYRIGHTS) command.
pgpoUpV05qrgG.pgp
Description: PGP signature
