[horde] alternative imp mail delivery methods

[Chuck Hagenbuch]

Quoting Nico Galoppo <scratch at ace.ulyssis.org>:

> Anyway, I was thinking of using IMP to have an internal web messaging
> system (so the website users can send mail to each other, but not
> outside). That would require IMP to deliver it's messages to a database
> (for example), instead of an IMAP server.

It requires _something_ to deliver to an alternative format. It'd probably be 
best to configure your MDA to handle this, unless you don't want to allow 
outside users to send mail in (even then, it's more flexible).

> I already discussed this with Chuck, and he proposed to patch the
> c-client library. It can deliver messages to a local mailbox instead of
> the IMAP server, but that would still require a user every mailbox
> wouldn't it?

That's not quite what I said. :) First off, c-client doesn't deliver messages 
anywhere; it's just responsible for reading them (okay, it does have smtp 
functions, but that's not the point). You can read messages from an IMAP 
server, but you can also read messages from a local mailbox file. Yes, you 
would need a mailbox _file_ for every user, but not a unix user - they'd all be 
owned by the webserver user.

> I took a quick look at the IMP api, and as far as I can see,
> implementing database message delivery would require rewriting
> IMP_Folder, IMP_Message & IMP_Tree. That way, it wouldn't be IMP anymore
> wouldn't it ;)

If you really want to do this, you don't want to touch those; using c-client to 
open a local mailbox will let those pieces of code stay exactly the same. What 
you need is:

1. Something to authenticate users against. Horde auth could take care of this 
nicely.

2. A way to deliver messages to local mailbox files. A sendmail rule could do 
this, or you could just write a custom Mail_local driver (using IMP 2.3) that 
writes messages directly to files.

3. You'll probably need some small changes to the auth code in IMP::authenticate
() and maybe the IMP::serverString() functions to support the local file 
opening.

That _should_ be about it. (2) is definitely the hardest piece; I'm happy to 
help you with the rest, and possibly with that as well. Now that I think about 
it, writing a custom Mail_ class might be a pretty easy way to go - you'd have 
to handle locking issues, but it'd let you encapsulate all of your local logic 
quite nicely...

-chuck

--
Charles Hagenbuch, <chuck at horde.org>
"We have no fuel on board, plus or minus 8 kilograms." -A NASA scientist