Mercury/32 v4.62, July 2008

V4.62 includes a correction for a problem where POP3 messages could be downloaded twice when the old-style MercuryP UID scheme was still in use. It also includes some clarifications in the setup program during upgrades and some minor changes to the internal Daemon Programming Interfaces. Sites that have installed v4.61 are advised to upgrade to v4.62, especially if they use POP3.

Mercury/32 v4.61, June 2008

V4.61 includes a large number of minor fixes (over 300 by our count), and some notable new features:

• Notifications and alerts  If you purchase (or have already purchased) a license for Mercury, you can now enable automatic checks for new releases and updates, security bulletins and general information about the program. To take advantage of this feature, see the new Alerts and notifications option on the Mercury Configuration menu..

• Lingering Mailboxes  This is a new performance option for the MercuryI IMAP server, especially aimed at people using "stateless" IMAP clients such as webmail packages. When it is turned on, Mercury defers breaking down the memory image of the mailbox when an IMAP connection terminates; if a new connection for the mailbox arrives before the standdown period has elapsed, it can be reused at once, hugely reducing the startup time for IMAP connections. Enable this option in the "Files" page of the "Core module" configuration dialog.

• IMAP INBOX now cached  The Mercury IMAP server now caches the IMAP inbox, meaning that connecting to it will be significantly faster than in previous versions.

• IMAP Server performace improved  Server performance, particularly when opening large folders, has been dramatically improved.

• DST-proof POP3 UIDs  Because of a long-standing bug in Windows, the MercuryP POP3 server in the past reported different UIDs for messages after a change in Daylight Savings Time, resulting in clients re-downloading messages they had already seen. This problem has been fixed in v4.61, but the fix is disabled by default, because enabling it will cause one last re-download. You can turn it on whenever you're ready in the MercuryP configuration dialog.

• MB_MLSS heavily improved  MB_MLSS, the MercuryB module that allows web-based management of mailing list subscriber settings, has been heavily overhauled. It now has options allowing subscribers to retrieve their passwords if they have forgotten them, and to change settings for all lists to which they are subscribed. As well, users can now select lists from drop-down controls instead of typing in their names (if you have 50 or fewer lists), and the service manipulates mailing lists directly, rather than going through the Maiser mail server interface.

• Mailing list password auto-assignment  Mercury's mailing list manager can now be instructed to auto-assign passwords for new subscribers to mailing lists. This, combined with the new capabilities of the MB_MLSS module (see above) makes mailing list management easier and more secure.

• SMTP server enforces size restrictions  In previous versions of Mercury, the SMTP server could be told to refuse incoming messages larger than a particular size, but only if the connected client used the ESMTP SIZE declaration. In v4.61, MercuryS now refuses *any* message larger than the size you specify, whether or not there is a SIZE declaration. This change *might* confuse some older SMTP client programs (we expect this to be a very rare occurrence if at all), but has become increasingly important in the age of spam and mail-borne viruses.

• POP3 Server completely overhauled  The MercuryP POP3 server has been totally overhauled, and is now substantially faster than in previous versions.

• POP3 login-time listing constraints  This powerful new feature allows users to control the messages the Mercury POP3 server will show them by adding a simple command to their POP3 username... For example, if you only want to see urgent messages from the "pmail.com" domain, you would login to your POP3 mailbox as username (urgent, from=@pmail.com). The constraints that are available are described in more detail in the Mercury manual and online help. We anticipate this feature being especially useful for people who use cellphones or other low-grade connectivity devices to check their mail.

• MSendTo commandline mailer  This new utility allows you to send mail from the commandline. It is quite sophisticated, and can generate a wide range of message types, including digests and unlimited numbers of MIME attachments. MSendTo can be used in scripts or called from programs to send mail via Mercury.

• Threading in the core module  In the past, the Mercury core module has been single-threaded (meaning that it can only ever be doing one thing at a time). With increasing processing of mail via external processes such as Mercury policies, SpamHalter, Content Control, filtering rules and so on, the time it takes to process a message in the queue has been getting longer and longer. As of v4.61, the Mercury core module now supports limited threading (it runs up to seven worker threads), which significantly improves queue throughput on heavily-loaded systems.

• Many, many fixes, including problems with IMAP UIDs being lost or duplicated after crashes, problems with the loader queue quarantine message being delivered multiple times and others.

As well, a comprehensive new developer guide and sample code for people interested in developing their own Mercury Daemons is nearing completion and will be made available in the next few weeks: an announcement will be made here when it is released.

Click here to go to the downloads page and download the v4.6x installer.

[ Page modified 21 June 2008 | Content © David Harris  | Design by Technology Solutions ]