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

[Jan Schneider]

Zitat von Allen Landsidel <allen at 1001islington.com>:

> 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!"

Don't worry, Horde is flexible enough that you can do all that without  
a single user intervention.

>>> 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.

I don't see how you could create subfolders to INBOX, if we don't  
display folders hierarchically below INBOX. That's the whole purpose,  
the uses shouldn't have to care whether folders folder are below or  
next to INBOX. This has been decided a while ago, and it won't be  
changed.
There's a lot of discussion in the mailing list archives, if you are  
interested in a more in-depth view at this discussion.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/