Hosted email options with MDaemon Private Cloud are now available. To learn more, please visit: http://www.altn.com/Products/MDaemon-Private-Cloud/.
 Please carefully read the section in the full release notes labeled as task  as it involves changes to the Active Directory integration system and you may find things that were broken in the past now starting to work. Please be aware of all changes made in that area and carefully read that section of these release notes.
 MDaemon 20.0 requires Windows 7, Server 2008 R2, or newer.
 Setup|Preferences|Miscellaneous has two new checkboxes that control whether system generated notification emails periodically sent to the Postmaster alias should also be sent to Global and Domain level administrators. By default, these options are both enabled. Domain administrators are restricted to receiving only those emails which are for their domain and the Release Notes. Global administrators receive everything including the Queue Summary report, Statistics report, Release Notes, 'No Such User' found (for all domains), Disk Error notifications, Account Freeze and Disable notifications for all domains (which, like Domain admins, they can unfreeze and re-enable), warnings about licenses and beta test versions about to expire, Spam Summary reports, and perhaps others as well. If you do not feel it appropriate for your administrators to receive these notifications you must disable these settings.
 How autoresponders are stored has changed. The text for an accounts autoresponder is now stored as OOF.MRK within the account's DATA folder which is a new sub-folder inside the account's root mail folder. Autoresponder script files are no longer kept in the APP folder and they are not shared between accounts. When MDaemon starts for the first time it will migrate all existing autoresponder files and settings to the correct places for every account. The AUTORESP.DAT file is obsolete and will be deleted along with every account specific .RSP file (OutOfOffice.RSP and non-account specific files will remain for reference and sample purposes). If you wish to quickly assign a single autoresponder configuration to multiple accounts you can use the new Publish button found at Account Editor|Account Settings|Autoresponder. This button will copy the existing autoresponder script text and all settings for the current account to other accounts that you select. There is also a button at Accounts|Account Settings|Autoresponders|Settings that lets you edit the default autoresponder script (OutOfOffice.rsp). This default is copied into an accounts OOF.MRK if the OOF.MRK is missing or empty.
 How account signature files are stored has changed. Signature files are now stored as SIGNATURE.MRK within the account's DATA folder which is a new sub-folder inside the account's root mail folder. When MDaemon starts for the first time it will migrate all existing signature files to the correct places for every account. The root MDaemon Signatures folder will no longer contain account specific signature files however it remains in place as it may still contain items needed by WebAdmin and the Content Filter. The original Signatures folder was backed up to \Backup\20.0.0a\Signatures\ prior to migration. Finally, every account's ADMINNOTES.MRK has been moved from the account's root mail folder to the new DATA sub-folder.
 Security|Spam Filter|White List (automatic) has had the default value changed to disabled for the option '...only whitelist addresses that authenticate using DKIM'. Having this enabled turns out to be a little restrictive for many and prevents address book whitelisting from working for MultiPOP and DomainPOP mail. Re-enable the setting if this is not to your liking.
 Setup|Preferences|UI 'Center all UI dialogs' has been reset to a default of 'enabled' for everybody. If you prefer otherwise you can disable it. This prevents screens from being created partially out of frame (which is better IMO) but it also makes multiple overlapping screens harder to select at times.
 Security|Security Manager|Screening|Location Screening - The default for this feature has been changed from disabled to enabled. When Location Screening is enabled the connecting country/region will always be logged (if known) even when the particular country/region is not being actively blocked. So, even if you do not wish to block any country you can still enable Location Screening (without selecting any countries to block) so that country/region can be shown and logged. Since the default setting for this has changed upgraders should take a look at their Location Screening configuration for correctness. MDaemon will insert the header 'X-MDOrigin-Country' that lists the country and region for content filtering or other purposes.
 The hard-coded fixed size limit of 2 MB for spam filter scans has been removed. There is now no theoretical limit to the size of a message that can be spam scanned. It is still possible to configure your own limit in case this is a problem but configuring 0 (zero) now means no limit. Additionally, the size limit has been converted from KB to MB and your existing value has been automatically converted or set to zero. You should check it at Security|Spam Filter|Settings and make sure this value is set how you want.
 Added 'Sender Domain' and 'Recipient Domain' columns to the Queues screens in the main UI. As a result of this a one-time reset of saved column widths had to be done. Once you set the column widths to your liking they will be remembered.
 By default now the Host Screen is applied to MSA connections. You can disable this at Security|Security Manager|Screening|Host Screen if you like.
 By default MDaemon IMAP, WebMail, and ActiveSync servers no longer provide access to the shared folders of disabled accounts. You can change this with a new settings at Setup|Server Settings|Public & Shared Folders.
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. More information on setting up MDaemon in a cluster can be found in the MDaemon Help file.
The RequireTLS effort in IETF is finally finished. Support for this has been implemented. RequireTLS allows you to flag messages which 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. For a complete description of RequireTLS see the RFC specification and especially the Abstract, Introduction, and Security Considerations sections.
RequireTLS is enabled by default. You can disable it with a new switch at Security|Security Manager|SSL & TLS|SMTP Extensions. It's fine to leave the service enabled. Only messages specifically flagged by a rule you must create using a new Content Filter action or messages sent to <local-part>+email@example.com (for example, firstname.lastname@example.org) are subject to the RequireTLS process. All other messages are treated as if the service was disabled. Several requirements must occur before a message will be sent using RequireTLS. If certain of them fail the message will not be sent and will bounce back rather than be sent in the clear. The requirements are:
RequireTLS requires DNSSEC lookups of MX record hosts, or the MX must be validated by MTA-STS. You can configure DNSSEC at Security|Security Manager|SSL & TLS|DNSSEC by specifying criteria whereby lookups will request DNSSEC service. DNSSEC requires appropriately configured DNS servers which is your responsibility. MDaemon's IP Cache and MX Hosts files have been updated to accept DNSSEC assertions. There's a new checkbox at Setup|Server Settings|DNS & IPs|IP Cache and you'll find fresh instructions at the top of the MX Hosts file for how to take advantage of this.
RequireTLS is an important advance against several possible attacks on email security and we are proud to have been a participant in this effort. Hopefully in the coming year all mail systems will deploy this.
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'.
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 never the message body until now. 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." That's why these options are on the Routing screen. For security purposes (probably you don't want all list members to be able to use this) you can select a checkbox which requires that the list's password be provided or no macros will be expanded. The list password is an old setting and can be found on the Moderation screen. If you don't provide a password that means any list member with "Write" privileges will be able to submit a post with macros so I recommend using a password /or/ enabling this feature for lists that have all "Read-only" members but who knows, it's up to you really. Here are the current macros available for use:
The list member name parsing code can handle "First Last" and "Last, First" formats OK.
Security|Security Manager|Screening|Hijack Detection has been improved. There are some new controls which will cause MDaemon to count the number of times that an authenticated user tries to send an email to an invalid recipient. An invalid recipient is defined as a 5xx error code in response to a RCPT command when trying to send the user's mail. If too many of these errors occur within too short 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 is a powerful measure to protect against accounts who have had their passwords stolen and are blasting out spams. I'm assuming that most of the attempted spams will result in a "5xx User Unknown" error fairly often. This should help prevent hijacked accounts from doing too much damage.
As part of this work the From Header Modification controls had to be moved to their own screen to make room for the new hijack detection controls. The From Header Screening settings can now be found at Security|Security Manager|Screening|From Header Modification.
MDaemon now has a dedicated queue for deferred messages. Messages are deferred as part of the Message Recall and Deferred-Delivery header support. Previously, the INBOUND queue was clogged up with deferred messages slowing down the system from delivering non-deferred mail. You can see there is a Deferred queue listed with the other queues in the tool window now and there's a Deferred sub-tab of the Queues root-tab so you can inspect the content of the DEFERRED queue. 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 DEFERRED 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. Activity is logged to the Routing tab/log file.
The Message Recall system no longer requires any delay or time spent in the DEFERRED queue. So, you can set the delay time to 0 if you want. However, this risks the strong possibility of the message you want to recall being delivered so a delay of at least 1 or 2 minutes is recommended. Otherwise you give your users very little time to realize they want to recall, send the recall request, and have time left over for MDaemon to process the request. But, also consider that since the recall system is now able to remove recalled messages from the remote queue(s) where there might already be a delay it didn't seem necessary to force a second delivery delay by making you use the DEFERRED queue needlessly. However, if you have your MDaemon setup to immediately deliver everything that gets into the remote queue(s) the instant it arrives there then you should consider using a delay value (something besides 0); otherwise recall won't have time to remove mail from the remote queue(s).
MDaemon now tracks the Message-IDs of the most recent email sent by each authenticated local user. This means users can 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 is the last message sent that needs to be recalled. 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. This completely eliminates any need to ever iterate across mail folder content which would be a prohibitive performance drain. There's a new control at Setup|Server Settings|Message Recall that will allow you to increase this 1000 value if you want (if you have a busy server). Recall attempts will fail if the message being recalled isn't within the last 1000 emails sent (or whatever value you set). This has made 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.
Messages sent to multiple recipients will ALL be recalled by a single request. The Message Recall system does not work without the X-Authenticated-Sender header to provide security and keep others from recalling messages they did not originate. Therefore, the option to disable this header (found at Setup|Preferences|Headers) will be overridden if Message Recall is enabled.
The Security root-tab has a new sub-tab called 'Auth Failures' and there is a corresponding new log file. This tab/log will contain a single line with details on 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).
You can right-click on a line in this tab and have the IP address of the offender added to the blacklist(s).
Several places in the code that forward messages have had authentication capability added. This means that several files in the \APP\ folder including forward.dat, gateways.dat, MDaemon.ini, all Mailing List .grp files, and possibly others now have the potential to contain obfuscated logon and password data in a very weakly encrypted state. The encryption is strong enough to defeat an over-the-shoulder glance but it is not strong enough to defeat hackers. As we always warn you, use the operating system tools at your command and any other measures to secure the MDaemon machine and directory structure from unauthorized access.
 The Setup|Server Settings|Servers & Delivery|Unknown Mail screen has had new options added which let you specify an AUTH logon and password for use with the host value specified on that screen. Also, the screen has been laid out differently and some text labels updated to better explain what some of these options do.
 The Mailing List Editor|Routing screen has had new controls added which let you specify an AUTH logon and password for use with the host value specified on that screen.
 The Gateway Manager|Forwarding screen has had new options added which let you specify an AUTH logon and password for use when forwarding a message to another domain/host. Also, the screen has been laid out differently and some text labels updated to better explain what some of these options do.
 The Gateway Manager|Dequeueing screen has had new options added which let you specify an AUTH logon and password for use when dequeueing mail to a remote domain/host/IP. Also, the screen has been laid out differently and some text labels updated to better explain what some of these options do.
 The Account Editor|Account Settings|Forwarding screen has had new options added which let you specify an AUTH logon and password for use when forwarding mail to a remote domain/host/IP. Also, the screen has been laid out differently and some text labels updated to better explain what some of these options do.
Setup|Server Settings|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 a logon and password using the new Account Editor forwarding controls (see task 22427 above) or the new Gateway Manager|Dequeueing controls (see task 22413 above) or any of the many other task specific settings then those credentials are used and they supersede what is configured here. This feature works with host names only (not IPs). I was able to easily code for one or the other (for now) so host names are more user friendly. Also please note that the UI for this is simple and doesn't (please Lord) need complication.
Many years ago I added logon and password capability to the MXCACHE.DAT file as a quick-fix for customers with immediate needs. This remains in place however the logon and passwords in that file are unencrypted. You now have the same functionality with this new Host Authentication feature so you no longer need to hack the MXCACHE.DAT file. Host Authentication uses HostAuth.dat where logon and password data is encrypted (however weakly) and it has a UI so it's better than MXCACHE.DAT hacks. If you want you can manually edit HostAuth.dat with notepad and enter plain-text logon and password values (which MDaemon will encrypt for you). See the instructions at the top of HostAuth.dat for how to do it.
Queues|Mail Queues|Custom Queues has been improved. 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, it still remains possible in some circumstances that individual messages within the queue might have their own unique delivery data and if so then that data takes priority over these new settings. This is by design and is not a mistake.
Now, the UI for this leaves something to be desired but it can't be improved right now. The UI does not (and will not) show logon and password data in the list-view. The UI cannot edit an existing entry (you must delete and recreate an entry to change it). The UI Add and Remove buttons do their work instantly - there is no pressing CANCEL to undo changes. If you make changes they are done. Please don't ask for a better UI because I can't do it. But these limitations are minor compared to the functionality gained. You can now setup 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 from accounts that are found to exist on other servers without requiring authentication. This can be disabled with a new checkbox at Security|Security Manager|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 new checkbox at Setup|Server Settings|Domain Sharing. These checkboxes are enabled by default.
 Setup|Server Settings|Domain Sharing has a new checkbox 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 IPs in their Trusted IP configuration (Security|Security Manager|Security Settings|Trusted IPs). Otherwise list messages might be refused with a 'Sender is not a member of the list' type error.
 Setup|Server Settings|Domain Sharing has a new Advanced button which 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.
 Setup|Preferences|Miscellaneous has a new checkbox 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.
 The Account Editor|Forwarding tab has a new 'Schedule' button that will let accounts configure a schedule for when forwarding starts and stops. Also, this is included in the Account Templates as well. 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 Account 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 (these are new) in case that is useful for you.
 Forwarding a message now updates the forwarding account's last access time (ie the LastAccess=date gets updated in the account's hiwater.mrk file). This means that accounts which do nothing else but forward mail are no longer potentially deleted for inactivity. Note that 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' (see 12791 in this document), etc. Just having a forwarding address configured will not automatically flag the account as active - the forwarding needs to actually happen.
 &  Security|Security Manager|Sender Authentication|SMTP Authentication has had two new options added. 'Do not allow authentication on the SMTP port' 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. Also, '...add their IP to the Dynamic Screen if they attempt it anyway' will add the IP address of any client that attempts to AUTH when AUTH is disabled to the Dynamic Screen. 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 has been improved. You can now select accounts that are enabled, or are using MultiPOP, or are near quota (70%), or 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.
 The Account Manager right-click menu has had new options added which let you add or remove all the selected accounts from or to mailing lists and groups.
 The Account Manager right-click menu has a new option which lets you copy an existing account when creating a new account. All settings of the existing account are copied to the new account except Full Name, Mailbox, Password, and Mail Folder.
 The Account Editor|Account Settings|IMAP Filters has a new button called Publish that adds the new rule to the account being edited and to every other account in that account's domain. This should save some time when a rule is needed for everybody. Also fixed a problem with the rule editor which was allowing duplicate rules to be added.
 The Domain Manager|Host Name & IP screen has a new settings 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 still accept messages from the outside world. You can schedule when 'Do Not Disturb' starts and stops. For example, if you configure April 1, 2020 to May 31, 2020 from 5:00pm to 7:00am, Monday thru Friday then this means that 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 April 1 and May 31, 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. Setup|Server Settings|Archiving now does its 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.
Mailing list traffic is never archived. Spam is never archived (the option to do so has been deprecated and removed from Setup|Server Settings|Archiving). Messages with viruses are never archived. System level messages are never archived and finally autoresponders are never archived.
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 here 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.
 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 then the encrypted form will be stored instead (because what other choice is there?) If you would rather have encrypted versions stored then you can check a new checkbox at Setup|Server Settings|Archiving.
 Setup|Server Settings|Archiving has an option to archive messages sent to public folder submission addresses. This is especially needed now that submissions addresses are not required to be an actual account on the server (see 12311 below). This option is enabled by default.
 Setup|Server Settings|Logging|Settings screen ran out of room so some of the items had to be moved to a new screen called (drum roll please) Setup|Server Settings|Logging|More Settings. This was necessary as part of the task to prevent the creation of log files for items which have logging disabled. For example, if you disable 'Log SMTP activity' then there is no reason to create an empty SMTP log file. MDaemon no longer creates empty log files. When items are disabled on this screen their associated log file will not be created at all on 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. For example, if you have not been logging POP activity there will be no POP log file. If you then enable POP logging the required log file appears. From now on we do not carry around empty log files for services we don't use (or services we do use but don't care about logging). This change applies to all log files that the core MDaemon engine manages (which is most of them). Log files for Dynamic Screening, Instant Messaging, XMPP, WDaemon, and WebMail run external to MDaemon and haven't been updated so they behave as before. But, we are getting closer to perfecting the logging system. As a result of this work if you change the logging 'mode' option at Setup|Server Settings|Logging|Log Mode MDaemon must be restarted.
 Several logging related changes such as making ATRN session logs look correct; making all logs consistent in colors and how they log Session and Child IDs; 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.
Also, 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.
 Use of Active Directory groups with MDaemon has been debugged and now works as expected. When you add someone to an Active Directory group they will be added to MDaemon. When you remove someone from an AD group their MDaemon account will be disabled (but not outright deleted - I'm relunctant to do that in a automated way as it results in the complete loss of account folders and mail data which I feel is something best left to an admin to do directly).
Within Active Directory adding a user to a group or adding a group to a user (either way) is not considered a change to the user (which MDaemon is looking for and needs) but it is considered a change to the group only. This fact caused me a lot of headaches. To solve this issue (in addition to a lot of new code) MDaemon needs a search filter that looks for changes to the group AND changes to users who are members of the group. The query for the group change is needed because MDaemon now tracks the 'members' attributes that are returned. The query for users who are members of the group is needed because that's where the user's data comes from. The group query doesn't return that.
So, to setup a proper search filter for a group called 'MyGroup' this will work:
Replace the 'ou=' and 'dc=' bits with something appropriate to your network.
There is still some room for improvement here during the v20 series but this is finally working correctly now (let's hope).
 When you configure 'Alias=%proxyAddresses%' in ActiveDS.dat MDaemon will create an alias for every value returned by that attribute so long as it's an SMTP type address (X500 and other types are ignored).
 Accounts|Account Settings|Active Directory|Authentication has a new control that lets you specify a separate (different) search filter 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. AD 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 layout and labels on some of the controls on this screen had to be modified to make things fit. Also, the Page Size control was removed. It can still be manually altered if more than 1000 is needed.
 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/updates address books: abTitle=%personalTitle%, abMiddleName=%middleName%, abSuffix=%generationQualifier%, abBusPager=%pager%, abBusIPPhone=%ipPhone%, abBusFax=%FacsimileTelephoneNumber%. If these create problems for you or you don't want them included when contacts are created you can comment out these templates in ActiveDS.dat using notepad.
 The ActiveDS.dat file [CharacterConvert] processing has been improved to allow single characters to be replaced with two characters (for example, ß will be converted to SS). Open ActiveDS.dat with notepad to see the default conversions that will be made. Also, conversion will take place on the Alias values (if any) as well as the Mailbox value by default.
 Public folder contacts will now be deleted when the associated account is deleted from Active Directory. The contact is only deleted if it was created by the Active Directory integration feature. A new setting at Accounts|Account Settings| Active Directory|Monitoring lets you disable this if you wish.
 When 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 accounts and aliases are created the accounts Administrator Notes data will be updated for auditing purposes.
 List Manager|Active Directory 'Test these settings' button result text was setup for localization. The results will also display the Base DN used for the test.
 List Manager|Active Directory now allows you to enter an AD attribute for the full name field of list members. You can still specify only an email address AD attribute if you wish but to also fetch full name values for list members setup the AD attribute like this: 'displayName, Email' rather than just 'Email'. The first attribute specified should point to the AD attribute where the full name resides (usually that will be 'displayName'). The second is the email attribute.
 Text which appears in the Active Directory screen/log is now setup for localization and colors added.
 MDaemon no longer creates an account for an AD group object. Previously, when a search filter included an AD group MDaemon would create an account for that group. But what's really in mind here is to create accounts for members of an AD group and not for the AD group object itself - which lacks several properties necessary for a proper MDaemon account anyway.
 Changes to account properties in Active Directory can trigger the recreation of that same account within MDaemon even when the account had previously been deleted using the MDaemon GUI (or web administration). To keep accounts from being recreated in this way a new checkbox has been added to Accounts|Account Settings|Active Directory|Monitoring. The checkbox is enabled by default (don't recreate accounts deleted using the GUI).
 'From Header Modification' has been renamed 'From Header Screening' and some new features have been added. Security|Security Manager|Screening|From Header Screening has a new checkbox that will check 'From' header display-names for anything that looks like an email address. If one is found and it does not match the actual email address then it is replaced with the actual email address. For example, if the 'From:' header looks like this: From: "Frank Thomas <firstname.lastname@example.org>" <email@example.com> then it will get changed to this: From: "Frank Thomas <firstname.lastname@example.org>" <email@example.com>. This option is disabled by default. Also, there's a new checkbox to apply all the settings on this screen to non-authenticated mail only. As before, only messages to local users are eligible for these settings.
MDaemon can 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. 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 password before and it has appeared in a data breach. Published passwords may be used by hackers in dictionary attacks. Unique passwords that have never been used anywhere else are more secure. See Pwned Passwords for more information.
At Accounts | Account Settings | Other | Passwords, MDaemon has an option to not allow an account's password to be set to one that is found in the list. It can also check a user's password every so many 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.
The MTA-STS effort in the IETF has finished. 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 is enabled by default. It can be disabled at Security|Security Manager|SSL & TLS|SMTP Extensions.
To set up MTA-STS for your own domain, you will need a MTA-STS policy file that can be downloaded via HTTPS from the URL https://mta-sts.domain.tld/.well-known/mta-sts.txt, where "domain.tld" is your domain name. The policy text file should contain lines in the following format:
Mode can be "none", "testing", or "enforce". There should be an "mx" line for each of your MX hostnames. A wildcard can be used for subdomains, such as "*.domain.tld". Max age is in seconds. Common values are 86400 (1 day) and 604800 (1 week).
Also needed is a DNS TXT record at _mta-sts.domain.tld, where "domain.tld" is your domain name. It must have a value in the format:
The value for "id" must be changed every time the policy file is changed. It is common to use a timestamp for the id.
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.
TLS Reporting is disabled by default. It can be enabled at Security|Security Manager|SSL & TLS|SMTP Extensions. Also make sure DKIM signing is enabled (at Security|Security Manager|Sender Authentication|DKIM signing) because TLS Reporting emails are supposed to be signed.
To set up TLS Reporting for your domain, you must create a DNS TXT record at _smtp._tls.domain.tld, where "domain.tld" is your domain name, with a value in the format:
Where firstname.lastname@example.org is the email address you want reports for your domain to be sent.
PUBLIC & SHARED FOLDERS
GROUPS & TEMPLATES