MERCURY MAIL TRANSPORT AGENT FOR NOVELL AND 32BITS WINDOWS.

MERCURY /32: Changes and additions between versions 3.32 - 4.01

It took quite some development time to get this release finalized and ready for public use, why? Just read on and be amazed about all the additions:   What's new in Mercury/32 v4.01? V4.0, while a long time coming, includes some of the most powerful improvements we have ever made to Mercury, and creates a significant roadmap for future versions. In particular, the MercuryB web server protocol module heralds the arrival of web-based management and services for Mercury, and the inclusion of SSL support improves security dramatically. MercuryB HTTP server: This new protocol module implements the HTTP protocol for web-based access using a loadable service module approach to provide services. MercuryB is not intended as a general- purpose web server - it is specifically targeted at tasks specific to Mercury, such as mailing list subscription management (included in this release), remote administration and web mail (in development). SSL/TLS support: The MercuryS (SMTP server), MercuryP (POP3 server) and MercuryI (IMAP4 server) protocol modules now have comprehensive, easy-to-enable support for the SSL secure sockets protocol. Web-based mailing list subscription management: Using the new MercuryB HTTP server, mailing list subscribers can now manage their list subscriptions over the web. Subscribing, unsubscribing and managing subscriptions is now as easy as using a web browser and filling in some simple forms. Heavily improved spam filtering: The content control engine in Mercury/32 v4.0 has been heavily enhanced with new tests and a new default rule set that catches vastly more spam. We are also currently developing auto-update mechanisms that will allow spam rule sets to be updated automatically, allowing faster response to new types of spam as it arises. The content control engine now also has more options for adding headers to messages and can generate diagnostic headers indicating which rules contributed to the calculated weight for the message. Mercury's autoreply engine has also been changed so that any message getting a positive content control weight will not receive an autoreply: this prevents the server from sending autoreplies in the majority of cases. Improved HTML and encoding handling in Content Control: Mercury's content control engine has been retrofitted with improvements made in Pegasus Mail v4.12, and now only checks textual components of messages. When doing so, it now correctly applies BASE64 and Quoted- printable decoding before applying its tests, and strips HTML tags from HTML content (leaving only A, IMG and base tags for later testing). Content control now has explicit tests that check for lazy HTML (IMG tags with remote references), IFRAME tags, and excessive numbers of comments. The regular expression engine has also been extended with a number of powerful new tests. Attachment filtering: Mercury's general-purpose filtering rule engine has been enhanced with the ability to filter attachments within messages. Attachment filters can work on the filename or extension of the attachment, and can delete attachments from messages if required. The filtering engine now also has an action that can add a header of your choosing to any message as it is processed. VERP support in mailing lists: VERP (variable envelope return processing) allows near-total automation of error processing in mailing lists. Mercury/32 now includes three modes for handling mailing list errors, two of which use VERP. For larger lists, VERP can substantially reduce the amount of effort required to keep subscriber lists up-to-date. Subscription passwords: You can now specify that a password be required for subscription to a mailing list - this eliminates casual or unwanted subscriptions to mailing lists and reduces moderator workloads. MercuryI IMAP Server improvements: The IMAP4 server has been heavily overhauled and is now much more robust than in previous versions. Sites using stateless clients (such as webmail packages like Twig or IMP) should notice performance improvements as well. Transaction-level filtering in MercuryS: The MercuryS SMTP server now supports filtering at the transaction level - you can apply expressions to the SMTP EHLO command and to the data of the message as it is actually received. This is an incredibly powerful feature, particularly for dealing with address harvesters and spammers who attempt to relay via your server. Short-term blacklisting: MercuryS now supports the idea of short- term blacklisting, where clients that breach too many compliance conditions or match specific transaction-level filters can be blocked from connecting to the server for a period of 30 minutes. This is a powerful way of dealing with zombie systems (computers that have been taken over by hackers or spammers) and of protecting against denial-of-service attacks. Connection control overhauled: The ability of the Mercury server modules to control which machines can connect to them based on IP address has been totally overhauled. It is now possible to specify arbitrary address ranges to which restrictions can be applied, and each restriction can have specific attributes enabled or disabled (so, for instance, you could create an "Allow" entry that permitted a system to relay mail through MercuryS but which was not exempt from transaction-level filtering). Improved console output: The various Mercury server protocol modules now produce much more detailed information on the console and in the log files to show why particular actions occurred. Progressive backoff in delivery: You can now tell Mercury to use a "progressive backoff" algorithm when calculating retries for mail jobs; this tells Mercury to start with a relatively short retry period, then use gradually longer and longer retry periods the more retries occur. This can dramatically speed the delivery of mail when one-off transient glitches occur, and cuts down queue congestion caused by messages with more significant delivery problems. Besides the above the following minor issues have been addressed: In this version, you can now use * wildcards in the mail server SET, MSET, STATUS and MSTATUS commands. Wildcard SET and STATUS commands will affect all lists to which you are subscribed on the server; wildcard MSET and MSTATUS commands will do the same, but require a valid mail server password (see the mail server configuration dialog for this). Example: if you want to change all subscription records for user foo@bar.com as moderator, you might send a message like this: password blahdiblah mset foo@bar.com * nomail exit This will set all foo@bar.com's subscriptions to nomail. You can now set the Mercury scratch files directory on the "Files" page of the Core module configuration dialog. Automatic replies will no longer be sent to any message containing an X-UC-WEIGHT header with a '#' character in it. This prevents autoreplies from going to messages that have been flagged as spam by CC but still delivered. Automatic replies also won't be sent to any message where the subject contains the string "Out-of-office", the string used by exChange. proper disclaimer-addition code - code that will correctly handle all the off-beat cases like multipart/related and pure HTML data. Disclaimer addition will be possible as both a single global configuration option, and also as a filtering rule action (so you'll be able to add disclaimers selectively based on content if you prefer). You can now use high-bit ISO-8859-1 characters in the confirmation, welcome and farewell files associated with mailing lists, and Mercury will correctly quoted-printable encode them. Just type the characters into the template normally - Mercury will detect them automatically and will apply the proper encoding to the resulting message. In all versions of Mercury/32 up to now, autoreplies have had the envelope address of "postmaster@domain...". This is now changed so that autoreplies have the return address of "<>", which is a formal SMTP shorthand meaning "do not attempt to reply to this address" A new regular expression operator, /s, has been added: when the regex engine encounters this in the format string, it ignores all whitespace in the source string until it encounters another /s operator. Transaction-level filtering: you can now filter the EHLO/HELO command and message subject line during the SMTP transaction phase. See the "compliance" page of the MercuryS configuration dialog, and the sample TRANSFLT.MER rule file included in the release archive. The way connection control ("allow" and "refuse") entries are handled has been overhauld. You can now enter address ranges, and the various overloaded functions that allow entries have traditionally supported in the past (such as authorizing relaying and so forth) are now explicit options you can check in an entry. The code is clever about checking ranges, in that it allows multiple ranges to overlap. To resolve this, it uses the following rules: If an entry exists that describes only the single address that is connecting (i.e, is not a range), then it will use that. If multiple ranges exist that encompass the address, it will use the one with the smallest range. So, imagine you have a refuse entry with the range 192.156.225.1 to 192.156.225.128, and an allow entry with the range 192.156.225.10 to 192.156.225.20: if 192.156.225.15 connects, the allow entry will be used because it has the narrowest range that encompasses the address. The mailing list management window now has typethrough in its list of lists - this should make it easier to locate lists, simply by typing in the first few letters of their names. Supports a new 'R' test in MercuryS transaction-level filtering: the 'R' test is applied to the RCPT command. The 'R' (refuse) action now no longer drops the connection - it simply goes into a state where only the QUIT command is ever accepted. A new "B" action attempts to shove a response down the TCP/IP connection then severs it. The new "obfuscated" keyword in content control; the more I experiment with this addition, the more powerful I believe it is. The sample spambust.dat has now had all the most common cases converted to use the "obfuscated" qualifier, and it now catches a whole lot of spam that SpamAssassin does not appear to trap.