[Vmail-discuss] Webmail for vmail-sql

[Chris Lightfoot]

On Wed, Aug 29, 2001 at 09:59:42AM +0200, Marcin Sochacki wrote:
    [...]
> 
> The original question concerned virtual accounts; getting some webmail
> for local users is a piece of cake.

Though the quality of many webmail solutions is not up to
scratch in my opinion.

> And BTW, some thoughts I've had recently about webmail solution for
> vmail-sql.
> 
> One can choose out of two possible ways to do it: (1) direct mailbox access
> and authentication (usually requires SUID scripts) and (2) access mailboxes
> via POP3 (i.e. tpop3d).
> 
> The first solution is employed by `neomail' and `openwebmail' packages.
> Both are written in Perl and need some patching to customize them for
> vmail-sql. They have some nice features, like addressbooks and subfolders,
> and don't require any IMAP or POP3 daemon at all.
> On the other hand, I'm not sure what the result would be under heavy load;
> I think there might be some mailbox locking issues.

Of the solutions I've looked at, those which use the
direct-access-to-folders method all seem to do so directly
from setuid CGI scripts. I haven't looked at the locking
in any detail, but it's not a trivial problem and I
wouldn't be surprised if there were issues there. In
particular, some sort of IPC between different instances
of the scripts is probably required for things to work
cleanly. I for one am not happy about the idea of a large,
potentially buggy perl program taking on the identities of
random users for each page view. (If the thing doesn't
acquire the identity of the users whose mail it is
reading, then it won't work with folders in a user's home
directory, which is pretty lame if you want to run it on a
machine with shell account users too.)

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

IMO POP3 is not suitable for this role. You can't select
new folders, you can't write messages in to the folder,
and you can't do anything with messages apart from
downloading them and deleting them.

> The only one I've found which provides caching for POP3 sessions is:
> PHPost (http://webgadgets.com/phpost/). It's written in PHP, and is
> muuuuch faster thanks to caching. Unfotunately there is no subfolders
> support here yet, but addressbook is almost done (as the author claims).
> 
> 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.

This seems a sensible choice if you're happy with the
limitations attendant on using POP3.

> P.S. Chris and The Team: how about hacking some IMAP
> server to support Vmail-SQL authentication? Folders should be no problem
> IMHO, one could use e.g. $MAILBOX_PATH.$FOLDER_NAME
> (/var/mail/SERVERS/example.com/luser.my_folder).

Hmm.

I have resisted doing this, for a number of reasons. In
particular, the IMAP server which I would probably start
from is the Washington University one. The problem with
this will be obvious to anyone who has had the misfortune
of looking at the code: it is _horrid_. Also, it's
non-free, and I've never quite understood the status of
patches to it. I believe that you can distribute patches,
but not the patched code. This is a pain, especially since
I don't imagine that the WU people would accept a patch
for MySQL support. The said, I have already written a
(not-quite-complete) patch for metadata caching for the WU
imapd (in a largely successful attempt to tame is
treacle-like performance when opening folders), so I
suppose an additional patch wouldn't chew up my soul too
much. It would be plenty slow, though, since the WU imapd
is a runs-from-inetd type of server.

An alternative is to find another IMAP server to patch.
However, I'm not aware of any which are (a) any good,
(b) support enough of IMAP (sorting, searching, threading,
...) and (c) support mailspools and maildirs. Without
this functionality, they won't really be a decent
replacement for the WU one. In particular, the Courier and
Cyrus products require respectively the use of maildirs,
or of a *whole new filing system for mail*, which is no
good at all for our application.

(I admit that the WU one is only (a) any good by a *very*
loose set of criteria. It's nice to see non-free software
lowering the bar here.)

The third alternative is to write one, which would be a
lot of work which I am reluctant to do `just for fun'.

-- 
Chris Lightfoot -- www.ex-parrot.com/~chris/
 ... a difficulty for every solution (Samuel, on the Civil Service)