Hi all !

Following the criticism of Konrad Hammerer about Pegasus being so old fashioned that some users do not even want to try it, I think that making it skinable could reverse this trend. I have made this suggestion elsewhere, and I think some people here said it was a good idea. I hope David will take that into account in the rewriting of the MailStore engine. On top of that, it could give the community a more participative role.

Cheers !

Whiskyfizz.

Hi!

Since mercury became a product with a price (license AND 50 bucks per year), I would like to know if there is some kind of an official release plan where I can see in which direction the mercury development will go. I think there are still many things that mercury should be capable of like:

• Server based filters (to move messages into another folder...)
• IMAP idle
• Support IMAP folders which can contain messages AND folders
• Better support for REAL imap mail clients like TBIRD (deleting a folder (which contains other folders) still does not work)
• ...

Maybe it is time to focus on mercury and IMAP and not on Pegasus and its proprietary protocol. To be honest, I think that Pegasus is a nice mail client, but it has no future. None of my users wants to work with such an "old fashioned" mail client. No offense, but this is the opinion of my users...

Best,

Konrad

We expect to see a release of Pegasus Mail v4.52 rather shortly. And then that David focuses on Mercury and probably the new MailStore engine.

Thanks for your answer.

Still, I really would like to know what the next version(s) of mercury could look like and what features are included. The reason is that my users are demanding these functions. And even more important, I need to convince my boss of still using mercury even when it costs an annual fee. For what it's worth, I think that mercury is a very good peace of software, but features like IMAP idle (for mobile phones) are mandatory nowadays.

Best,

Konrad

What else besides support for IDLE would you like to see (by priority please)?

Peter - I would like to see the richness of the possible actions available in Filtering Rules available to Policy actions.  Conversely, it would be useful to have the same Sentinel/Results file actions in Policy available in the Filtering Rules.

Thank you

Gordon

Hi Peter,

• Prio 1 would be, that users can maintain there account through a web front end. The main goal would be to provide filtering rules directly on the server instead of defining them on every client (mobile, at home, at work, web client, rich client...). Of course, things like "changing password", "auto reply" (out of office message) and "forward" would be nice to ;-).
  
  I have access to a kerio mail server where all this is possible through a very simple web front end with nothing more than a couple of drop downs (providing the filtering rules) and text boxes (for the values of the filtering rules) plus a commit button. If necessary, I could provide screenshots...
  

• Also Prio 1 is IMAP idle

• Prio 2: Support IMAP folders which can contain messages AND folders AND that those folders can be deleted as well. It is still not possible to delete a folder which can contain other folder using TBird!!
  
  
• Prio 3: Support REAL certificates and not only self created/signed
  

Thanks a lot,

Konrad

Hi again,

for me, it would be a good start to implement the enhanced server side filters in that way, that the admin can define the filters directly on the server so there is no web gui necessary. At least things like "put every message with subject "**SPAM**" into the folder "Junk" would be possible with that functionality.

Best,

Konrad

Just as an update, we've put forth a few "urgent" requests to David. Among them is not a web front end, but to fix MercuryX that prevents proper start, possibility to reload more than just the user database via command, and some administrative openings for daemon administrative integration - so that we begin the journey towards remote management of Mercury, as this is especially important when running as a native service, or when servicing large user bases that changes often.

David focuses a lot on the new Mailstore development, that will help all of us longing for imap idle, imap filtering on the server side, add-on handling protocols etc. - My "simple" guess is that a better mailstore engine is really important for better mobility, pda connections, cache, transparent modes etc.

One of you asked about a web management. Such one already exists, please test out Rolf Lindbys webserver package.