Hi guys,

Has anybody already upgraded to v4.90? I'm interested in any experiences before updating our Mercury v4.81 email production system.

I'm taking for granted that the direct setup "over" the existing version works as usual and the setup process is recognizing a running version to take over all settngs, isn't it?

No, I am still waiting for others willing to test it out

The one related post on the LISTSERV list reported the overwrite of their modified spamhalter.ini file as the only issue.

This version has been extensively tested by the Beta team before release, and I can report it has been running on our server since September 8 without any issues or restarts.

Updates from v4.81 work without breaking any existing settings, but there are some new settings that may be worth checking out after installation.

As Brian mentioned the Spamhalter installer will query if the spamhalter.ini file should be replaced with one containing default values. Just clicking "Yes" may be the wrong choice here, so some extra attention is advised.

Hi Rolf,
Thanks for your reply and the hint regarding Spamhalter which is indeed active with us. I will install v4.90 soon.

Three questions:

1.
David said that a new license has to be purchased for v4.90. This is no problem for us and we are happy to contribute your work. But how it works technically? Presently, on v4.81, we have installed a valid 16-100 license. Could we update to v4.90 and purchase the new license during the next days? Or do we need the new license in advance of the update that it works without any limitations?
Taking for granted that David's license server at http://mlicense.pmail.gen.nz/mlic is still working.

2.
Since many users here with us are using Thunderbird and connecting via IMAP to Mercury, I'm especially pleased about the changelog statement "IMAP reliability improved".
But I read also: "Note that some Thunderbird users may find they need to disable "chunking" to work with this Mercury release - this is a side-effect of the other fixes we have put in place and will be addressed in a future release."

Long time ago we sometimes experienced corrupted email attachments when tried to open them in TB. And when I remember correctly we did something with the chunking settings in TB. That's why I'm triggered from David's statement on disabling chunking in TB. Do you mean the following TB setting:

mail.server.default.fetch_by_chunks TRUE

which should be set to FALSE?

3.
You said that there are some new settings may be worth to check. Could you provide an overview about all newly added setting fields in the different Mercury Modules? Or do I have to compare all 4.90 settings with the settings in 4.81 to find out the differences? We do change any settings in Mercury very rarely and that's why we don't have them all in mind. Mercury is working too good and too stable and nobody needs to take care permanently to mess around the settings.

Hi Joerg,

So here is what I can tell:

1.
License renewals and donations are much appreciated, but there are no limitations enforced by the program. More details here: http://www.pmail.com/mlicense.htm

2.
I haven't tested IMAP with Thunderbird myself so can't say for sure.

3.
Apart from new features mentioned in the release notes there are additional options in connection control settings for various modules and probably in the compliance tab as well.

I should mention that the installers for the other bundled daemons will query about restoring defaults the same as for Spamhalter, so advisable to click the right button there as well.

Tested it on an other pc, seems to be really working.
I have seen, that there will be different/better locations for logging, session-logging and some other points. I am now in the process of adapting the new locations in my existing setup. Hopefully next weekend have i time for the double switch (Mercury and OS).

A post containing notes of the changes that you find would be appreciated.

Okaydokey, done with upgrading Mercury...

Different folders for logging and session-logging departed in:

CORE - only in LOGS
MAISER - only in LOGS
MERCURYB - in LOGS and SESSIONS
MERCURYC - in LOGS and SESSIONS
MERCURYE - in LOGS and SESSIONS
MERCURYH - in LOGS and SESSIONS
MERCURYI - in LOGS and SESSIONS
MERCURYP - in LOGS and SESSIONS
MERCURYS - in LOGS and SESSIONS

New folder dumps in C:\Mercury.

MercuryS SMTP Server - tab Compliance - "Enable simplified phishing protection"

In Mercury/32-Help-System via F1 the point "Advanced TCP/IP Configuration Options" is interesting, because it describes the usage of the file "TCPIP.OPT" for managing the openssl-stuff like ssl-ciphers, sni, tls etc.

Hi Sellerie,

Thanks for early adopting and reporting

Regarding "different folders for logging / session logging" - does it mean Mercury Setup is ignoring our current log drop destinations and is creating new LOGS and SESSIONS folder under ..\Mercury\ in any case?

Regarding SMTP server's fishing protection ... I take for granted that this is an additional checkbox which could be activated on demand. Does the manual describe how it works and whether the postmaster will be informed about any filtered mails or delivery attempts?

No, Mercury does not ignore your existing setting. Mercury simply creates more folders.

Yes, "Enable simplified phishing protection" could be activated on demand. The inline help describes the function as follows:
"It has become increasingly common for criminals who control large numbers of computers (also called botnets) to attempt to work out passwords on systems like mail servers by the brute-force approach of having their botnets repeatedly connect and try a candidate password in an AUTH or similar command, then disconnect. Because each attempt is usually made by a different "bot", regular tests for multiple failures won't normally work. If you enable this control, Mercury will watch for failures on an account by account basis, and as soon as an invalid password is detected, it will lock the account for 30 minutes. During this time, attempts by other bots from the same group will fail their attempts, rendering the brute force approach largely useless. Although this control is not enabled by default, we strongly recommend that you consider enabling it if your security and password practices permit it."

I think an email will be send to maiser or the administrative user.

On a lab platform I tested the update process from version 4.80 to 4.90.
With the installed version 4.80 the Control Panel/Programs and Features displays the following relevant information :

Mercury/32 v4.80 David Harris DD.MM.YYYY 23.4 Mo 4.80

and the registry contains the related keys.

After upgrade to version 4.90 the Control Panel/Programs and Features displays the following information :

Mercury v4.90 David Harris 13.11.2021 31.5 Mo 4.90
Mercury/32 v4.80 David Harris DD.MM.YYYY 23.4 Mo 4.80

and the registry contains still the related keys to version 4.80 and nothing about version 4.90.
It seems that for Windows version 4.80 is not really fully uninstalled and version 4.90 is not fully installed ...

What do you think about this problem ?

====================

GrayWall 1            |    Ararat s.r.o.    |    30.10.21    |    3,04MB    |    1.2.2
Mercury/32 v4.80    |    David Harris    |    29.10.21    |    23,4MB    |    4.80

These are all mercury related entries. I do not have an entry for version 4.90 and in the registry the version entry is listed as "01EA".

====================

Help - About Mercury - Information lists the following:

Mercury/32 Mail Transport System for Microsoft Windows
Copyright (C) 1993-2021, David Harris, all rights reserved
Visit our web site, http://www.pmail.com for support info.

Mercury/32 version: Mercury/32, v4.90.298, 08 Sep 2021 13:54:57
Operating mode: Standalone
Windows version: abc
MERCURY.EXE directory: C:\MERCURY
Base directory: C:\MERCURY
New mailbox location: C:\MERCURY\MAIL\~N
TMP environment variable: C:\Users\def\AppData\Local\Temp
TEMP environment variable: C:\Users\def\AppData\Local\Temp
[No license installed]

====================

My old entries were:

Mercury/32 Mail Transport System for Microsoft Windows
Copyright (C) 1993-2015, David Harris, all rights reserved
Visit our web site, http://www.pmail.com for support info.

Mercury/32 version: Mercury/32, v4.80.149, Aug 18 2015
Operating mode: Standalone
Windows version: abc
MERCURY.EXE directory: C:\MERCURY
Base directory: C:\MERCURY
New mailbox location: C:\MERCURY\MAIL\~N
TMP environment variable: C:\Users\def\AppData\Local\Temp
TEMP environment variable: C:\Users\def\AppData\Local\Temp
[No license installed]

For your information, after the upgrade from 4.80 to 4.90, the following key still remains in the registry :

\HKEY_CLASSES_ROOT\Software\Mercury32

with subkeys BaseDir, Command, Queue and Version.

Version value is REG_SZ 0450 which seems to be 4.80.

By the way do you have some news concerning Pegasus Mail new version ?.

Unfortunately I completely agree

So do I ...

Brian informed me that there is a current discussion on Listserver about a broken self-signed certificate creation routine in M4.90. I do not have further information in this regard since I do not follow any discussions on listserver.

It's a pity that this new forum is still less frequented. A lot of work has been invested but most guys are sticking on the listserver, where you have to register and subscibe to single discussions first. These hurdles could scare off new interested users.

...and now?