In order to be able to sell Mdaemon to prospective new clients I do need to wow them a bit with the GUI as this is the first thing that most end clients see and care about. They don't care about spam filtering, back end administration etc which are the things that I care about for Mdaemon.

I don't think that you need to make huge changes to your CSS coding. In fact, most of the changes I am suggesting would probably be quite minor.

1. Replace the flag, category, select icons etc with more modern looking icons. A lot of the icons within webmail are a bit basic looking. I am not sure if it's the colour, size or the icons themselves etc as I am not a graphic designer. I just can see that it looks a bit dated in a way.

2. Most email programs are moving to a double or triple line view for each message, where you can see a snippet of the email message as well. For some reason that I don't know, it does dramatically change the look of the webmail program for the better as well if the rows are much higher than standard one line rows. That spacing just seems to display better for some reason. It also helps to show emails that have been categorised better if you have a line down the length of the row highlighting the category colour instead of a small square like you currently do.

3. Hover over appointments in calendar to have a bubble display of the whole event. You already have this, but it's a very basic looking html bubble compared to say Em client or Outlook. The calendar view just looks very basic overall.

4. I also think the issue may be the default font used in Webmail. Some fonts just look more modern than other fonts. But it may be because there is just too much grey everywhere? I am not sure, but the email window look is a bit bland.

Below, is an example of what I am suggesting. However I am not indicating that you should implement this exact design as your developers will have lots of ideas of their own no doubt.

But a picture does better illustrate where I think the gui design should be going. You have already done this to a very large extent with the MDIM app within the webmail. I would imagine that you just need to port the CSS coding from the MDIM within webmail to the actual Webmail itself?

Thanks Robert

https://www.google.co.uk/imgres?imgurl=https%3A%2F%2Fi.pinimg.com%2Foriginals%2Fac%2F05%2F6c%2Fac056c3bb59df1a77eb8f4d9223340d5.jpg&imgrefurl=https%3A%2F%2Fwww.pinterest.com%2Fpin%2F557883472562905306%2F&docid=XGrvBR2AnA0z4M&tbnid=7MnZ11WGr2zO9M%3A&vet=12ahUKEwjQne7n7L7lAhWRWhUIHSNlA804ZBAzKEowSnoECAEQSw..i&w=1566&h=1176&bih=914&biw=1680&q=good%20webmail%20gui&ved=2ahUKEwjQne7n7L7lAhWRWhUIHSNlA804ZBAzKEowSnoECAEQSw&iact=mrc&uact=8

The request is that some of the metadata that appears in log files be organised in an accessible SQL db to simplify, and help secure the utilisation of the overall system.

My use case is as follows:

In an attempt to secure users primary emails I regularly run scripts to attempt to determine the source of authenticated sessions, and that they correspond to users and devices that are expected e.g. ActiveSync sessions from known devices and networks, or authenticated SMTP from known IPs or via authenticated VPNs.

These tasks end up parsing a lot of log files, where all of the info seems to reside.
However, it would be much easier if this metadata were stored in a queryable database.

A simple example - a QNAP NAS needs to have password details of an authenticated email account to send updates and details of security checks. Such NASes have had security holes that might have allowed them to be compromised. So I check that it only sends email to admins, and that this account only gets used from the NASes IP address.
This involves parsing the Dynamic screen log to check when an authenticated session starts, parsing the SMTP-in log to see the recipient and message number, and possibly the all log to check the title and other details.

These tasks would obviously be easier if they were a couple of queries! They would be dynamic and easier to protect rather than having log files copied around.

The following security settings would be a good example here.

Close connection if no PTR exists
Close connection if no PTR Match
Outbreak Protection
Spambot Detection

I used to have Spambot Detection enabled but I disabled it a few months back because it appeared to me that the only emails being affected by this were legitimate senders.

I currently have both PTR checks above enabled. We have had a few legitimate senders affected by this.

I also have Outbreak Protection enabled

However there is no easy way for me to list all senders (domains) that were affected by security setting abc. This would really help to ensure that a particular security setting is optimal in that it's blocking 99% spam and less than 1% of legitimate emails. I think it would make sense to have some kind of search function to enable administrators to compile a complete list of sender domains that were blocked because of a security setting which would make it easy to pick up legitimate senders that are being blocked as a result of a security setting. In addition, if I saw 95% of the emails being dropped were from legitimate senders, I could disable that security setting.

I feel that we could be missing legitimate emails and don't even know about it because the sender either doesn't realise or does not let us know.

Currently with location screening, any countries in the blacklist, the emails are simply dropped. In the main this has worked well with blocking 90% of the countries that we never expect to receive emails from and I think has really helped with malware.

However, once every few months, we miss an email that is sent by a helpdesk system or CRM system which for some reason is located in a country in the blacklist even though the supplier we are dealing with is not located in that country and their usual emails come through another system. I suspect that we are also missing emails that we are not even aware of that we should be receiving, because we are not waiting for that particular email.

I have come to the conclusion that a simple blacklist is not entirely practical because there is no way to track an expected email if it's blocked by country. I always have to keep asking the sender what IP address and country the Mailer program is using/from which is really not a desirable way to manage emails and this is causing frustration for end users.

I would like to request that we have the option to either blacklist a country or filter a country for smtp email connections as there are certain countries where an outright ban is appropriate but other countries where a spam filter approach might be better. In fact what I would do is set all countries to filter and after a couple of years, just block countries where we get no legitimate emails and filter the rest.

In addition, it would allow us to whitelist senders from filtered countries whilst still filtering everything else from that country. Currently I have to allow an entire country even if we only receive one sender from that country. Geolocation is great, but we need to go beyond simply blacklisting countries. I hope my suggestion of blacklisting and filtering lists would solve this.

With regards to my other request about separating authentication block list vs smtp block list - that request is still valid and relevant. We don't need people outside the country logging into the email.

Hopefully this latest feature request can be accommodated as well as separating authentication and smtp block list.

Thank you
Robert