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

We have a lot of hosts on Security Settings > Screen Host.

For example we have .dotmailer.com, .pur?.net, .getrespooonse.com, .createsend.com and more. Basically all this big companies that pretend to send solicited bulk mail but all they do is send unsolicited bulk mail. Thanks to this entries we have reduces our incoming mail by 90%.

The problem is this companies have loads of hosts and they try and try and try to send emails even when you reply with a 550 after the HELO several times.

Since added all those hosts to Screen Host our number of SMTP sessions (in) has gone for 300 per hour to 3000 per hour!!!

Our log files are full of 220 > HELO > 550 I thought, why don't you have an option to add to dynamic screen the refused hosts? That will stop all those incoming SMTP sessions that end with a 550 after the HELO.

Auto Black Listing feature of the sender IP and auto reporting to SPAM COP.

The problem with this is it is a manual process and not Automated and it should be. One big problem with MDaemon is your Black list feature only places the Domain address into the Black list. You are not providing a method of auto IP blocking.

Also if the server is used for Gateway SPAM filtering which is what we do for customers there is not a quick way to show all email and then display the messages as shown below. In order to see the screen below you need to dig in the Queue area to locate this screen and the other issue is it fails to display the Sender IP address.

You can right click on the message and select black list however it is only placing a useless name (fake name or email address) into the black list which will never be used again by the SPAM sender. You need to search the message just as SPAM COP does and locate the sending IP and issue this IP to the BLACK List. Also you should place the Name of the bogus domain and or IP next to it.

We are aware that you could unintentionally block a valid email sender if the IP were for example coming from AOL. This is up to the ADMIN on if they want to block it or not but currently there is not a good method for blocking IP Addresses.

This process could be automated and at the same time you Black List the IP it could also send ALTN the header and handle it the same way SPAM COP handles reported SPAM for members and or you could possible set up a way to report the message to SPAM COP.

The 2 items - Black Listing IP and Reporting the sender as a SPAMMER are the ways we saw SPAM eliminated after using MDaemon for 15 or more years and running all your regular methods which worked poorly.

Also by placing the Sending IP address into the queue below I can review the number of SPAM messages coming from a set of Servers and I can not tell this the way it displays the information currently. I would need to open each message and look through the message to locate the sending IP. Again there is no reason why you can not provide a way to display the sender IP and have the feature to Black List this IP of the selected messages.

I would in many cases TAG multiple records which could then be black list all these IP addresses in a mater of seconds. To further supply a smart method of Rejected or Dropped messages can be placed into a simple LOG that can be quickly viewed. The idea here would be IP address which has been black listed and the sender Email that has been dropped. This allows us a way to see dropped IP and sender email domain addresses. I can then see from this log if a good person has been dropped verses the SPAMMER that come from the same sending system. I find that in most cases the method outlined in this document to be the best method of elimination of SPAM.

Customers migrating from other Mail platforms often have a set of per user PST files they wish to migrate over to MDaemon. Currently the method of migrating this information involves each user setting up a new Outlook connector profile, Mounting the PST and moving the data over manually.

This works but is long winded for multiple users. It would be great if this migration could happen at the server. For example. you could have a migration tool that matches PST files (named to match MDaemon user accounts) and runs through the process of importing the data within the PST file storing it under that account. In a similar way that the Exchange Migration tool works.
The ability to migrate for other mail platforms would help attract new customers who wish to try out all of the benefits of MDaemon and Outlook Connector.

I have been testing MDaemon & other email server software in order to put them into production in our office.

MDaemon has two ways of sharing emails : Public folders & shared folders with their own ACLs. In public folders the flags can be either per user or shared flags with other users. If the flags are shared with other users, then the Read, Unread, Replied, Forwarded, etc. all status are shared with other users, this way one can know which emails have been replied or forwarded. However if the Public Folders are configured with Per User IMAP flag settings, then every user does get to know which emails are new and unread by him, but it does not reflect whether a particular email has been replied or forwarded by any of his colleague. What I am looking is for a situation where all flag status are shared between the users except for the read / unread status. This way every user will have a clear picture of the conversation as well as what mails are new to him. This is a feature that works well with other mail servers such as Axigen & Desknow, where all flags are shared except for read unread status which is configured on a per user basis.