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
- 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
- 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
- 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
- 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
- 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 firstname.lastname@example.org as moderator, you might send a message like this:
This will set all email@example.com's subscriptions to nomail.
mset firstname.lastname@example.org * 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 126.96.36.199 to
188.8.131.52, and an allow entry with the range 184.108.40.206 to
220.127.116.11: if 18.104.22.168 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.