Mercury/32 v4.73 has now been released. This new version contains significant new capabilities and a number of important fixes, especially for the MercuryI IMAP server. V4.73 is the final iteration in the series of incremental upgrades to Mercury v4.7 that has come out since its release, and will be the last release in the v4.x family, with development proceeding to Mercury/32 v5 from this point on. We hope to release V5 sometime in 2011. The following changes are present in v4.73: <ul><li><font color="blue">Selective SSL options</font>  The MercuryS SMTP server now has options that allow you to enable SSL support on the primary and alternate SMTP ports selectively (so, you can have SSL enabled on the secondary, but not on the primary, ideal for submission by your remote users). There are also new Access Control permission settings in the MercuryS ACL editor that allow you to enable or disable SSL based on the IP address of the connecting client.</li></ul> <ul><li><font color="blue">ACL range corrections</font>  In previous versions of Mercury, access controls would not work correctly if the address range exceeded 256 addresses, and would occasionally work incorrectly with particular address ranges. These problems have now been fixed.</li></ul> <ul><li><font color="blue">Duplicate message suppression</font>  You can now create an empty file called MSGIDS.MER in any mailbox directory (i.e, a directory where a .CNM file gets created), and this signals to Mercury that it should suppress duplicate messages in that mailbox. Duplicate detection is based on a combination of sender and message-ID, and only the last 200 messages delivered to the mailbox are actually remembered.</li></ul> <ul><li><font color="blue">MercuryC forced sender option</font>  This option allows you to specify a single address MercuryC should use as the source of the mail it is sending when it is negotiating with the upstream "smart host". This option is quite technical, being buried in the depths of the SMTP transaction itself, and does not affect the "From" field in the message, or alter the contents of the message in any way, other than altering the Return-Path header that the smart host will write into the message. It is primarily aimed at users of services such as Yahoo Premium Mail, which require the SMTP "MAIL FROM" address to be the address of a known subscriber.</li></ul> <ul><li><font color="blue">Extended POP3 lockout detection</font>  MercuryP now locks out any account with too many login failures for five minutes regardless of the address from which the lockout occurred. So, once any system has failed logging into a POP3 account, all systems are prevented from attempting to login to that account for five minutes. This feature is primarily aimed at botnets that attempt to crack passwords by logging in from successive different systems and trying username/password combinations until they fail, and is automatic.</li></ul> <ul><li><font color="blue">Fixes for MercuryI IMAP</font>  MercuryI now saves UID lists any time they change: this should prevent UID synchronization problems from occurring, but may introduce small extra processing delays with very large folders. There have also been some changes in the way the IMAP SEARCH command is handled that should improve performance and reliability in a number of search scenarios (in some cases spectacularly), and MercuryI now caches FETCH data which should significantly improve performance and reduce load when clients like Apple Mail fetch messages a chunk at a time.</li></ul> <ul><li><font color="blue">MBXMAINT updated</font>  The mailbox maintenance utility MBXMAINT has been heavily updated. It now fixes a wider range of problems, and can also correct folders where messages contain duplicate message identifiers (important for more reliable IMAP operation). The program has been split into a commandline version, MBXMAINT.EXE and a user-interface version, MXBMAINT_UI.EXE. Both versions have considerably better reporting and output.</li></ul> <ul><li><font color="blue">Random filename generation fixed</font>  A very long-standing problem where the "random" filenames generated by Mercury were not very random and tended to repeat has finally been found and corrected. Mercury should now generate much more "random" filenames and the possibility of filename collisions should be dramatically lower as of this version. </li></ul><a href="http://www.pmail.com/downloads_s3_t.htm" title="Mercury downloads" target="_blank" mce_href="http://www.pmail.com/downloads_s3_t.htm">Click here</a> to go to the Pegasus Mail home downloads page and retrieve v4.73. Cheers! -- David --