Yes.

Usage:  MALIAS.EXE <source_file_name> <alias_file_name>

Judging by the IMAP log, we have recently been the subject of a brute force attack on our Mercury based IMAP server. The Mercury manual is a bit vague, but implies that steps are taken to temporarily (30 min) blacklist misbehaving IP addresses. There is an option to override the short term blacklist, but no description about what would trigger the block.

My concern is that there is no sign in the log that it is doing any blocking. Here is a short except:

Password failure, user 'website', from 59.167.127.168
Password failure, user 'wesley', from 120.151.142.86
Connection from 211.31.199.182, Sun Feb 21 04:13:14 2016
Connection from 59.167.127.168, Sun Feb 21 04:13:14 2016
usa at 211.31.199.182: 1 sec. elapsed, connection closed Sun Feb 21 04:13:14 2016
Password failure, user 'wanson', from 59.167.127.168
Connection from 211.31.199.182, Sun Feb 21 04:13:14 2016
website at 59.167.127.168: 0 sec. elapsed, connection closed Sun Feb 21 04:13:14 2016
wesley at 120.151.142.86: 0 sec. elapsed, connection closed Sun Feb 21 04:13:14 2016
Connection from 211.31.199.182, Sun Feb 21 04:13:14 2016
Password failure, user 'webuser', from 211.31.199.182
Connection from 211.31.199.182, Sun Feb 21 04:13:14 2016
Password failure, user 'vincent', from 59.167.127.168
Connection from 120.151.142.86, Sun Feb 21 04:13:15 2016
wanson at 59.167.127.168: 1 sec. elapsed, connection closed Sun Feb 21 04:13:15 2016
Connection from 120.151.142.86, Sun Feb 21 04:13:15 2016
Password failure, user 'waters', from 211.31.199.182
Password failure, user 'vanessa', from 211.31.199.182
Connection from 120.151.142.86, Sun Feb 21 04:13:15 2016
Connection from 120.151.142.86, Sun Feb 21 04:13:15 2016
webuser at 211.31.199.182: 1 sec. elapsed, connection closed Sun Feb 21 04:13:15 2016
Password failure, user 'video', from 211.31.199.182

this suggests that multiple password attempts have been permitted within a few seconds. The 3 IP addresses implicated in the attack caused about 2.4Mb of log similar to this excerpt in about 15 minutes.

 So my questions are:

Is there a defence built in against a brute force attack on the IMAP server?

Is there any evidence from this log or elsewhere I could look, that it is actually working (or definitely not working)?

If it is not working, any suggestions to auto-block IP addresses that make repeated failed login attempts would be very welcome.

Many thanks for any help

To clarify, that comment was referring to the case presented by the original poster and may or may not apply to the second case.

I have moved Mercury a number of times simply by copying it to the new machine being sure that all paths remain identical. 

I can't answer the question of whether an upgrade from v4.01a to v4.8 requires any special considerations.

Right, Mercury really likes the queue directory and all scratch directories to be there, even if empty! :)

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.