Re: [webmin-l] Virtualmin Professional

[Joe C. <jo...@sw...>]

Craig White wrote:

> ----
> good for you guys - I think that is a logical extension of the
> webmin/virtualmin product.

Thanks for the encouragement!  We felt that way too.  It just became 
apparent that it was the best way to answer the needs of commercial 
hosting providers, without causing any pain to users of the GPL version.

And thanks for all of the good advice.  I'll comment on each bit inline 
below.

> Hosting is not my thing so I haven't played with virtualmin at all in
> any form.
> 
> It does seem to me from my reasonably good familiarity with webmin and
> my minimal familiarity with usermin that:
> 
> - webmail at my last look was very minimal and should support things
> like IMAP folders/IMAP logins

Usermin supports (straight from the Usermin Folders page):

- System folders like Inbox, Drafts and Sent Mail that always exist.
- Folders in in the mail directory that can be created or deleted by 
Usermin.
- Other files or directories that can be managed as folders by Usermin.
- POP3 accounts on other servers that can be treated as folders.
- IMAP accounts on other servers.
- Composite folders, which combine two or more other folders into a 
single list.
- Virtual folders, which contain a selection of mail from others.

Usermin mail rocks.  And with the new theme, it is close to being as 
good looking as any other webmail product on the market--I've got some 
other stuff up my sleeve on the look-and-feel front, too, so webmail is 
going to get a lot nicer to use in the coming months, hopefully without 
losing any of the clean simplicity and flexibility of the current 
interface.  Usermin has been my favorite webmail client for years 
because of its clean and simple design, but I know some folks like the 
flash of Squirrel, Horde, etc. so I'll address that too.  ;-)

> - Better LDAP management/integration

Currently, the Virtualmin LDAP support is limited to a couple of 
specific use cases, which cover what we've had people request 
specifically...but not all LDAP use cases.  In short, users and groups 
in LDAP are supported, and QMail+LDAP is supported for mail users and 
aliases (though I should note that Virtualmin Professional bundles 
Postfix, and QMail will never be an included package for Virtualmin 
Professional--so, technically, this use case doesn't apply to Virtualmin 
Professional unless you jump through a few hoops to replace Postfix as 
the mail server).  We have an open wish in the bug tracker to add 
support for Postfix+LDAP for aliases and other stuff.  It is likely it 
will happen in the next couple-few weeks, as it isn't a huge task and 
LDAP is popular in some types of mass-hosting environments.

If anyone has any specific use case examples of using LDAP in a virtual 
hosting environment, I'd certainly like to hear about it.  Specifics are 
much easier to develop for than generic "more <feature>" goals.

> - Better Cyrus integration - especially because cyrus-imapd is such a
> natural for virtual users/virtual domains

We won't be supporting Cyrus, I'm afraid, unless there is real 
widespread customer demand for it.  We've chosen Dovecot as our 
IMAP/POP3 server.  I know of no compelling reason to support Cyrus over 
Dovecot, but I'm willing to be wrong.  I've tried them all, and Dovecot 
is a gorgeous example of elegant design applied to a mundane but 
absolutely necessary task...very fast, zero maintenance, extremely 
reliable, historically very secure, supports LDAP (and SQL if someone 
were sick enough to go down that path for mail), and standards 
compliant.  And it works great for virtual hosting environments with a 
lot of flexibility.

> - Support for Sieve editing by users

Never touched it, though it sounds nice in theory.  We've got 
comprehensive Procmail rule editing support--but it is extremely 
intimidating for normal users (even some PhDs I know are afraid of 
Procmail).  However, I have a hard time imagining that normal users 
would find any kind of comprehensive Sieve editing any less intimidating 
than the current Procmail interface.  Sieve just doesn't look like a 
user-level solution for anyone other than you and I and people like us. 
  My mom will never use Sieve directly and it would be madness for me to 
try to convince her to use it directly.  Since we can put an easy/safe 
GUI on either Procmail or Sieve, it's irrelevant to the end user what we 
use.  What it comes down to is that direct editing of a text-based email 
processing rules language is just not something normal users are going 
to do.

Something a customer suggested that I think would be nice is import of 
existing filters from Mozilla or Outlook.  Though, because these things 
are stored way deep down in the users home directory and offer no 
"export" feature, it would be quite ornery to actually walk a user 
through the process of finding their filter file and uploading it. 
Maybe we just need to emulate the filter creation model of Thunderbird 
and/or Outlook, so that users can create filters in Usermin using an 
interface they already are familiar with.  Whether it generates Sieve 
rules or procmail rules is somewhat irrelevant to the user.  I think in 
this case, Sieve would be a solution looking for a problem, since we 
already have a mail rule processor in place for mail that is more 
powerful (of course, Sieve is less powerful by design--but we can 
restrict access to the power of procmail as needed, while we can't make 
Sieve more powerful as needed).

In short, I don't see what our non-computer nerd users could possibly 
gain by having Sieve support.  They definitely need filter configuration 
(which is not very easy to use in Usermin currently, I will concede), 
but what language those rules are written in is wholly a question for 
the software developer...not the end user.  The end user should never 
have to see a programming language, even one that is as simple as Sieve. 
  For you and me, Sieve would be awesome.  For Virtualmin users, it 
would be as pointless as the Procmail interface in Usermin currently is.

But, again, I'm willing to be wrong.

> Not that I haven't been able to make good use of webmin but I have
> pretty much eschewed usermin in favor of Horde 3/IMP 4/Ingo etc. because
> it fills the gaps of Sieve/IMAP and a much more robust webmail
> interface.

Define "robust"?  What's missing from Usermin's webmail that makes it 
less appealing to you (other than IMAP and Sieve, if anything)? 
Whatever it is we'd like to address it.  ;-)

I've found that quite a few webmail apps rely on an extra SQL database 
for storage of indexes or other random crud.  I find this to be a very 
fragile design decision...If you're going to use an extra database in a 
project that isn't a database-driven app (i.e. one in which the database 
is core to the functionality), it ought to be an embedded database like 
SQLite or BerkeleyDB...no configuration, no setup, no maintenance. 
Running a mail server simply should not require database maintenance. 
This seems a common and nearly fatal flaw in a lot of webmail 
applications, IMHO, no matter how nice they might look otherwise.

> Just thought I would pass along my comments.

And they are greatly appreciated.  Thanks!

Regards,
Joe