[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>:
>
>>> I would much rather not have to run an ftp daemon whos only job is  
>>>  to move files around the local filesystem, but I don't know the   
>>> semantics that ingo's backend.php wants.
>>
>> Use the FTP entry as a starting point. horde/lib/VFS/file.php  
>> should  have the available backend configuration items documented  
>> in the file  header.
>
> Thanks for the pointer, I'll look into that.
>
> I'm also curious (to change subjects) about the password hashing  
> that horde uses if you are using it to do user authentication.   
> Currently I'm letting imp/imapd do user authentication but this is  
> proving to have some drawbacks in the environment I'm creating.
>
> Currently I have courier imapd (that change to namespace stuff re:  
> cyrus messed up courier a bit too, more on that in a minute) using  
> an SQL database for authentication, user management is done via  
> postfixadmin.  I'm wondering if the hash/salt is a sort of  
> 'standard' meaning if I migrate all the existing account records  
> over to Horde, can Horde use the hashes as-is?  If not, what's the  
> solution to providing pop3/imap access to people that don't want to  
> use the horde interface?

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.

> .. on the imapd namespace changes ..
>
> (disclaimer:  I have never read any IMAP spec/RFC.  If the RFC says  
> that it's supposed to be such-and-such a way, you can say so and  
> call me names.  This all applies to Courier-IMAPD, I've never used  
> Cyrus and never will.)
>
> 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.

Jan.

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