Upgrade is very simple: Make sure you have a full backup, shut down Mercury, and run the installer, selecting upgrade. If you use any of the daemons that come with Mercury they will probably need to be upgraded too.

Ah! That WAS checked!

Thank you!

a

Ok, so it appears that Exchange online accounts experience the same problems and MS is looking to "fix" this problem as it is changing the messages and causing the DMARC failures as seen here:

https://blogs.msdn.microsoft.com/tzink/2016/05/19/why-does-my-email-from-facebook-that-i-forward-from-my-outlook-com-account-get-rejected/

So my question is to the Mercury32 developers, can you also do this so that I can effectively use the basic forwarding and Aliases functions in Mercury32?  Our users use the "Forward file" setting so that they can set their own forwarding themselves and I don't have to be involved. 

If not, I will have no choice but to move to some other platform as the way our user operate we need to use this type of forwarding as they have an use multiple email addresses.

Thanks,

MP

That sounds like the mailbox at some point  was accessed from a different device, maybe a smartphone, that marked a number of messages as "read", preventing the normal POP3 client from getting them. If MercuryP was set to create a log file (needn't be a session log in this case) it might be possible to locate a different IP address there.

It's possible to run more than one instance of Mercury, from different directories. As they have separate settings it would be possible to have them listen on different interfaces. They would however have separate mailbox directories as well.

Another option is to use fsynonym.exe. Create a text file (e.g. mail-names.txt), which maps to local mail account name:

jony@domain1.com == jony1
jony@domain2.com == jony2

You then use fsynonym to parse the contents of the text file to a file named synonym.mer

Check out the documentation. We use Mercury to manage the mail for 3 different domains and this works fine.

I found the reason:
Mercury is RunAs different user on my system. Two users cannot access the sound system simultaneously ("Another application is playing audio. You can either interrupt the application or wait until it is done. Then try using Sound Recorder again.").

So it's neither a bug in M/32 nor that common file formats wouldn't work in M/32.
Just for the record: A possible workaround was to Run a program with the parameter C:\WINDOWS\system32\runas.exe /savecred /user:[LoggedOnUser] "C:\WINDOWS\system32\sndrec32.exe /PLAY \"C:\MERCURY\notify.wav\" /CLOSE"
or such. I did not test that out though as a system monitoring is running on that server anyway where I just add a log file test for system.log.

 HTH, Rainer

P.S. Happy new year [D] !

[quote user="Brian Fluet"]Changes to the .conf files are indeed rare but I prefer to do a file compare of the samples from the existing and new version and then use the new ones when there are changes.
[/quote]

I agree - that's best [;)]

[quote user="Brian Fluet"]

I am using Mercury in a Windows environment but have the same problem.  I first discovered it when I upgraded from v4.74 to v4.80.  See my thread here:

http://community.pmail.com/forums/thread/44383.aspx

The response made me  wonder if I was lucky that mailbox corruption didn't occur but it sound like you had users operating the same as I did with no problems.  It cerrtainly doesn't sound like it is a good idea to override the lock [/quote]

I'm sure that's true and is the way I've always understood it.

I've just seen a similar problem and posted details (including a session log) in a separate topic here:

 http://community.pmail.com/forums/thread/45424.aspx

Googling the error I saw had some interesting results, as discussed here: 

http://openssl.6102.n7.nabble.com/openssl-update-1-0-1f-to-1-0-1g-broke-sendmail-SSL23-GET-SERVER-HELLO-tlsv1-alert-decode-error-td49242.html

In this case it looks like a fix implemented in 1.0.1g of OpenSSL caused some compatibility issues in certain mail servers, resulting in the same error I saw with Mercury 4.8.  Mercury 4.8 shipped for me with OpenSSL 1.0.1h.  Not sure if the same issue is still in the 'h' release, but it seems related.

Mark 

According to David Harris, there is no fixed limit of number of subscribers in Mercury mailing list.

I would also recommend to update to v4.80

In past wee also experienced occasional Mercury crashes from time to time, often in connection with the establishment of SSL connection to our ISP. Sometimes once a week, sometimes only once per month or more rare. But since we have updated to v4.80 at the beginning of this year, no further crashes. We are happy.

Please let us know if a daily maintenance restart does not reset that counter.

Edit:  I withdraw this clarification inquiry because a during a reread of Rolf's post it became apparent he is talking about an OS restart and not a Mercury restart.

Send a mail via SMTP to yourself and have a look at the received headers.

But what is the problem stopping and starting Mercury?

Regards

    Olaf

I noticed that the last couple of years messages from one folder were missing.

My fix:
I knew some text that would be in the most recent missing email, so I searched the MAIL\username folder for that text using Agent Ransack.
This identified a PMI/PMM pair that held the missing emails.
They had a different filename from the current truncated files.
I closed Mercury and concatenated the files together, via the good old 'copy /b' DOS method.
Starting Mercury again and looking at the folder with 'eM Client', I see the messages now exist, but only the Date column is correct, not message content.
Then I tried mxmaint_ui.exe - A 'Check' showed invalid index numbering or something. A 'Repair' completed with a not-too-scary warning.
Starting Mercury again, then eM Client..... all my messages are there!!! (Just had to mark some as read).

Hope this can help anyone else who strikes the same problem.

I see. Many thanks. 

Last post in this thread.

Today I sent a message to 7 local addresses. I added the addresses to the Cc field via an address book which lists all local accounts. Two accounts did not receive them. Mercury had 'killed' them.

I chose 'resend this message' and sent it to them individually and they received the messages.

Neither of these accounts are subject to mail filtering at all.

This is a PITA, but I can't see any way around it.

I've not upgraded to 4.8 yet as I have a ton of other things to do. Hopefully, that will sort this weird issue out.

No need to respond.

They may be the cause of the "still trying" messages - but in this case the messages were delivered OK.

That's basically it, switch modules and restart Mercury. I assume you already checked that the new ISP isn't blocking port 25 for outgoing messages and that there is a reasonable PTR record for the IP address.

OK so I made another test:

I opened a mailbox with IMAP, removed the connection to the network from the computer running the IMAP client, and closed the IMAP client. The connection was still up in Mercury's console, and the lock file was still there. I reconnected the network and opened the mailbox again. Mercury now showed two concurrent IMAP connections to the mailbox. The mailbox was fully accessible, except messages could not be deleted (which is expected behavior with more than one IMAP connection).

Multiple IMAP connections to the same mailbox are allowed, so if one connection is lost due to client side failure it makes no difference for creating a new one.

The best shot at finding out what actually happens when your user gets locked out is probably still to try to catch it in a session log.