[ingo] User authentication/imapd namespaces was Re: Normal 'filesystem' backend for ingo/procmail?

[Allen Landsidel]

Quoting Jan Schneider <jan at horde.org>:

> Why don't you keep Horde users authenticating against IMAP or IMP?  
> This way you don't have to care about that, because IMAP  
> authentication is independent from how the passwords are stored, as  
> long as the IMAP server understands those.
>
> Beside that, if you have reasons to authenticate directly against the 
>  SQL server, Horde supports all common hashes, so this should work 
> too.

Well primarily I was figuring if I used Horde, which doesn't seem to be 
'supported' or make any sense, meaning horde itself provides no native 
authentication backend, that there would be more freedom to the Horde 
apps.

I was hoping that if Horde was handling all the authentication itself, 
with it's tight integration with the modules, it would be easier 
administratively to create things like a system-wide Turba address book 
that is automatically kept up to date when I add/remove users, and 
things like that.

Free/busy URLs are another example; if Horde was managing the user 
database, then I'd imagine it wouldn't be too difficult for Kronolith 
(if it is installed) to add each users free/busy URL to their global 
address book entry.

I hope I've at least explained what I'm trying to accomplish clearly, 
if it's possible or not is entirely something else.  I'm "the sysadmin" 
where I work, but I'm not the only guy in the IT department, and while 
they're open to replace Exchange I have to find a suitable replacement.

They're going to come after me with pitchforks if I tell them "Well 
first you use postfixadmin to add users and that's where users change 
their passwords.  Then each user needs to go into Turba to set this 
administration-owned shared address book as their primary address book. 
  After that, make sure to add the new user to the address book, and 
don't forget to look up their free/busy URL and add that as well.  See, 
this is almost as easy as clicking 'new user' in active directory!"


>>
>> To me, the default should be to show all the mailboxes as  
>> sub-folders of INBOX.  First, physically, that's how they are  
>> stored.  In Maildir format, Inbox is the '.' directory, and all  
>> directories/folders created from that point must by definition be  
>> under/within Inbox.  You cannot actually create a folder that is at  
>> the same level as Inbox, since Inbox is the top level maildir.
>
> As you already noticed, this is how Courier handles it technically.  
> Users shouldn't have to care which IMAP server is used under the 
> hood,  and how it stores folders internally. Thus IMP provides a 
> consistent  interface for all IMAP servers with any folders on the 
> same level as  INBOX.

I understand, but it's not just how Courier handles it.  It's also how 
Cyrus handles it, and even Dovecot, which I just replaced courier with. 
  The Inbox is always the top-level Maildir, and all the folders are 
contained below it (physically on disk).

Personally I like the special folders being at the same logical level 
as the Inbox.

However, this doesn't negate the "bug" that is apparently in Courier 
only (maybe Cyrus, don't care, haven't looked) but not in Dovecot -- If 
you do NOT do the "unsupported hack" to change the namespace/folders 
options in the new IMP, you cannot create folders under the Inbox.

That functionality people definitely want, and the IMP detection of 
namespaces has broken this in Courier.  It works fine in Dovecot.

I just wanted to bring to attention the fact that Cyrus isn't the only 
IMAP server that was 'broken' by the change to autodetection, and that 
overriding while perhaps distasteful to some, shouldn't be an hidden 
unsupported option.