Re: ANN: Alternate namespace for Cyrus IMAP
On Thu, 07 Jun 2001 20:45:22 -0400, Ken Murchison [EMAIL PROTECTED] (km) writes: km I took a look at this and it IS doable (I actually hacked some code), km but it makes the LIST/LSUB code uglier than it already is. For this km reason, and the fact that Larry and I both feel that most users won't be km sharing their INBOXes, I'm not going to implement this right now. I'm not even sure at this point if we'll deploy this new namespaces provision as I haven't had a chance to play with it yet. However, it would have to happen that we're starting to create a few shared INBOXes. ;-) Currently, we're using the bb. prefix as shared folders to mirror some internal lists, and the archive. prefix to mirror a few external lists (like this one). However, for pseudo-users, or what I sometimes refer to as managed (yeah, right) shared folders, I've started using the prefix user.. An example of this might be user.helpdesk. There are a couple of reasons why I've been experimenting with shared folders that begin with user.: - It means that folks can easily use +detail aliasing. So using the example of helpdesk, I could funnel mail into helpdesk+amos or helpdesk+call09892320. - Can use Sieve for this shared folder. One cheesy application might be to abuse vacation to act as a 'thankyou' auto-responder. - Sometimes when we created a bb. folder as the pseudo-user for some group on campus, we've heard responses like we don't want everybody to have access to this!. While it's true that user education can help here, one benefit of placing such specialty folders under user. is that it clearly identifies these as being different than the mailing lists / news groups shared folders. However, like I said, at this point I'm not sure if we'll be deploying this namespaces thing or not. Frankly, and perhaps I'm just too far removed from the user support people to know any better, but I'm not aware that we've had any problems with the current behavior. Though, I suppose when word of this feature gets around, that might change. ;-) -- Amos
Re: ANN: Alternate namespace for Cyrus IMAP
John Holman wrote: Ken I do have one query though. Since personal folders and INBOX now exist at the same level for the logged-in user I had expected the same to be true also for Other Users - e.g. there might be mailboxes Other Users.Mike.INBOX Other Users.Mike.Saved etc. (There is a similar example on p.7 of RFC2342) However this is not the case - instead the messages in Mike's INBOX are found in Other Users.Mike Is it worth reconsidering this while the enhancement is still not official - or are there theoretical or practical reasons for the way it's done at present? No reason, either practical or theoretical, that I can think of right now (it just never occurred to me). I can take a look at the code to see if this is feasible. If it's going to break a lot of other stuff, I'll probably skip it for the time being. In fact, I'll look at this tonight. I was just about to release a new beta with updates to lmtpd, but I'll hold off until I check this out. I'm interested in what other people think about this. Is this change a MUST or a SHOULD for people that intend to use the alternate namespace? Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: ANN: Alternate namespace for Cyrus IMAP
Ken Murchison wrote: John Holman wrote: Ken I do have one query though. Since personal folders and INBOX now exist at the same level for the logged-in user I had expected the same to be true also for Other Users - e.g. there might be mailboxes Other Users.Mike.INBOX Other Users.Mike.Saved etc. (There is a similar example on p.7 of RFC2342) However this is not the case - instead the messages in Mike's INBOX are found in Other Users.Mike Is it worth reconsidering this while the enhancement is still not official - or are there theoretical or practical reasons for the way it's done at present? No reason, either practical or theoretical, that I can think of right now (it just never occurred to me). I can take a look at the code to see if this is feasible. If it's going to break a lot of other stuff, I'll probably skip it for the time being. In fact, I'll look at this tonight. I was just about to release a new beta with updates to lmtpd, but I'll hold off until I check this out. I took a look at this and it IS doable (I actually hacked some code), but it makes the LIST/LSUB code uglier than it already is. For this reason, and the fact that Larry and I both feel that most users won't be sharing their INBOXes, I'm not going to implement this right now. That being said, if the current behavior is determined to be a violation of RFC2342 or the people that contracted me to implement the alternate namespace want this 'feature' or demand for this 'feature' is overwhelming, then I WILL implement it. Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
RE: ANN: Alternate namespace for Cyrus IMAP
Hi, One point that I failed to mention is that subfolders of INBOX are _NOT_ permitted when using the alternate namespace (subfolders of other personal folders are allowed). This sacrifice had to be made in order to preserve the existing mailstore structure. I have no problem with this, other than: How do you move existing users over to this new system? Tarjei
RE: ANN: Alternate namespace for Cyrus IMAP
From: Tarjei Huse [EMAIL PROTECTED] Hi, One point that I failed to mention is that subfolders of INBOX are _NOT_ permitted when using the alternate namespace (subfolders of other personal folders are allowed). This sacrifice had to be made in order to preserve the existing mailstore structure. I have no problem with this, other than: How do you move existing users over to this new system? Tarjei In my limited case, the process was: 1. compile Ken's branch 2. (ask Ken some questions, but please skip this since you are reading this) 3. make install 4. edit imapd.conf to have altnamespace: yes userprefix: user 5. request users to all exit their mail clients (NS and MS in our case) 6. kill and then restart master YMMV, but in our case, existing folders were moved up one level of hierarchy: before: INBOX--- |--Trash |--infocyrus |--linux--- |--debian |--ipchains |--realestate |--school after: INBOX Trash infocyrus linux--- |--debian |--ipchains realestate school as viewed in the NS client. The directory/file structure in spool/imap/user remained the same. Even NS clients which were open during the changeover still survived, with only some message delete ability not behaving properly. After closing and restarting the NS client, the behavior was fine, with no lost messages or folders. Chris
Re: ANN: Alternate namespace for Cyrus IMAP
[EMAIL PROTECTED] wrote: From: Tarjei Huse [EMAIL PROTECTED] Hi, One point that I failed to mention is that subfolders of INBOX are _NOT_ permitted when using the alternate namespace (subfolders of other personal folders are allowed). This sacrifice had to be made in order to preserve the existing mailstore structure. I have no problem with this, other than: How do you move existing users over to this new system? Tarjei A couple of comments: In my limited case, the process was: 1. compile Ken's branch 2. (ask Ken some questions, but please skip this since you are reading this) I would kill master before doing the make install. If any processes are running, the make install might not be able to copy over all of the new binaries (text file busy errors). 3. make install 4. edit imapd.conf to have altnamespace: yes userprefix: user userprefix is optional. By default, the prefix for the other users' namespace will be Other Users. In this case, Chris set it to user so it looks the same as the standard namespace (not a bad idea since its less typing when manipulating accounts with cyradm). Likewise, the default prefix for the shared namespace is Shared Folders. Yes, these are ugly, but I took them straight from RFC2342 for lack of something better. In my case, I've been using #user and #shared. Note that using the # character is not recommended by the RFC because it is not IMAP URL friendly. 5. request users to all exit their mail clients (NS and MS in our case) Obviously should do this before killing master above. 6. kill and then restart master Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: ANN: Alternate namespace for Cyrus IMAP
[EMAIL PROTECTED] wrote: From: Ken Murchison [EMAIL PROTECTED] I am pleased to announce the availability of an alternate namespace for Cyrus IMAP which allows personal folders to reside at the same [top]level as the INBOX. You should consider this code to be late-beta, I encourage people to check this out, and give Ken feedback. It is working very well for me. This feature satisfies an urge which most of my users have, namely to create folders at the same level of hierarchy as the INBOX in their NS and MS clients. One point that I failed to mention is that subfolders of INBOX are _NOT_ permitted when using the alternate namespace (subfolders of other personal folders are allowed). This sacrifice had to be made in order to preserve the existing mailstore structure. Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: ANN: Alternate namespace for Cyrus IMAP
From: Ken Murchison [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: From: Ken Murchison [EMAIL PROTECTED] I am pleased to announce the availability of an alternate namespace for Cyrus IMAP which allows personal folders to reside at the same [top]level as the INBOX. You should consider this code to be late-beta, I encourage people to check this out, and give Ken feedback. It is working very well for me. This feature satisfies an urge which most of my users have, namely to create folders at the same level of hierarchy as the INBOX in their NS and MS clients. One point that I failed to mention is that subfolders of INBOX are _NOT_ permitted when using the alternate namespace (subfolders of other personal folders are allowed). This sacrifice had to be made in order to preserve the existing mailstore structure. Seems preferable to me...and the setting is in imapd.conf if you don't agree. Chris
