Thanks for the prompt reply, Norman. I am ready to spend some time on this but I can hardly guarantee that it will be enough to deliver something usable.
> I could gice you some starting points.. I am all ears. I am starting with IMAP parsers and commands. My first problem is in which states should the ACL commands be valid? This was the only resource saying something to the topic I could find: ftp://ftp.cac.washington.edu/imap/old/draft-myers-imap-imsp-01.txt > command_auth ::= list / lsub / lmarked / subscribe / unsubscribe / > create / delete / rename / replace / move / > get / set / searchaddress / fetchaddress / > storeaddress / deleteaddress / addressbook_cmd / > createaddressbook / deleteaddressbook / > renameaddressbook / getacl / setacl / deleteacl / > myrights > ;; Valid only when in Authenticated or Selected state I have no idea how authoritative it is. How far are you with https://issues.apache.org/jira/browse/IMAP-322 ? - It would be nice to be able to turn ACL on and off. How should the user groups be modeled? - Simply as Set<String> User.getGroups() ? Or maybe as an entity of its own? Best, Gazda On Wed, Jan 4, 2012 at 4:46 PM, Norman Maurer <[email protected]> wrote: > Hi Jochen, > > First of welcome :) > > Your observation is correct, there is no ACL support in Apache James (yet). > The Mailbox API should be able to handle different namespaces and also perms > with a little bit of work. I think adding the IMAP parser / command etc is > even more trivial. Anyway as you already know its not implemented yet.... > > Maybe its a perfect way for you to contribute some code ;) > So if you are intrested in adding the support I could gice you some starting > points.. > > Bye > Norman > > Sent from my iPhone. Excuse any typos.... > > Am 04.01.2012 um 15:39 schrieb Jochen Gazda <[email protected]>: > >> Ladies & Gentlemen, >> >> in the meantime I could gather some more observations concerning James >> ACLs and shared folders. >> All of them are bad news for me. Please correct me if I am wrong: >> >> 1. There is no IMAP ACL support in James: parsers for GETACL, SETACL, >> DELETEACL, LISTRIGHTS and MYRIGHTS in >> org.apache.james.imap.decode.parser.ImapParserFactory are commented >> out. Perhaps they used to exist some time ago but not in the current >> trunk. >> >> 2. There is no notion of group in >> org.apache.james.user.api.UsersRepository or >> org.apache.james.user.api.model.User >> >> 3. There are https://issues.apache.org/jira/browse/IMAP-76 saying that >> there were no shared folders and >> https://issues.apache.org/jira/browse/IMAP-80 saying that shared >> namespace support was added to MailboxSession but the >> org.apache.james.mailbox.store.SimpleMailboxSession.sharedSpaces field >> is initialized with an empty ArrayList and not a single element is >> added to it anywhere in the code. >> >> My conclusion is that there are no ACLs, no shared folders and no >> groups in James. >> >> Are there any plans to support any of them? >> >> Thanks in advance, >> >> Gazda >> >> On Wed, Jan 4, 2012 at 10:55 AM, Jochen Gazda <[email protected]> wrote: >>> Ladies & Gentlemen, >>> >>> googling for "Apache James" combined with "ACL" or "permissions" does >>> not bring anything relevant and querying the similar in james java >>> sources ditto. >>> >>> I guess Apache James 3 just does not support IMAP ACLs, does it? >>> >>> Is there another way how to achieve similar results? I.e. that each >>> user and noone else can access can read/write his own inbox and that >>> there are some group folders accessible to the group members? >>> >>> Thanks in advance, >>> >>> Gazda >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
