At present, clients accessing the object base managed by MDaemon, can only see and are offered real and actual folders existing on the file system of the server. Add the ability to define virtual folders. There could be two kind of virtual folders: (A) those provided by MDaemon itself (say, the union of two or more real folders of the same type: messages, calendars, contacts etc.), and (B) those provided by plug-in libraries developed by ISV.

Since MDaemon 13.0, with the introduction of generic file folders, a useful virtual folder would be a union of folders of different default tipe, which contain related pieces of information, but which we are forced to keep in different and independent folders due to the typed nature of MDaemon object base folders.

As you may know, Mdaemon has the Read Confirmation and Delivery Confirmation. However, these features may not be affective if the users decide to click on "Cancel" or not even click on the broadcast email that you send to them.

If you want your users to read a very important message or announcement, the only way that you can do is to force them to read it. Therefore, Acknowledgement Message is the way to go.

Right after a users log in to his/her email account, the whole WorldClient email interface will be replaced by a small windows that contains the important message that you want your users to read. At the bottom of that window, there is a "Acknowledge" button that will become active after 5 seconds (In other word, the Button will only be click-able 5 seconds after the Ackknowledgement Windows appears). This is to prevent lazy or irresponsible users not to read the message and just simply click on the Button to get away.

After the users click on the "Acknowledgement", the users will be able to see his/her normal WorldClient interface and an automated email acknowledgement confirmation will send to the admin or whoever has the permission to setup the acknowledgement message.

Under heavy volume (especially a 50% spam rate), CFilter and MSpamD's normal behavior may slow down drive access. Also, WebDaemon becomes erratic and unusable during periods of high volume: this partly from the fact it too uses the HDD for temporary files. The only option to alleviate any of this involves use of a RAMdrive: which I am currently testing, but pretty sure most admins would be uncomfortable with. Whatever can be done in memory, that would not compromise operations; should be supported by default. This would also help SSD users avoid unnecessary drive writes as well: since files/data that don't need to be permanently saved, wouldn't be written on those devices.

During an upgrade, like to 14.0.1, the auto backup that runs during the install only backs up the App and Spamassassin folders.
However, depending on what is upgraded during the install of the new software, you may need other folders to roll back to the previous version, if an issue is found, such as Worldclient and Webadmin. Otherwise you need to either manually back these up prior to install or get them back from an alternative backup source.
Would it be possible to add this functionality to the system to ensure the ability to swiftly and cleanly roll back if necessary?

A Domain Admin can see spam listed under the Public-Spam Trap from within WorldClient. Here the email can be tagged as Spam, forwarded, etc. but it cannot be Released.

Releasing legitimate email from the Spamfilter queue can only be performed by the Global Admin yet the Domain Admin can see all the spam - regardless of the domain - under the Public-Spam Trap.

At a minimum, if the Domain Admins can see the Public-Spam Trap under WorldClient then they should be able to see the Spamtrap Queue under Remote Administration.

-OR-

the ability to Release needs to be allowed from within WorldClient by Domain Admins

MDaemon Signatures do not appear to be signatures as we come to appreciate in Outlook Emails, but rather a message Disclaimer. It would be nice to have the ability to position the signature after a senders message content added as a message reply or message forward. MDaemon currently adds the signatures to the very bottom of the message content of replied and forwarded messages. This doesn't look very professional when all the signatures appear to be grouped at the bottom of the message. It looks confusing. As a side note, users on mobiles devices with ActiveSync should have their mobile signature removed and an MDaemon user configured signature added for consistency. This could be done by allowing a broader use of MACROS and configuration options within CF Rules.