MDaemon's XMPP server now supports persistent chat rooms, which do not need to be recreated every time all users leave the room. Configure them at: Setup | Web & IM Services | XMPP.
When on the Quarantine, Bad, or Spam Trap queue screens in the MDaemon GUI, a right-click popup menu option was added to report messages to MDaemon.com as false positives or false negatives. Similar options have also been added to MDaemon Remote Administration. The messages will be analyzed and passed along to third-party vendors for corrective action.
A GUI has been created to assist in running ASMC (ASMCUI.exe in MDaemon's \app\ folder). It allows you to store your options and recall them at a later time. ASMC supports migrating mail, calendars, tasks, notes, and contacts from ActiveSync servers that support protocol version 14.1. Documentation for it can be found in MDaemon's Docs folder, at: \MDaemon\Docs\ActiveSync Migration Client.html.
Greatly expanded and improved the Mobile Theme for Webmail users. See RelNotes.html located in MDaemon's \Docs\ folder for a complete list of the many features that have been added.
A significant number of improvements have been made to MDaemon's Cluster Service:
•Added a Multi-Node Mail Routing option, where mail queues are shared between the cluster nodes. Having multiple machines process and deliver the messages allows them to split the work more evenly and prevents messages from being stuck in the queues of any machines that are down.
•SSL certificates are now replicated from the primary to secondary nodes.
•Queues on secondary nodes are frozen during the initial data replication, which improves responsiveness during startup.
•Replication is paused as soon as MDaemon shutdown starts, eliminating clustering-related shutdown delays.
•Cluster nodes may be added using IP address or DNS name.
•The shared network paths can now be managed more easily from the new Shared Network Paths screen.
•Logging and diagnostics tools are provided on the new Diagnostics screen.
Dozens of options have been added to MDaemon's Remote Administration interface. For a complete list of these options and other changes to MDRA, see RelNotes.html located in MDaemon's \Docs\ folder.
Added ability to search for restricted files inside 7-Zip compressed files.
Autoresponders now support Unicode (UTF-8), allowing the text to be in any language.
IMAP filtering rules can now search the message body for particular text.
•You can now attach an event to a new email by right-clicking the event and choosing the "Send" option in the LookOut and WorldClient themes, and from the event preview in Mobile theme.
•All New Account Creation features have been removed.
•When you publish a calender (share a Public Access link to it), new options allow you set its default calendar view (e.g. month/week/day) and publish a Free/Busy calendar link.
•Added an option to skip the IP persistence check on a per user basis. In MDRA edit a user account, go to Web Services and check "Skip IP persistence check for Webmail sessions".
•Added ability to search the CC field in advanced search.
•Added Maximum Messages sent per day to the displayed quotas.
•Setup | Mobile Device Management has been removed and replaced by the ActiveSync Management dialog at Setup | ActiveSync.
•The ActiveSync Client Settings screen has been removed. Customize client settings on the Tuning, Domains, Groups, Accounts, and Clients screens.
•The ActiveSync Client Type screen has menu commands to whitelist and blacklist client types.
•Added screens at Setup | Message Indexing for the configuration of real-time and nightly maintenance of the search indexes used by Webmail, ActiveSync, and Remote Administration.
•Several plugins now share a common Diagnostics configuration screen.
•The MDRA and Webmail browser-based help systems have been updated with a new responsive theme, to make them more useable across different types of devices.
•The appearance of the XML API documentation portal can be customized globally and by domain. See the "Changes and development notes" in the help portal (ie. http[s]://ServerName[:MDRAPort]/MdMgmtWS) or view the file \MDaemon\Docs\API\XML API\Help_Readme.xml on disk using Internet Explorer for more information. A sample company.mail directory is provided at \MDaemon\Docs\API\XML API\Samples\Branding.
•Added Alias operation to simplify Alias management, resolve and report aliases.
•Added FolderOperation Search action to search messages.
•Added support for the Cluster Service to QueryServiceState and ControlServiceState.
•When a message is sent between local accounts, both "in" and "out" archive copies will be created if both "Archive inbound mail" and "Archive outbound mail" are enabled.
•The option to archive spam messages, which was removed in version 20.0, is back.
•Spam messages released from the Spam Trap are archived.
•MDaemon Connector has been updated to version 7.0.0.
•Spam Filter: updated to SpamAssassin 3.4.4. and removed deprecated settings in local.cf.
•AntiVirus: ClamAV updated to version 0.103.0, and Cyren AV engine updated to version 22.214.171.124.
•XMPP Server: Updated database backend to version SQLite 3.33.0.
For a comprehensive list of additions, changes and fixes included in MDaemon 21, see RelNotes.html located in MDaemon's \Docs\ subfolder.
MDaemon's new Cluster Service is designed to share your configuration between two or more MDaemon servers on your network. This makes it possible for you to use load balancing hardware or software to distribute your email load across multiple MDaemon servers, which can improve speed and efficiency by reducing network congestion and overload and by maximizing your email resources. It also helps to ensure redundancy in your email systems should one of your servers suffer a hardware or software failure. See: Cluster Service, for more information on setting up an MDaemon server cluster on your network.
The RequireTLS effort in IETF is finally finished, and support for this has been implemented. RequireTLS allows you to flag messages that must be sent using TLS. If TLS is not possible (or if the parameters of the TLS certificate exchange are unacceptable) messages will be bounced rather than delivered insecurely. RequireTLS is enabled by default, but the only messages that will be subject to the RequireTLS process are messages specifically flagged by a Content Filter rule using the new Content Filter action, "Flag message for REQUIRETLS...", or messages sent to <local-part>+email@example.com (for example, firstname.lastname@example.org). All other messages are treated as if the service is disabled. Additionally, several requirements must be met in order for a message to be sent using RequireTLS. If any of them fail, the message will bounce back rather than be sent in the clear. For more information about these requirements and how to set up RequireTLS, see: SMTP Extensions. For a complete description of RequireTLS, see: RFC 8689: SMTP Require TLS Option.
The MTA-STS effort in the IETF has finished, and support for this has been implemented. SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. MTA-STS support is enabled by default. See: SMTP Extensions for more information on setting this up, and MTA-STS is fully described in RFC 8461: SMTP MTA Strict Transport Security (MTA-STS).
TLS Reporting allows domains using MTA-STS to be notified about any failures to retrieve the MTA-STS policy or negotiate a secure channel using STARTTLS. When enabled, MDaemon will send a report daily to each STS-enabled domain that it has sent (or attempted to send) mail to that day. There are several options provided for configuring the information that your reports will contain. TLS Reporting is disabled by default and discussed in RFC 8460: SMTP TLS Reporting.
MDPGP now supports encrypting messages between domains using a single encryption key for all users. For example, suppose 'Domain-a' and 'Domain-b' wish to encrypt all emails sent between them but do not wish to setup and police individual encryption keys for every user account within the domain. This can now be done as follows:
'Domain-a' and 'Domain-b' each provide the other with a public encryption key via any method they like. For example, they can email the keys to one another by right-clicking on an existing public key in the MDPGP UI and selecting 'Export & Email Key.' If they wish to create new keys dedicated for this purpose they can click the 'Create keys for a specific user' button and choose the '_Domain Key (domain.tld)_ <email@example.com>' item which has been put there for this purpose (although any key will work). Once each side has received the other's key they click the 'Import Domain's Key' button on the MDPGP UI and enter the domain name to which all emails will be encrypted using the provided key. The system does not create a key in the dropdown list for every one of your domains. You can use the key that is provided for all your domains or you can create domain specific keys yourself if you wish.
If either side already has a public key they wish to use and it is already on the key-ring they can right-click on the key in the MDPGP UI and select 'Set as a Domain's Key'. However, do not use a key for which you also have the corresponding private key. If you do, MDPGP will encrypt a message and then immediately see that the decryption key is known and promptly decrypt that very same message.
At this point MDPGP creates a Content Filter rule called 'Encrypt all mail to <domain>' which will invoke the encryption operation on every email sent to that domain. Using the Content Filter means that you can control this process by enabling or disabling the Content Filter rule. You can also tweak the rule to fine-tune the criteria you wish to employ before messages are encrypted (for example, maybe you want to do this same thing but for two domains or for only certain recipients within the domain). The Content Filter provides the flexibility to achieve this.
MDPGP has a new checkbox and setup button where you can map IP addresses to specific encryption keys. Any outbound SMTP session delivering a message to one of these IPs will first encrypt the message using the associated key just prior to transmission. If the message is already encrypted by some other key no work is done. This is useful (for example) in situations where you want to make sure all messages sent to certain key partners, suppliers, affiliates, etc are always encrypted.
The Mailing List Editor » Routing screen has some new options which will allow for macros to be used within the message body of list posts. This will allow you (for example) to personalize each list message. Macros have been supported for a long time in list mail header and footer files, but they have never been supported in the message body. Since the macros are related to individual list members, this option is only compatible with lists that are configured to "Deliver list mail to each member individually." Additionally, for security purposes you can set this option to require that the list's password be provided in order to use macros in the message body. If you choose not to require a password, then any list member who is allowed to post to the list will be allowed to use them. See the Mailing List Routing screen for more information, and for the list of macros that can be used.
Hijack Detection has some new options to help prevent accounts from being used to blast out spam due to their passwords being stolen. One common characteristic of spam email is that the messages are often sent to a large number of invalid recipients, due to the spammer attempting to send them to old email addresses or otherwise guess new ones. Therefore if an MDaemon account begins sending messages to a notable number of invalid recipients in a short amount of time, that is a good indication that the account has been hijacked and is being used to send spam. To prevent this, MDaemon can now track the number of times that an authenticated user tries to send an email to an invalid recipient. If this happens too many times within too short of a time frame, you can have MDaemon freeze the account (the postmaster will get an email about this and they can respond to re-enable the account). This can help to stop a hijacked account automatically, before it does too much damage. Note: As part of this work, the From Header Modification options were moved to their own From Header Screening page, to make room for the new Hijack Detection options.
To help improve the efficiency of the Message Recall system and Deferred-Delivery header support, MDaemon now has a dedicated queue for deferred messages. Previously, the Inbound queue could become clogged with deferred messages, which could slow down the delivery of non-deferred mail. The new, Deferred queue helps to solve that problem. Messages in the Deferred queue are placed there by the system and have the date they are set to leave the queue encoded into the file name. MDaemon checks the queue once per minute and when it's time for messages to leave the queue they are moved to the Inbound queue and subject to normal message processing/delivery.
Additionally, MDaemon now tracks the Message-IDs of the most recent email sent by each authenticated local user, which means users can now recall the last message they sent (but only the last message they sent) simply by putting RECALL (alone by itself) as the Subject in a message sent to the mdaemon@ system account. There is no need to find and paste the Message-ID of the message you want to recall when it was the last message sent. Recalling any other message still requires the Message-ID be included in the Subject text or the original message from the users SENT folder attached to the recall request.
In addition to remembering the most recent email sent by each authenticated user, MDaemon also remembers the locations and Message-IDs of the last 1000 emails sent by all authenticated users. Consequently, this makes it possible to recall messages right out of user mailboxes even after they've been delivered. So, messages will disappear from user mail clients and phones if they are recalled. Note: this is of course only possible for messages sent to other local users; once MDaemon has delivered a message to some other server it is no longer under MDaemon's control and therefore cannot be recalled.
There is a new Authentication Failures log file that contains a single line with details for every SMTP, IMAP, and POP logon attempt that fails. The information includes the Protocol used, the SessionID so you can search other logs, the IP of the offender, the raw Logon value they tried to use (sometimes this is an alias), and the Account that matches the logon (or 'none' if no account matches).
There are several forwarding options in MDaemon where you can now add authentication credentials. This means that several files in the \APP\ folder (e.g. forward.dat, gateways.dat, MDaemon.ini, and all Mailing List .grp files) that now have the potential to contain obfuscated logon and password data in a weakly encrypted state. As always, you should therefore use the operating system tools at your command, as well as any other measures you choose, to secure the MDaemon machine and directory structure from unauthorized access. Authentication credential options were added to: Unknown Mail, Mailing List Routing, Gateway Editor » Forwarding, Gateway Editor » Dequeuing, and Account Editor » Forwarding.
Host Authentication is a new screen where you can configure port, logon, and password values for any host. When MDaemon sends SMTP mail to that host the associated credentials found here will be used. Please note that these credentials are a fallback and are only used when other more task-specific credentials are unavailable. For example, if you configure an Auth logon/password using the new Account Editor » Forwarding or Gateway Manager » Dequeuing options, then those credentials are used and they supersede what is configured here. This feature works with host names only (not IP addresses).
You can now specify a host, logon, password, SMTP return-path, and port for any remote queue. If provided, all messages in the queue are delivered using these new settings. However, by design it still remains possible for individual messages within the queue to have their own unique delivery data, which will take priority over these new settings. Additionally, you can now set up as many remote queues as you want, filter mail into them using the Content Filter based on whatever criteria you choose, give to each queue its own delivery schedule, and have completely different routing take place based on your wishes.
For some time Domain Sharing has performed lookups on SMTP MAIL sender values as needed. However, messages were often refused with 'Authentication Required' and yet there is no way authentication can be performed when the sender account resides on a different server. This has been addressed and MDaemon can accept mail without requiring authentication from accounts that are found to exist on other servers. This can be disabled with a new Security Manager option at: Sender Authentication » SMTP Authentication. If you would rather not perform Domain Sharing lookups on the SMTP MAIL sender at all you can completely disable that with a Domain Sharing option.
Domain Sharing also has a new option that enables sharing of mailing lists. When a message arrives for a mailing list a copy is created for each Domain Sharing host that also keeps a version of that list (a query is made to check). When these hosts receive their copies they will make delivery to all the members of that list which they serve. In this way mailing lists can be split across multiple servers with no loss in functionality. For this to work each Domain Sharing host must include the other hosts' IP addresses in their Trusted IPs configuration.
Finally, Domain Sharing has an Advanced button that opens a file where you can configure domain names that are allowed to use Domain Sharing. When nothing is in this file (the default condition) then all your domains can use Domain Sharing. See the instructions at the top of the file for more information.
Preferences » Miscellaneous has a new option that allows administrators to prevent account mail forwarding from sending emails outside the domain. If a user configures mail forwarding for their account to send to a foreign domain the message will be moved to the Bad Message queue. This setting only applies to messages that are forwarded using the mail forwarding options for the account.
Account Editor » Forwarding has a new Schedule button that will let accounts configure a schedule for when forwarding starts and stops. This is also included on the corresponding Account Templates screen. These settings configure the date and time forwarding starts and the date and time that it stops, but forwarding will only happen on the days of the week you select.
The Forwarding Address field in the New Accounts Template now works with account macros. The only macros with data at the point of new account creation however are those related to the account user's full name, domain, mailbox, and password values. So (for example) if you want every new account to forward to the same email address but at a different domain you can put this in the Forwarding Address field: $MAILBOXfirstname.lastname@example.org. Macros also work in the Send As, AUTH Logon, and AUTH Password fields.
Forwarding a message now updates the forwarding account's last access time. This means that accounts which do nothing else but forward mail are no longer potentially deleted for inactivity. Note: The forwarding must actually occur and not be defeated by other configuration options such as restrictions on where the forwarder can send mail or being 'off-schedule'. Just having a forwarding address configured will not automatically flag the account as active.
Sender Authentication » SMTP Authentication has two new options. First, the "Do not allow authentication on the SMTP port" option will completely disable AUTH support over the SMTP port. AUTH will not be offered in the EHLO response and will be treated as an unknown command if provided by the SMTP client. The other option is to "...add their IP to the Dynamic Screen if they attempt it anyway." This option will add to the Dynamic Screen the IP address of any client that attempts to authenticate when AUTH is disabled. The connection will also be immediately terminated. These settings are useful in configurations where all legitimate accounts are using the MSA (or other) port to submit authenticated mail. In such configurations the assumption is that any attempt to authenticate on the SMTP port must be from an attacker.
The Account Manager's filtering options have been expanded. You can now also choose to display accounts based on whether or not they are Enabled, are using MultiPOP, are near quota (70%), are near quota (90%), or are not forwarding. You can also search the account description field for any text you want and select accounts based on that. Further, the shortcut/right-click menu has new options to add or remove all the selected accounts from or to mailing lists and groups. It also has an option to Copy an existing account in order to create a new one. All settings of the existing account are copied to the new account except Full Name, Mailbox, Password, and Mail Folder. Finally, the Account Editor's IMAP Filters screen has a new button called Publish for adding a new rule to the account being edited and to every other account in that account's domain. This can save some time when a new rule is needed for everyone.
The Domain Manager's Host Name & IP screen has a new setting that lets you enable "Do Not Disturb" for a domain. When active, the domain will refuse all connections from all users for all services, but it will still accept incoming messages from the outside world. Further, you can schedule when 'Do Not Disturb' starts and stops. For example, if you configure May 1, 2020 to June 30, 2020 from 5:00pm to 7:00am, Monday thru Friday, then that means no mail services will be available for that domain's users on those days of the week beginning at 5:00pm and resuming at 7:01am, so long as the current date falls between May 1 and June 30, 2020. Erasing the scheduled start date deactivates the schedule and has the effect of putting the domain on 'Do Not Disturb' forever.
MDaemon's simple message archiving system has been changed to be more efficient and consistent. Archiving now work as follows: When a message is delivered from the Local Queue(s) to a user's mail folder an archive copy will be created at that time (in the 'IN' folder of the recipient, if so configured). When a message is picked up from the Remote Queue(s) for SMTP delivery (whether delivery succeeds or not) an archive copy will be created at that time (in the 'OUT' folder of the sender, if so configured). You will see lines like "ARCHIVE message: pgp5001000000172.msg" in the Routing log or you might see lines like "* Archived: (archives)\company.test\in\email@example.com\arc5001000000023.msg" in the Routing log when Local and Remote mail is processed. Further, a 'ToArchive' queue now exists as a system queue (not exposed in the UI). This queue is checked at regular intervals for messages which have been dropped there (manually, or by a plugin, or otherwise). When messages are found there they are immediately archived and deleted. If messages are found which are not eligible for archiving then they are simply deleted. The name of the queue is \MDaemon\Queues\ToArchive\. The Routing screen/log will show details whenever a message is successfully archived. Also, Archiving of encrypted messages is now handled more consistently. By default unencrypted copies of encrypted messages are stored in the archive. If a message can't be decrypted, the encrypted form will be stored instead. If you would rather have encrypted versions stored, then there is an option to allow you to do so. Additionally, there is now an option to archive messages sent to public folder submission addresses, which is enabled by default. Finally, the following types of messages are never archived: Mailing List traffic, Spam (the option to do so has been deprecated and removed), messages with viruses, system-level messages, and autoresponders.
MDaemon no longer creates empty log files. When items are disabled on the Settings screen their associated log file will not be created at startup. Log files that may already exist when an item is disabled are left in place (not removed). If a log file is missing when an item is enabled then the required log file will be created instantly. This change applies to all log files that the core MDaemon engine manages. Log files for Dynamic Screening, Instant Messaging, XMPP, WDaemon, and WebMail run external to MDaemon and therefore haven't changed. Several other logging-related changes include: making ATRN session logs look correct, making all logs consistent in colors and how they log Session and Child IDs, and the MultiPOP server no longer tears-up and tears-down sessions for accounts that are already over quota and therefore there is no longer wasteful logging in these cases. Finally, the Router log was only logging INBOUND and LOCAL queue message parsing. It now also logs REMOTE queue parsing when delivery attempts are made. This way you don't have to search the Router log and the SMTP(out) logs to see when a message was processed.
You can now configure MDaemon's Active Directory integration feature to create an MDaemon account when you add someone to an Active Directory group, and when you remove someone from an Active Directory group their corresponding MDaemon account will be disabled (but not deleted). To utilize this functionality, you must use an alternative Active Directory search filter. See: Active Directory » Authentication, for more information.
On Active Directory's Authentication screen there is now a separate "Contact search filter" option for contact searches. Previously, contact searching was done using the user search filter. There's also a separate test button for the contact search filter. Active Directory searches have been optimized so that when the search filters are identical a single query updates all data. When they are different two separate queries are necessary.
The following fields have been added to the ActiveDS.dat file templates, so that they are included in contact records when Active Directory monitoring creates or updates address books: abTitle=%personalTitle%, abMiddleName=%middleName%, abSuffix=%generationQualifier%, abBusPager=%pager%, abBusIPPhone=%ipPhone%, and abBusFax=%FacsimileTelephoneNumber%.
Public folder contacts are now deleted by default when the associated account is deleted from Active Directory. However, the contact is only deleted if it was created by the Active Directory integration feature. The setting to control this is located on the Active Directory Monitoring screen.
When the Active Directory monitoring system creates or updates an account and finds a mailbox value that is too long to fit in MDaemon's limited space for the mailbox value, it will truncate the mailbox value as before but now it will also create an alias using the full size mailbox value. Also, when an account or alias is created, the note's section of the account's Administrative Roles screen is updated for auditing purposes.
The Mailing List Manager's Active Directory screen now allows you to enter an Active Directory attribute for the full name field of list members.
Changes to account properties in Active Directory can trigger the recreation of an MDaemon account, even when the account was previously deleted within MDaemon. To keep accounts from being recreated in this way, a new option was added to Active Directory Monitoring. By default, accounts will not be recreated when they were manually deleted within MDaemon.
The "From Header Modification" options were moved from the Hijack Detection screen to their own From Header Screening screen, and new options were added. Such as, From Header Screening can now check "From:" header display-names for anything that looks like an email address. If one is found and it does not match the actual sending email address then the displayed address can be replaced with the actual email address. For example, if you are using this feature and the "From:" header looks like this: "From: 'Frank Thomas <firstname.lastname@example.org>' <email@example.com>" then it would be changed to: "From: 'Frank Thomas <firstname.lastname@example.org>' <email@example.com>".
MDaemon can now check a user's password against a compromised password list from a third-party service. It is able to do this without transmitting the password to the service, and if a user's password is present on the list it does not mean the account has been hacked. It means that someone somewhere has used the same characters as their password and it has appeared in a data breach. Published passwords may be used by hackers in dictionary attacks, but unique passwords that have never been used anywhere else are more secure. See Pwned Passwords for more information.
On the Security Settings' Passwords screen, MDaemon now has an option to prevent an account's password from being set to one that is found in the compromised passwords list. It can also check a user's password every certain number of days when they log in, and if it is found, send a warning email to the user and postmaster. The warning emails can be customized by editing message template files in the \MDaemon\App folder. Since instructions for how a user should change their password may depend on whether the account is using a password stored in MDaemon or using Active Directory authentication, there are two template files, CompromisedPasswordMD.dat and CompromisedPasswordAD.dat. Macros can be used to personalize the message, change the subject, change the recipients, etc.
With over 250 new features and improvements included in MDaemon 20, there are many not listed in this section. See RelNotes.html located in MDaemon's \Docs\ subfolder for a complete list of all new features, changes, and fixes included in this version.
Webmail's Mobile theme has been replaced with a more modern GUI with more features. Message list features now include personalized categories, message snooze, sort by flagged/unread/snoozed, sort columns, and message recall. Calendar features now include Import/Export events as csv or ics files, add external calendars, private access links, publish calendar, and view multiple calendars at one time. Compose features now include deferred delivery, multiple signatures, text/html messages, and email templates. Other features include drag and drop email filters, multiple signatures editor, more folder management options, notifications, drag and drop column management, drag and drop categories management, and more. If running Webmail in IIS, additional configuration steps are needed to utilize the new mobile theme. See Knowledge Base article 1236 for more information.
You can now configure an email signature to be pushed to Webmail and MDaemon Connector for your users. A Default Client Signature can be set or it can be set per domain on the Domain Manager's Client Signatures screen. Use signature macros such as $CONTACTFULLNAME$, $CONTACTEMAILADDRESS$, to personalize the signature with data pulled from the user's contact in the domain's Public Contacts folder. Use the $ATTACH_INLINE:filename$ macro for inline images in the HTML signature. After entering signature text, it will appear in Webmail's Compose options as the "System" signature, and will become the user's default signature. It can be enabled/disabled for Webmail by default under the Webmail Settings, or per domain on the Domain Manager. For MDaemon Connector, the signature's name and related settings can be configured on the MC Client Settings' Signature screen. This feature requires MDaemon Connector 6.5.0 or newer.
MDaemon's Remote Administration (MDRA) interface now has a Categories page under the Webmail options, for configuring Domain Categories and default Personal Categories.
Many options that previously could only be managed through MDaemon's application interface have been added to MDRA. For a complete list, see the Release Notes.
MDaemon now supports the Server Name Indication (SNI) extension to the TLS protocol, which allows a different certificate to be used for each of your server's host names. MDaemon will look at the active certificates and choose the one that has the requested host name in its Subject Alternative Names field (you can specify the alternate names when creating the certificate). If the client does not request a host name, or if no matching certificate is found, then the default certificate is used.
The XML-API has been expanded to include the ability to manage mailbox folders and items in the folders. Folders can be created, deleted, renamed, and moved using the API. Item operations support email, calendar, contacts, tasks, and notes. Items can be created, deleted, and moved using the API. Full documentation can be found in the MDaemon\Docs\API\XML-API\ folder.
MDaemon's Remote Administration (MDRA) web interface has been further expanded to include access to features that formerly could only be administered using a Configuration Session (i.e. MDaemon's application interface), and there are now several options that can only be accessed via MDRA. Consequently, for new MDaemon installations, the "Start MDaemon" Start Menu shortcut will now open a browser to MDaemon Remote Administration by default rather than opening an MDaemon Configuration Session. If you wish to change this, edit \MDaemon\App\MDaemon.ini and set [MDLaunch] OpenConfigSession=Yes/No and OpenRemoteAdmin=Yes/No. Set the Remote Administration URL at Setup » Web & IM Services » Remote Administration » Web Server if the auto-generated URL does not work or if MDRA runs in an external web server. If a working URL cannot be determined, a Configuration Session will be opened instead. Finally, under the Windows Start menu, in the MDaemon program group, there are now shortcuts to Open MDaemon Configuration Session and Open MDaemon Remote Administration.
•Webmail users with their Show Saved Search Folders option enabled (located in Webmail under Options » Folders) will now be asked if they wish to add an "All Unread" and an "All Flagged" Saved Search folder to their list. They will be asked only one time, the first time they sign-in. If a user chooses "No", he or she can still easily create those Saved Searches manually by clicking the Create All Unread Saved Search and Create All Flagged Saved Search buttons (also located under Options » Folders). Administrators can prevent Webmail from asking users if they wish to create those searches by adding DefaultSavedSearchesCheck=Yes under [Default:UserDefaults] in the MDaemon\WorldClient\Domains.ini file.
•Modified some WorldClient theme icons to make them easier to see.
•Added "(EXPIRED)" to the browser tab title when the session expires, so that if a user is not in the Webmail tab the user will still know that the session expired.
•Added a delete icon for removing common contacts from the autocomplete list.
MDaemon signatures now support macros that insert the sender's contact information into the signature, taken from the sender's contact located in its domain's Public Contacts folder. This allows default and domain signatures to be personalized with the sender's information. $CONTACTFULLNAME$, for example, inserts the sender's full name, and $CONTACTEMAILADDRESS$ inserts the sender's email address. Use Webmail, MDaemon Connector, or ActiveSync to edit the public contacts. Blank values are used if no contact exists for the sender. Available macros are listed on the Default Signatures page.
Users can also control the placement of MDaemon signatures in their messages by using the $SYSTEMSIGNATURE$ macro to place the default/domain signature and $ACCOUNTSIGNATURE$ to place the account signature.
The WorldClient and LookOut themes now feature a browser-based XMPP client that lets users instant message without needing to run the MDaemon Instant Messenger desktop application or some other XMPP client application. Users can enable it from Webmail's Options | Personalize screen, using the "Enable MDaemon's Instant Messaging feature in browser" option. Admins can enable or disable instant messaging per domain using the Domain Manager, per account using the Account Editor, or per group using the Group Manager.
MDaemon includes a new BOSH server to support instant messaging in Webmail. Its settings can now be configured on the XMPP screen (new in 18.5.1).
Added a user option in Webmail to exempt Two Factor Authentication logins from Location Screening. If a user has BypassLocationScreeningTFA=Yes in the [User] section of their User.ini file, and Two Factor Auth is enabled for the user, Location Screening is bypassed. This allows users to login to Webmail in countries that would normally be blocked by Location Screening.
Users whose accounts are set to use Active Directory (AD) authentication can now change their AD password in Webmail if the "AllowADPasswordChange" setting is enabled in \MDaemon\WorldClient\Domains.ini. It is disabled by default.
MDaemon's Remote Administration (MDRA) web interface has been expanded to include access to many features that formerly could only be administered using MDaemon's graphical user interface.
The new DNSSEC (DNS Security Extensions) option allows MDaemon to act as a Non-Validating Security-Aware Stub Resolver, which is defined in RFCs 4033 and 4035 as "an entity that sends DNS queries, receives DNS responses, and is capable of establishing an appropriately secured channel to a security-aware recursive name server that will provide these services on behalf of the security-aware stub resolver." What this means is that during MDaemon's DNS queries in can request DNSSEC service from your DNS servers, setting the AD (Authentic Data) bit in the queries and checking for it in the answers. This can provide an additional level of security during the DNS process for some messages, although not all, because DNSSEC is not yet supported by all DNS servers or for all top-level domains.
When enabled, DNSSEC service is only applied to messages that meet your selection criteria; it can be requested or required as broadly or narrowly as you choose. Simply designate any "Header Value" combinations you choose on the DNSSEC screen and MDaemon will request DNSSEC service for any messages matching that criteria whenever performing a DNS query. When the DNS results fail to include authenticated data then no negative consequences result; MDaemon simply falls back to normal DNS behavior. If, however, you wish to require DNSSEC for certain messages, add "SECURE" to the header/value combination (e.g. To *@example.net SECURE). For those messages, when the DNS results fail to include authenticated data, the message will be bounced back to the sender. Note: Because DNSSEC lookups take more time and resources, and because DNSSEC is not yet supported by all servers, MDaemon is not configured to apply DNSSEC to every message delivery by default. However, if you wish to request DNSSEC for every message you can do so by included "To *" in your criteria.
There is a new Scan all messages every [n] day(s) option under Security » AntiVirus that can be used to scan all stored messages periodically, to detect any infected message that may have passed through the system before a virus definition update was available to catch it. Infected messages will be moved to the quarantine folder and have the X-MDBadQueue-Reason header added, so that you can see an explanation when viewed in MDaemon. Messages that cannot be scanned will not be quarantined. There is also a Configure mailbox scan option to specify how often you wish to scan the messages and whether you wish to scan all message or only those that are less than a certain number of days old. You can also manually run a mailbox scan immediately.
Enable the new Exempt from Location Screening option on an ActiveSync client's settings screen if you want the device to be able to bypass Location Screening. This makes it possible for a valid user to continue to access his or her account via ActiveSync when, for example, traveling to a location that is otherwise blocked from authentication attempts. In order to exempt the device it must have connected and authenticated using ActiveSync within the time-frame configured in the Remove inactive clients after this many days setting located on the Tuning screen. When exempting a device from Location Screening, there is also an option to whitelist the remote IP address from which it is connecting. This can be useful for allowing other clients that might be connecting from the same IP address.
You can now add a "Remember Me" checkbox to the sign-in pages of MDaemon Webmail and MDaemon Remote Administration (MDRA), via options located on the Webmail Settings screen and MDRA Web Server screen, respectively. When this option is enabled, users who sign-in via the https port will see the checkbox. If users check this box then their credentials will be remembered for that device. Then any time they use that device to connect to Webmail or MDRA in the future they will be signed in automatically, until such time that they manually sign out of their account or their Remember Me token expires. The Remember Me option is disabled by default and applies to all of your domains. If you wish to override this setting for specific Webmail domains then use the Remember Me setting located on the Domain Manager's Webmail screen in MDaemon's desktop interface.
By default, users' credentials will be remembered for 30 days before they are forced to sign-in again, but you can use the Expire Remember Me tokens after this many days option (located in MDRA) to designate a different number of days if you choose. You can set this option up to 365 days. Note: Two-Factor Authentication (2FA) has its own Remember Me expiration key (TwoFactorAuthRememberUserExpiration=30), located in the [Default:Settings] section of the Domains.ini file, located in the \MDaemon\WorldClient\ folder. Therefore 2FA will again be required at sign-in when the 2FA Remember Me token expires, even if the regular token is still valid.
In MDRA there is also a Reset Remember Me button that you can use if you suspect that an account may have had a security breach. This will reset the Remember Me tokens for all users, causing them to have to sign-in again.
In MDaemon Webmail you can now snooze an email in your message list. A snoozed message will be hidden from you for a designated period of time. To snooze a message, right click on it and choose the "Snooze for..." option in the context menu. Then choose how long you wish to snooze the message. The "Choose a date and time" option is only available for browsers that support the date and time inputs. Hidden messages can be viewed in the LookOut theme by clicking the "View Snoozed Messages" icon in the toolbar and the WorldClient theme by choosing "view snoozed" from the view drop-down menu in the toolbar. This feature is on by default. To turn off the feature, go to Options | Personalize in Webmail and find the Inbox Settings. Uncheck the "Enable Message Snooze" box. There are no snooze controls in Lite and Mobile theme, but snoozed messages are still hidden.
In MDaemon Webmail users can now publish a calendar to a publicly accessible link, and they have the option to password-protect the calendar. To publish a calendar, in Webmail's LookOut or WorldClient theme go to Options | Folders and click the "Share Folder" button next to the calendar you wish to publish. Then, open the Public Access tab and, if desired, fill in the display name or require a password, then click the "Publish Calendar" button. A confirmation dialog will be displayed, and after clicking OK an alert will display the new URL where the calendar is available. There will also be a link displayed on the page once the calendar has been published. To unpublish the calendar, click the "Unpublish Calendar" button. To change the password or the display name, click the "Update" button.
If you wish to disable this globally, change the value of the EnablePublicCalendars key to No in the [Default:Settings] section of the Domains.ini file. To disable it on a per user basis, add CanPublishCalendars=No to a user's User.ini file.
Location Screening is a geographically based blocking system that you can use to block incoming SMTP, POP, IMAP, Webmail, ActiveSync, AutoDiscovery, XML API, Remote Administration, CalDAV/CardDAV, XMPP, and Minger connections from unauthorized regions of the world. MDaemon determines the country associated with the connecting IP address and then blocks that connection if it is from a restricted location, and adds a line to the Screening log. For SMTP, Location Screening can optionally block only connections using AUTH. This is useful, for example, if you have no users in a specific country but still wish to be able to receive mail from there. That way you would only block those attempting to log in to your server.
The \MDaemon\Geo\ folder contains database files that serve as the master country IP database. The files were provided by MaxMind (www.maxmind.com), and updates can be downloaded from their site if desired.
MDaemon's Dynamic Screening system has been greatly expanded to operate with SMTP, POP, IMAP, Webmail, ActiveSync, AutoDiscovery, XML API, Remote Administration, CalDAV/CardDAV, XMPP, and Minger. Authentication failures are tracked across all of these services and IPs addresses can be blocked for all of them. Dynamic Screening can be configured on its new, multi-tabbed dialog under the Security menu.
PIM (calendar, contact, tasks, notes) items now support attachments. Attachments can be added to a PIM item via Webmail, Outlook Connector, or CalDAV/CardDAV. When scheduling a meeting, any attachments will be sent to the meeting attendees.
The MDPGP dialog contains a new option to enable the automatic transmission of public keys as part of the SMTP message delivery process. To do so, MDaemon's SMTP server will honor an SMTP command called RKEY. When sending an email to a server that supports RKEY, MDaemon will offer to transmit the sender's current, preferred public-key to the other host. That host will respond indicating that it either already has that key ("250 2.7.0 Key already known") or that it needs that key, in which case the key is immediately transferred in ASCII armored form ("354 Enter key, end with CRLF.CRLF") just like an email message. Keys that are expired or revoked are never transmitted. If MDaemon has multiple keys for the sender it will always send the key that is currently marked as preferred. If no key is preferred then the first one found is sent. If no valid keys are available then nothing is done. Only public-keys that belong to local users are offered.
Public-key transfers happen as part of the SMTP mail session that delivers the message from the user. In order for the public-keys transmitted in this way to be accepted, the public-key must be sent along with a message that has been DKIM signed by the domain of the key owner with the i= set to the address of the key owner, which also must exactly match the From: header address of which there can be only one. The "key owner" is taken from within the key itself. Also, the message must arrive from a host in the sender's SPF path. Finally, the key owner (or his entire domain via use of wildcards) must be authorized for RKEY by adding an appropriate entry to the MDPGP rules file (instructions are in the rules file for this) indicating that the domain can be trusted for key exchange. All this checking is done automatically for you but you must have DKIM and SPF verification enabled or no work can be done.
The MDPGP log shows the results and details of all keys imported or deleted, and the SMTP session log also tracks this activity. This process tracks the deletion of existing keys and the selection of new preferred keys and updates all participating servers it sends mail to when these things change.
Using the new Add-ins screen on the OC Client Settings dialog, you can manage the state of the Outlook Add-ins used by your Outlook Connector users. You can allow any or all of the add-ins to be used normally, or you can disable any that you choose. This feature can be especially useful in cases where you know of a specific add-in that conflicts with the Outlook Connector Client, allowing you to disable that add-in to avoid problems. The Add-ins feature requires Outlook Connector 5.0 or newer.
In the LookOut and WorldClient themes, an option was added to export and import Groups/Distribution Lists from and to a contact folder in Webmail. The format is MDaemon Webmail specific, since Outlook does not support exporting and importing Groups. The format is as follows:
Columns: Group GUID, Group Name, GUID, Full Name, Email
Each line that contains either a Group Name or a Group GUID is considered the beginning of a new group. Any GUID, Full Name or Email on that line is considered the first member of the group/list.
Example from Excel:
When importing, the Group GUID is replaced with a freshly generated GUID. If no Group Name is included, the name will be displayed without translation as "ImportedFromCSV_%GUID%", where %GUID% is replaced with the first five characters of the GUID. Leaving the cells to the right of a group name empty will result in the next line being the first member of the group/list. The Email field is required for a member to be added.
Voice Recording was added to the Lookout and WorldClient themes. This feature requires a microphone and is only available in certain browsers. It can be disabled by the admin on a per user basis by adding EnableVoiceRecorder=No to the User.ini. Users are limited to five tracks of five minutes each. Attempting to record more than five tracks in a Voice Recorder session will result in either the selected track or the first track being replaced by the new recording (the user will be prompted). After recording is stopped (either automatically or by the user), the track is converted to an mp3 and uploaded to the server. Users have four options regarding each track:
•Save to the desktop
•Save to default WorldClient documents folder
•Send in an email using a quick dialog that only includes To, CC, BCC, Subject, and a plain/text Message Body
Only the To is required. There are generic Subject and Message Body phrases used when no Subject or Message Body is input by the user.
•Open a new Compose view with the track attached
Users can only act on one track at a time. For example, only one track can be attached to a message. If a user wants to attach multiple tracks to a message, the user will need to save each track to the default documents, and do the attaching from there.
The LookOut and WorldClient themes have new folder management features in the Options » Folders view and in the main folder list view.
In the folder list view (left pane):
•Users can drag and drop to move folders from one parent folder to another.
•Users can rename folders and give favorites nicknames by clicking on them a second time (shortly after folder selection)
•Show Folders by Type is now available in the LookOut theme
•If there is already at least one favorite folder (because favorites are hidden until one is added), users can drag and drop a folder to favorites in order to add it (dragging a folder out of the favorites does nothing).
•The new folder and rename folder dialogs were added to the LookOut theme
In the Options » Folders view, the folder tree is now collapsible, and the New Folder dialog has been moved to an external window like in the WorldClient theme.
WCIM now uses the XMPP protocol for instant messaging instead of WorldClient's proprietary protocol. This allows the WCIM desktop client to communicate not only with other WCIM clients, but any third-party XMPP clients (including mobile clients) connected to your MDaemon's XMPP server. Additionally, WCIM now has two types of connections: "WCMailCheck" and "WCIMXMPP." WCMailCheck connects to WorldClient for new mail notifications and message counts. WCIMXMPP connects to the XMPP server for instant messaging. Consequently, WCIM users will now have an entry for each type of connection listed on the Connections screen of the client (e.g. "Example.com Mail" and "Example.com WCIM"). When updating to version 17, WCIM will automatically create a WCIMXMPP connection to go with your already existing WCMailCheck connection, and it will migrate your IM contacts from the old system to XMPP. The look and feel of the new WCIM client is essentially the same, but there are some differences, such as how contacts and group chats are managed. See the WCIM client's Help system for more info about what has changed.
WorldClient is new equipped with direct support for Dropbox, which allows your users to save file attachments to their Dropbox accounts, and to insert direct links to Dropbox files in outgoing messages. To provide this feature to your WorldClient users, you must set up your WorldClient as a Dropbox app on the Dropbox Platform. This is a simple process, requiring you only to sign in to a Dropbox account, create a unique name for an app with Full Dropbox access, specify the Redirect URI to WorldClient, and change one default setting. Then, you will copy and paste the Dropbox App Key and App Secret from there to the options on Dropbox screen in MDaemon. After that your users will be able to link their Dropbox accounts to WorldClient when they next sign in to WorldClient. For step-by-step instructions on how to create your Dropbox app and link it to WorldClient, see: Creating and Linking Your Dropbox App.
When you create your Dropbox app it will initially have "Development" status. This allows up to 500 of your WorldClient users to link their Dropbox accounts to the app. According to Dropbox, however, "once your app links 50 Dropbox users, you will have two weeks to apply for and receive Production status approval before your app's ability to link additional Dropbox users will be frozen, regardless of how many users between 0 and 500 your app has linked." This means that until you receive production approval, Dropbox integration will continue to work but no additional users will be able to link their accounts. Obtaining production approval is a straightforward process to ensure that your app complies with Dropbox's guidelines and terms of service. For more information, see the Production Approval section of the Dropbox Platform developer guide.
Once your WorldClient app is created and configured properly, each WorldClient user will be given the option to connect their account to their Dropbox account when they sign in to WorldClient. The user is required to log in to Dropbox and grant permission for the app to access the Dropbox account. Then the user will be redirected back to WorldClient using a URI that was passed to Dropbox during the authentication process. For security that URI must match one of the Redirect URIs you specified on your app's info page at Dropbox.com. Finally, WorldClient and Dropbox will exchange an access code and access token, which will allow WorldClient to connect to the user's Dropbox account so that the user can save attachments there. The exchanged access token expires every seven days, meaning that periodically the user must reauthorize the account to use Dropbox. Users can also manually disconnect their account from Dropbox, or reauthorize it when necessary, from the Cloud Apps options screen within WorldClient.
To support SSL/TLS and HTTPS for MDaemon, WorldClient, and Remote Administration, you need an SSL/TLS Certificate. Certificates are small files issued by a Certificate Authority (CA) that are used to verify to a client or browser that it is connected to its intended server, and that enable SSL/TLS/HTTPS to secure the connection to that server. Let's Encrypt is a CA that provides free certificates via an automated process designed to eliminate the currently complex process of manual creation, validation, signing, installation, and renewal of certificates for secure websites.
To support using Let's Encrypt's automated process to manage a certificate, MDaemon includes a PowerShell script in the "MDaemon\LetsEncrypt" folder. A dependency of the script, the ACMESharp module v2, requires PowerShell 5.1 and .Net Framework 4.7.2, which means the script will not work on Windows 2003. Additionally, WorldClient must be listening on port 80 or the HTTP challenge cannot be completed and the script will not work. You will need to correctly set the execution policy for PowerShell before it will allow you to run this script. Running the script will set up everything for Let's Encrypt, including putting the necessary files in the WorldClient HTTP folder to complete the http-01 challenge. It uses the SMTP host name of the default domain as the domain for the certificate, retrieves the certificate, imports it into Windows, and configures MDaemon to use the certificate for MDaemon, WorldClient, and Remote Administration.
If you have an FQDN setup for your default domain that does not point to the MDaemon server, this script will not work. If you want to setup alternate host names in the certificate, you can do so by passing the alternate host names on the command line.
..\LetsEncrypt.ps1 -AlternateHostNames mail.domain.com,wc.domain.com -IISSiteName MySite -To "firstname.lastname@example.org"
You do not need to include the FQDN for the default domain in the AlternateHostNames list. For example, suppose your default domain is "example.com" configured with an FQDN of "mail.example.com", and you want to use an alternate host name of "imap.example.com". When you run the script, you will only pass "imap.example.com" as an alternate host name. Further, if you pass alternate host names, an HTTP challenge will need to be completed for each one. If the challenges are not all completed then the process will not complete correctly. If you do not want to use any alternate host names then do not include the –AlternateHostNames parameter in the command line.
If you are running WorldClient via IIS, you will need to pass this script the name of your site using the -IISSiteName parameter. You must have Microsoft's Web Scripting tools installed in order for the certificate to be automatically setup in IIS.
Finally, the script creates a log file in the "MDaemon\Logs\" folder, called LetsEncrypt.log. This log file is removed and recreated each time the script runs. The log includes the starting date and time of the script but not the date and time stamp for each action. Also, notification emails can be sent when an error occurs. This is done using the $error variable, which is automatically created and set by PowerShell. If you do not wish to have email notifications sent when an error occurs, do not include the –To parameter in the command line.
There is a new Password option to store mailbox passwords using non-reversible encryption. This protects the passwords from being decrypted by MDaemon, the administrator, or a possible attacker. When enabled, MDaemon uses the bcrypt password hashing function, which allows for longer passwords (up to 72 characters), and for passwords to be preserved yet not revealed when exporting and importing accounts. Some features, however, are not compatible with this option, such as weak password detection and APOP & CRAM-MD5 authentication, because they depend on MDaemon being able to decrypt passwords. Non-reversible passwords is enabled by default.
There is a new ActiveSync setting that you can use to require that "New clients must be authorized by an administrator prior to synchronizing" with an account. The Clients list indicates any clients awaiting authorization, and the administrator can authorize them from the same screen. This option is available on the Global and Account client settings screens. The global option is Off by default and the account option is set to "Inherit."
Two types of administrative notifications have been added to ActiveSync: Sync Rollback Notifications and Corrupt Message Notifications.
The ActiveSync Service can now notify the administrators if a client is repeatedly/frequently sending expired Sync Keys in Sync operations.
These merely inform the admin that the server issued a rollback for a given collection because a client made a sync request with the most recently expired Sync Key. The subject states "ActiveSync Client Using expired Sync Key". This could occur because of a network issue or something about the content previously sent to the client in that collection. In some cases, the item ID will be there, it merely depends upon whether or not the previous sync on that collection sent any items.
Rollback warnings do not mean the client is out of Sync, it means that the client has the potential to go out of Sync and our internal system detected it. Rollback warnings are issued for a collection no more than once per 24 hour period. The following keys can be edited under the [System] header in the \MDaemon\Data\AirSync.ini file:
•[System] SendRollbackNotifications=[0|1|Yes|No|True|False] (Default is disabled)
•[System] RollbackNotificationThreshhold=[1-254] : The number of rollbacks that must occur on a given collection prior to a notification being sent to the admin. We recommend a value of at least 5 here, since Network hiccups play a part in this. (Default is 10)
•[System] RollbackNotificationCCUser=[0|1|Yes|No|True|False] : Whether or not to CC the user whose client sent that expired Sync Key. (Default is disabled)
The ActiveSync Service can now notify the administrators if a particular message cannot be processed. These are sent in real time to inform the admin of a mail item that could not be parsed and that further action on this item is not possible. The subject states "Corrupt message notification". These items, in previous versions, could lead to a crash. In most cases, the content of the msg file will not be MIME data. If it is MIME data, it is likely corrupt. You can choose to CC the affected user of these notifications with the CMNCCUser key so that they are aware that an email has arrived in their mailbox that is un-readable. The appropriate action for these is to move the designated msg file from the user's mailbox and analyze it to determine both why it is not able to be parsed and how it came to exist in the state that it is in. The following keys can be edited under the [System] header in the \MDaemon\Data\AirSync.ini file:
•[System] SendCorruptMessageNotifications=[Yes|No|1|0|True|False] (Default is Enabled)
•[System] CMNCCUser==[0|1|Yes|No|True|False] (Default is Enabled)
WorldClient can now act as a basic public-key server. Enable the new MDPGP option to "Send public-keys over HTTP (WorldClient)" and WorldClient then will honor requests for your users' public-keys. The format of the URL to make the request looks like this: "http://<WorldClient-URL>/WorldClient.dll?View=MDPGP&k=<Key-ID>". Where <WorldClient-URL> is the path to your WorldClient server (for example, "http://wc.example.com") and <Key-ID> is the sixteen character key-id of the key you want (for example, "0A1B3C4D5E6F7G8H"). The key-id is constructed from the last 8 bytes of the key fingerprint - 16 characters in total.
Enable the new MDPGP option to "Collect public-keys from DNS (pka1) and cache for [xx] hours" if you want MDPGP to query for message recipient public-keys over DNS using PKA1. This is useful because it automates the process of obtaining some recipients' public keys, preventing you or your users from having to obtain and import them manually in order to send encrypted messages. When PKA1 queries are made, any key URI found is immediately collected, validated, and added to the key-ring. Keys successfully collected and imported to the key-ring using this method will automatically expire after the number of hours specified in this option or according to the TTL value of the PKA1 record that referred them, whichever value is greater.
MDPGP now always tracks keys by their primary key-ids rather than sometimes by the key-id and other times the sub-key-id. Consequently, the MDPGP dialog's list of keys was cleaned up to remove two unnecessary columns. Further, MDPGP now more strictly controls the contents of its "exports" folder. As a result you will always find exported copies of local user keys there. Even though the private keys are encrypted, for extra security you should use OS tools to protect this folder (and indeed the entire PEM folder structure) from unauthorized access.
Previously, when multiple different keys for the same email address were found in the key-ring, MDPGP would encrypt messages using the first one that it found. Now you can right-click on any key and set it as preferred, so that MDPGP will use that key when multiple keys are found. If no preferred key is declared, MDPGP will use the first one found. When decrypting a message MDaemon will try each one.
Disabled and deleted keys are now tracked in a new file called oldkeys.txt. Previously, disabled keys were tracked in the plugins.dat file.
MDPGP can now verify embedded signatures found within messages that are not encrypted. Previously it was not able verify signatures unless the message was both signed and encrypted. When viewing a message with a verified signature in WorldClient, a new icon is displayed to indicate it was verified. Signature verification is enabled by default for all non-local users, or you can specify exactly which email addresses can and cannot use the service (see: "Configure exactly who can and can not use MDPGP services" on the MDPGP dialog).
MDaemon is now equipped with an Extensible Messaging and Presence Protocol (XMPP) server, sometimes called a Jabber server. This allows your users to send and receive instant messages using third-party XMPP clients, such as Pidgin, Gajim, Swift and many others. Clients are available for most operating systems and mobile device platforms. MDaemon's XMPP instant messaging system is completely independent of MDaemon's WorldClient Instant Messenger chat system; the two systems cannot communicate with each other and do not share buddy lists.
The XMPP server is installed as a Windows service, and the default server ports are 5222 (SSL via STARTTLS) and 5223 (dedicated SSL). The XMPP server will use MDaemon's SSL configuration if it is enabled in MDaemon. Also, some XMPP clients use DNS SRV records for auto-discover of host names. Please refer to http://wiki.xmpp.org/web/SRV_Records for more information.
Users sign-in through their chosen XMPP client using their email address and password. Some clients, however, require the email address to be split into separate components for signing in. For example, instead of "email@example.com," some clients require you to use "frank" as the Login/Username and "example.com" as the Domain.
For multi-user/group chat service, clients typically display this as "rooms" or "conferences." When you want to start a group chat session, create a room/conference (giving it a name) and then invite the other users to that room. Most clients don't require you to enter a server location for the conference; you only need to enter a name for it. When you are required to do so, however, use "conference.<your domain>" as the location (e.g. conference.example.com). A few clients require you to enter the name and location together in the form: "room@conference.<your domain>" (e.g. Room01@conference.example.com).
Some clients (such as Pidgin), support the user search service, allowing you to search the server for users by name or email address, which makes adding contacts much easier. Usually you will not have to provide a search location, but if asked to do so, use "search.<your domain>" (e.g. search.example.com). When searching, the % symbol can be used as a wildcard. Therefore you could use "%@example.com" in the email address field to display a list of all users with an email address ending in "@example.com."
Use the OC Client Settings dialog to centrally manage the client settings of your Outlook Connector users. Configure each screen with your desired client settings and MDaemon will push those settings to the corresponding client screens as necessary, each time an Outlook Connector user connects to the server. The OC Client Settings are only sent to clients when one of the settings has changed since the last time the client connected and received them. If you enable the provided option to "Allow OC users to override pushed settings," users can override any pushed settings on their individual clients. If that option is disabled, then all of the client screens are locked; Outlook Connector users can make no changes.
To allow for certain settings that must be different for each user or domain, OC Client Settings supports macros such as $USERNAME$, $EMAIL$, and $DOMAIN$. These macros will be converted to data specific to the user or domain when pushing settings to a client. Take care not to place any static values in any fields that should use a macro, such as putting something like "Frank Thomas" in the Your Name field. To do so would cause every Outlook Connector user who connects to MDaemon, to have his or her name set to "Frank Thomas." For your convenience there is a Macro Reference button on the General screen, which displays a simple list of the supported macros.
For those using MDaemon Private Cloud (MDPC), there is another OC Client Settings dialog on the Domain Manager, for controlling the Outlook Connector client settings on a per domain basis.
This feature is disabled by default, and works only for those using Outlook Connector client version 4.0.0 or higher.
This new security feature modifies the "From:" header of incoming messages to cause the name-only portion of the header to contain both the name and email address. This is done to combat a common tactic used in spam and attacks where the message is made to appear to be coming from someone else. When displaying a list of messages, email clients commonly display only the sender's name rather than the name and email address. To see the email address, the recipient must first open the message or take some other action, such as right-click the entry, hover over the name, or the like. For this reason attackers commonly construct an email so that a legitimate person or company name appears in the visible portion of the "From:" header while an illegitimate email address is hidden. For example, a message's actual "From:" header might be, "Honest Bank and Trust" <firstname.lastname@example.org>, but your client might display only "Honest Bank and Trust" as the sender. This feature changes the visible portion of the header to display both parts, with the email address given first. In the above example the sender would now appear as "email@example.com -- Honest Bank and Trust," giving you a clear indication that the message is fraudulent. This option only applies to messages to local users, and it is disabled by default.
The IP Screen now contains an Import button that you can use to import IP address data from an APF or .htaccess file. MDaemon's support for these files is currently limited to the following:
•"deny from" and "allow from" are supported
•only IP values are imported (not domain names)
•CIDR notation is allowed but partial IP addresses are not.
•Each line can contain any number of space-separated or comma-separated IP addresses. For example, "deny from 126.96.36.199 188.8.131.52/16", ""184.108.40.206, 220.127.116.11, 18.104.22.168", and the like.
•Lines starting with # are ignored.
Using the Automatic Updates features you can configure MDaemon to inform the postmaster whenever an update is available for one of your installed products, or you can download and install updates automatically. This includes MDaemon, SecurityPlus, and Outlook Connector. Automatically installing updates can be controlled separately for each product, and a server reboot is required each time an update is installed. Installer files are downloaded when the update is detected, but the installation and reboot occur later at whichever hour you have designated. All installation activity is logged in the MDaemon system log, and the postmaster is informed after an update has occurred. See the Updates dialog for more information.
WorldClient supports categories for email in the LookOut and WorldClient themes. Users can add the Categories column to the message list by going to "Options » Columns" and checking "Categories" in the Message List section. To select categories for one or multiple messages, select the messages and right-click one of them. Use the context menu to set the category.
•Administrators can create custom categories. There are two files for this purpose: DomainCategories.json and PersonalCategories.json.
•Domain Categories are enabled globally by default. To disable them open MDaemon\WorldClient\Domains.ini, and in the [Default:Settings] section change the value of "DomainCategoriesEnabled=" from "Yes" to "No".
•Users are able to add and edit their own categories by default. If you wish to disable this option, you can do so per user or globally by changing the value of "CanEditPersonalCategories=" from "Yes" to "No". The user option is located in the [User] section of the User.ini file and the global option is in the Domains.ini file under the [Default:UserDefaults] section.
•If Domain Categories are enabled, and a user is not allowed to edit personal categories, the user will only see the categories listed in DomainCategories.json.
•If Domain Categories are disabled, and a user is not allowed to edit personal categories, the user will see the categories listed in PersonalCategories.json.
•The file CustomCategoriesTranslations.json is used to support your custom category names in multiple languages. Add any necessary custom category translatations to that file to make it possible for WorldClient to recognize a category saved to an event, note, or task in one language as the equivalent category in another language.
For more detailed information relating to the files mentioned here, see: MDaemon\WorldClient\CustomCategories.txt.
You can now hide the White List and Black List folders for WorldClient users by default. To do so, open MDaemon\WorldClient\Domains.ini, and under [Default:UserDefaults] change the value of "HideWhiteListFolder=" or "HideBlackListFolder=" from "No" to "Yes". You can hide or show these folders for specific users by editing those same keys in the User.ini file under the [User] section.
Check for Attachments
In the LookOut and WorldClient themes there is now an option to check a composed message for attachments before sending, when attachments are mentioned in the subject or body of the message. This can help you avoid accidentally sending a message without an attachments when it is supposed to include one.
You can now control whether or not accounts are allowed to use or required to use Two-Factor Authentication (2FA). There are two new options on the New Accounts template for controlling the default settings for new accounts, and there are corresponding options on the Web Services screen for controlling 2FA for individual accounts.
The user interface for MDRA no longer uses frames and has been updated to use a mobile first responsive design. Browser support is limited to IE10+, the latest Chrome, the latest Firefox, and the latest Safari on Mac and iOS. Android stock browsers have been known to have issues with scrolling, but Chrome on Android devices works well.
This design is based entirely on the size of the window being used. Whether the user is on a phone, tablet, or PC, the appearance is the same for the same window size. The most important change here is the menu. From 1024 pixels width and below, the menu is hidden on the left side of the browser. There are two methods that can be used to display the menu. If a touch device is in use, swiping to the right will show the secondary menu. Whether or not the device is in use, there is also a "menu" button in the top left corner that will display the secondary menu. Tapping or clicking the menu title with the left arrow next to it at the top of the menu will display the primary menu. The help, about, and sign out menu in the top right corner changes based on the width of the screen as well. From 768 pixels and above, the words Help, About, and Sign Out are displayed. From 481 pixels to 767 pixels, only the icons are displayed. 480 pixels and below displays only a "gear" icon which when clicked or tapped will display a drop down menu with the Help, About, Sign Out options. List views with more than one column have column on/off buttons that are accessed by clicking or tapping the gray right arrow button on the far right of the toolbar container. The settings pages are no longer designed to be exact copies of the MDaemon GUI, but are instead designed to reposition and resize based on the width/height of the browser.
A new feature called Spambot Detection tracks the IP addresses that every SMTP MAIL (return-path) value uses over a given period of time. If the same return-path is used by in an unusual number of IP addresses in a short period of time, this may indicate a spambot network. Although it could still be a legitimate use of the mail system, experimentation has shown that this can be effective in limited cases at detecting a distributed spambot network as long as the same return-path is utilized throughout. If a spambot is detected, the current connection to it is immediately dropped and the return-path value is optionally blacklisted for a length of time you specify. You can also optionally blacklist all the spambot IPs then known for a user-defined period.
MDaemon now supports synchronizing contacts via the CardDAV protocol. MDaemon's CardDAV server allows an authenticated CardDAV client to access the contact information that is stored in MDaemon. Notable CardDAV clients are Apple Contacts (included with Mac OS X), Apple iOS (iPhone), and Mozilla Thunderbird via the SOGO plugin. For more information on CardDAV and configuring CardDAV clients, see: CalDAV & CardDAV.
MDaemon now supports Two Factor Authentication (i.e. 2-Step Verification) for users signing into WorldClient or MDaemon's Remote Administration web-interface. Any user who signs into WorldClient via HTTPS can activate Two Factor Authentication for the account on the Options » Security screen. From then on the user must enter a verification code when signing into WorldClient or Remote Administration. The code is obtained at sign-in from an authenticator app installed on the user's mobile device or tablet. This feature is designed for any client that supports Google Authenticator.
MDaemon now includes an ActiveSync protocol based Migration Client (ASMC.exe). It supports migrating mail, calendars, tasks, notes, and contacts from ActiveSync servers that support protocol version 14.1. Documentation for it can be found in the \MDaemon\Docs folder.
MDaemon now ships with an XML over http(s) based API. The result of this is that MDaemon Management clients can be written using any language on any platform that can make http(s):// post requests to the server. In MDaemon, this is only available to authenticated Global Admins, but in MDaemon Private Cloud a subset of the available operations is accessible to authenticated domain admins as well. The API also produces a website with documentation on the API specification. The installation default is to have it installed at http://servername:RemoteAdminPort/MdMgmtWS/, however, this can be set to any url for the sake of additional security.
The available operations include: