[Vmail-discuss] Webmail for vmail-sql

[Paul Warren]

On Wed, Aug 29, 2001 at 09:59:42AM +0200, Marcin Sochacki wrote:
[virtual webmail]

> The second way is quite popular among webmail packages. Unfortunately almost
> all of them claiming support for POP3, are extremely slow with large
> mailboxes. Actually the problem lies not in the size itself, but the
> number of messages. The webmail software connects to POP3 server and
> retrieves the headers for each message. Every time the user clicks
> on another message, or reloads the page there is a new POP3 connection
> made. Most of them have no caching mechanism, and it slows down things
> quite considerably. Some nice webmail-POP3 apps, which belong to this
> category are: NOCC and Postaci.

Interesting.

Chris and I are currently working on ReMail which is an IMAP based
web-mail program.  Unfortunately, being IMAP based it will not support
virtual email initially, however it is a long-term aim to tie it in with
vmail.  It uses an IMAP proxying daemon which maintains IMAP sessions.

In the long term we plan to put POP3 support in, but the problem with
POP3 is the lack of multiple folder support.  Do you know how the
POP3 webmail programs that offer subfolders work?

> Currently my choice is PHPost (with some patching). Direct mailbox access
> with Neomail and the like has too many problems for me:
> - SUID and security,
> - mailbox locking,
> - need to rewrite some code when vmail-sql changes e.g. the authentication
>   scheme.

One of the advantages of going via a POP3 or IMAP daemon is scalability
- you can run the daemon on a different machine from the frontend box.

> P.S. Chris and The Team: how about hacking some IMAP
> server to support Vmail-SQL authentication? 

Whilst this would undoubtedly be a nice endpoint, getting there is not - 
the wu-imapd code is (according to Chris) pretty horrid.

> Folders should be no problem
> IMHO, one could use e.g. $MAILBOX_PATH.$FOLDER_NAME
> (/var/mail/SERVERS/example.com/luser.my_folder).

That's one way of doing it, although we then have to be careful about
'.' in folder names, and what do we do about nested folders?  Another
problem about hacking this support into an existing daemon is that we're
asking for security that almost certainly was not designed into it,
specifically it needs to be impossible for one user to read another
user's mail spool despite the fact that they are owned by the same UNIX
user.

Paul