As Thomas already stated, There is Squirrelmail for webmail, and with use of daemons (even with out them) Mercury is already powerfull. Spamhalter, Greywall and Content Control and even the standard filtering Rules... and more...
I run Mercury as a service (win32) that starts up automatically when I start up the computer. When starting, the startup screen always appears for couple of seconds.
It would be nice to have a parameter (for example mercury.exe -nosplash) that starts up Mercury without splash screen so that it feels as an "invisible" service when starting up the computer.
Comments: Strangly if srvany.exe is used (part of Windows Resource Kit Tools) to create the effect of Mercury as nt service, there is no start-up screen when the parameter mercury.exe -m is used, but there is a minimized window of mercury in the taskbar that disappears when you click on it.
When the program FireDaemon () is used to let seem Mercury as a nt service, there is no minimized window but still a startup screen.
For internal reasons (to do with the way Mercury manages the list files) it's not a trivial change to sort the subscriber list. It's a reasonably common request, but implementing it will take quite a bit of effort.
We create the smtpauth.mer file with the same pairs as local mailbox name (= username) and the pop3 password. If your local mailboxes follow the syntax you should be able to have that combination within smtpauth.mer.
However, we've found it to be limiting, narrowminded and confusing for the users to have local mailboxes equal the mail-address. It gets very hard to explain that a mailbox has mail addresses attached to it, and that you can have as many as you like connected with a mailbox. Also for our users when using the webmail interface our users can log in using either their email address or their mailbox name, and a conversion is made if needed into the pair of mailbox/password for proper pop and imap fetch.
At this point, you can't really write a Daemon that could have a significant impact on the way MercuryP operates - I haven't as yet opened up its innards in the way I have for MercuryS... GreyWall is a good example of the type of minute control that the new protocol-level event mechanism I have developed for Daemons allows, but I'm retrofitting the event mechanism on a module by module basis, and MercuryP hasn't been done yet (even for v4.5). It's on the list though.
That said, the sorting idea isn't a difficult option to add, so that seems like a reasonable compromise in the short term.
Commentary on Point 1. The 30 char limit on email address in the Syslog (I and O records) will truncate this : Symantec_Mail_Security_for_SMTP@workorder.se Changing to variable-length records will also allow the addition of new fields more easily.
Commentary on Point 2 relating to mail stats. In trying to determine bandwidth usage per user, I have been examining the "I" and "O" records from the Syslog. 2.1 Mail between Local users only generates an "I" record. 2.2 A Local / Non-Local identifier on each address would be most useful for reporting (as indicated in the Core display) This to be able to split reporting between Local and Non-Local traffic. 2.3 Inbound mail indicates the TO address as the "mailbox" name and not the "alias" (email address) Outbound mail shows the FROM address as the email address and not eh "mailbox" name. Correlating the two is not possible by looking at the data only - a matching table is required.
Have you had a look at PopfileD? It's a server-side daemon for mercury that uses popfile to classify mails.
I have 5 separate buckets set up; you could create a bucket for 'houses' that adds an X-Text-Classification header to the mails, then your boss could filter houses mail as spam, and you could filter it into your 'todo' folder for example.