MERCURY MAIL TRANSPORT AGENT FOR NOVELL AND 32BITS WINDOWS.

MERCURY /32:

Changes and additions for version 4.61 - added on 02-June-2008

The Help button when defining Secondary Queues did not work. Fixed now. The "Alerts and notifications" settings should now be reliably saved when altered in the dialog. Newly-downloaded alerts and notifications now take the current date and time, which will result in them sorting into sensible spots in their recipient's inboxes. A fix has been put in place for crashes on autoforwarding. Daemon Developer documents available, through the community and website There is now a CONFIRMW.MER in the setup file The problem in MB_MLSS where attempting to subscribe to a moderated mailing list would produce an error is fixed. LOADER.EXE now creates its log files in the directory from which it is run. The loader log file now correctly indicates scheduled daily exits instead of marking them as apparent abnormal terminations. The CONFIRMW vs CONFIRMS selection logic should now work correctly for subscription confirmation in lists.

Changes and additions for version 4.61 - added on 25-May-2008

This build contains a change to the underlying TCP/IP code that *might* be important on some systems. In particular, it *might* impact on problems with stale connections. The change involves calling the WinSock "shutdown" more often.

Changes and additions for version 4.61 - added on 07-May-2008

The installer now implements a new directory structure for logs, session logs and scratch files (this ONLY applies to new installations, not to upgrades): LOGS +---- Core +---- Maiser +---- MercuryS +---- MercuryD +---- MercuryB +---- MercuryC +---- MercuryE +---- MercuryH +---- MercuryI SESSIONS +---- MercuryB +---- MercuryC +---- MercuryD +---- MercuryE +---- MercuryI +---- MercuryP +---- MercuryS It also now pre-enters the paths for these directories in the configuration for each module, general logs in the "LOGS" subdirectory, and session logs in the "SESSIONS" subdirectory. For general logs, the filename is pre-entered as: <path>\~y-~m-~d.log For session logging, the session logging directory is now entered as <path>\<modulename> (e.g, "c:\merc\sessions\mercuryp") Session logging is turned off by default in all cases. MercuryE and MercuryC will no longer issue an ESMTP SIZE declaration in the MAIL FROM command if the size of the job is reported as zero by FindFirstFile. New installs of Mercury now default to using DST-proof UIDs for MercuryP (upgrades will default to NOT using them).

Changes and additions for version 4.61 - up to 03-May-2008

New feature: MercuryB (Mailing List Subscriber Service - MLSS): There is now a "forgot password?" item that will allow you to ask the server to e-mail your list password to you. This will be combined with an option to autocreate passwords when none is assigned. A "mass change" option that will allow you to set MAIL, NOMAIL or unsubscribe to all lists of which you are currently a member - it will work by sending a confirmation message to your subscription address with a completion link that will finish the process. The opening screen now has drop-down lists from which you can select the list you want to work with, instead of having to type the name in. Mercury can now auto-assign list passwords to any subscription that does not have them - there is a new option in the list editor for this. MLSS no longer works via the Mercury maiser - it now directly manipulates subscriptions, meaning it works better and faster, and that the mail server can now be disabled if you wish. MLSS's error handling has been heavily beefed-up. It handles more errors than before, and does it better. The standard welcome files now include new versions that offer links to MLSS for most management options instead of describing the archaic maiser commands. These standard files will be selected automatically if the list is marked as MercuryB-enabled and you use the standard welcome options. Other changes in Mercury: There is a quite nasty bug in the outgoing filtering rules code in Mercury - if you use a rule that deletes or moves the outgoing message, the queue files will remain open and stranded in the queue until the program restarts. Over time, this will use file handles until Mercury runs out and the system starts misbehaving. Fixed now. Mercury P has been completely rewritten: MercuryP now has a setting to use "DST-proof" UIDs. By default, this setting will be off in release versions, so that people can choose when they want to make the move. Turning the option on will result in one last re-download of mail for most users, because the UID will change to the new form, invalidating the stored values... But because the new UID is derived from static fields within the message itself, it will be unaffected by DST changes or changes in file timestamps. MercuryP now supports short-term blacklisting; MercuryP should be anything up to 10x faster than previous versions, especially on large mail drops. MercuryP now does heavy caching on mailbox contents, and no longer renames messages to mark them read (it updates the X-PMFLAGS header in the message instead). MercuryI now caches the inbox, which should result in dramatically faster SELECT operations on that folder. The foldering subsystem now supports a notion I'm calling "lingering mailboxes": the process of initializing a mailbox on connection is time-consuming and bandwidth-heavy; for normal IMAP clients, this usually isn't much of a problem because they typically use persistent connections... But for stateless IMAP clients, such as IMAP-based webmail packages, the delay required to startup a mailbox can get crippling, especially once the mailbox gets large. The changes I've made allow you to enable what is effectively a mailbox cache: when the connection is closed, instead of breaking down the mailbox image, Mercury puts it into a short-term cache: if a connection to that mailbox comes in before the cache entry expires, it can be reused with zero initialization overhead. It's worth noting that while the mailbox is lingering in the cache, it remains locked, so local Pegasus Mail users won't be able to access it: for this reason, choosing a cache timeout carefully may be quite important. But for people using MercuryI to host webmail or other stateless IMAP clients, this setting should have a really big impact on performance. Enable this option on the "Files" page of the Mercury Core Module configuration dialog. It's there because the foldering subsystem is actually a core component, and will eventually be shared by modules other than the IMAP module. A rather nasty little problem in MercuryI where UIDs for some messages would sometimes become invalid after Mercury crashes has been fixed. The primary symptoms of this were mismatched headers and message bodies for the most recent messages in the new mail folder. This version includes the fix for the MercuryI SEARCH vulnerability that was publicized a little while back. From this release, you'll be able to select entries in the Mercury system messages window and copy them using Ctrl+C. New startup option: MERCURY.EXE -P <cpu>. Where <cpu> can be the processor on which Mercury should run, or zero to suppress processor affinity, which is strongly not recommended. The default for this is 1. Mercury now uses a new console code in the core module. While on the face of it, this doesn't sound like a big development, it's actually very important because it will make it possible to remote the console screens, allows for much better reporting, reduces the size and complexity of protocol modules, and makes it easy for Daemons to have their own consoles. The console code will, I suspect, also generalize very nicely into a new logging mechanism. New consoles. The core module, MercuryS and MercuryP now all use the new console model. Mercury now hosts the same object interface as WinPMail. The object interface is the future of Mercury in almost every way, and this development is therefore enormously important. There is now a tool that automatically generates a header file suitable for use in Daemons from the core Mercury header files. This addresses one of the most significant problems I have had with making the Daemon interface more widely accessible to developers, because I now no longer have multiple different files to keep up-to-date. This is also a far more important development than it sounds because it will make it far easier for third parties to develop their own Daemons for Mercury. The the problem where accessing a mailbox via POP3 could result in messages being duplicated (and in some very rare scenarios, the wrong message being reported for a particular UID) in the IMAP server has been fixed. MercuryP Login-time maildrop listing constraints You can now specify certain mailbox display constraints for MercuryP by adding them to your POP3 login name. The general syntax of these options is as follows username ([,...]) that is, you enter your username as normal, then the list of constraint options you want to use in brackets after the name, separating the options from each other using commas. The options that are available are: NEW The NEW constraint tells MercuryP to list only files that were not present in the mailbox the last time you connected to it. UNREAD The UNREAD constraint tells MercuryP to list only files that are not marked as having been read (note that downloading a message via POP3 implicitly marks it as read) URGENT The URGENT constraint tells Mercury to list only messages that have a "Priority" or "X-Priority" header indicating that the message is urgent. FROM=<expression> This constraint tells MercuryP that it should only list messages that match the expression you supply. If the expression contains an '@' sign, then the comparison is performed only on the address portion of the field; if no '@' is present, the comparison is performed only on the textual embellishments of the field (such as the personal name). The expression can contain any Mercury regular expression characters and need not contain the "From:" text or be enclosed in '*' closure markers. SUBJECT=<expression> This constraint does much the same as the "From" constraint except that it acts on the "Subject" field of the message. SHOW=<expression> This constraint allows you to define a regular expression that is applied to all the headers of the message. The expression should usually contain the entire header text including the header keyword. The message is only displayed in the mail drop if the expression matches at least one header. OMIT=<expression> This constraint is the opposite of the "SHOW" constraint: the expression you supply is applied to every header in the message and if any header matches, the message is omitted from the maildrop listing. Threading in the core module. The Mercury core module now has a level of multithreaded processing. In testing here, this has improved the processing speed of mail going through the core by anything up to 350%. Note that you will only gain any real benefit from this if you have some level of message processing going on (policies, SpamHalter, Content Control. filtering rules and so on). Systems where little or no message processing occurs will notice almost no performance gain. Now neither loader nor Mercury itself will allow you to run more than one instance from the same install directory - you cannot override this. You can run multiple instances from different install directories though without any problems. When loader.exe quarantines a mail queue after multiple failures, it generates a message to the postmaster indicating that it has done so. This feature caused loader to restart over and over agian. Fixed now. Filtering rule "Move" and "Copy" actions now correctly detect a parameter that is an alias for a public mailbox and deliver the message there accordingly. Timestamps have been added to the core module console. Header removal should now work as part of the "Add header" filter rule action. It's now impossible to select "Strict mode" without "Normal mode" (a common problem in the past for people didn't understand that strict mode was effectively an extension of normal mode), and equally impossible to select "Only authenticated connections may relay" without turning on the other restrictions as well. New options in MercuryP and MercuryI configuration allow you to refuse all attempts to connect to an account using an empty password. The MercuryS configuration options for relaying control have been heavily tidied up (although the actual anti-relaying code is still exactly the same). The help has been tidied further and is now substantially complete. This version contains the automatic alerts and notifications feature. Simply install as always, making sure that you include your own MERCURY.LIC file. Then, go to "Alerts and Notifications" on the "Configuration" menu and fill in the blanks (the controls are disabled if there's no valid license). The site's licensing info can now be found in the Information... box under Help /About... In list management you can now use <Del> to delete the selected user, <Ins> to add a new user, and a new button, "Toggle" which does the following things: If the currently-selected subscriber is marked NOMAIL, it changes the subscription to ACTIVE. If the currently-selected subscriber is marked ACTIVE, it changes the subscription to NOMAIL. If the currently-selected subscriber is marked as on vacation, it changes the subscription to ACTIVE. There are new Mercury program and setup logos, which are the work of Sven Henze. As always, Sven has taken my at-best mediocre artwork and turned it into something that I think is quite special. New stand alone program: MSendTo is a commandline mailer for Mercury/32. It can construct a wide range of message types using a wide range of options. If run on the machine where Mercury is running, it will automatically determine the Mercury queue from the registry, or the queue can be configured statically or supplied on the commandline. To see a full description of the MSendTo commandline syntax, start a command shell and simply type "MSendTo" with no parameters.