You couldn't be more wrong about this, Devon:

 "outgoing authentication" has absolutely no effect on mails addressed to local mail addresses. Think yourself: How would a foreign MX deliver mail to your local domains if it had to AUTH?

Just to update as this was posted on the mailing list as well: The ISP is currently investigating why traffic on port 25 apparently is blocked.

Thanks Rolf.  I think I know what's happening here.  For the account in question, all mail is intentionally being forwarded from another server (I cannot easily change this).  So, the immediate connection to Mercury is not from a spammer's server but from this forwarding host.  I don't think that connection control is going to help me in this situation.

Unfortunately, I haven't yet found any of these recent spamming hosts blacklisted, when checking with whatismyipaddress com, so Mercury's blacklist feature is not going to help either.

Gordon 

Just a confirmation, in case anyone else has this problem; the cause and the fix I've posted appear to work, the only downside being that access to my website requires using www in front of the domain name, previously it was optional. an alternative fix might be to set up a forwarding email account with my hosting provider but not create an MX record to point to it. The reason for no MX being that the spam that I refuse connections to will end up there and get forwarded to me.

DOH!  That "Example" line has bitten me in the butt before.  You would think I would learn.

Thank you!

FYI...

Clamav v0.99.1 release announcement:

http://blog.clamav.net/2016/03/clamav-0991-has-been-released.html

[quote user="Devon P"]

I use a program called peerblock to create my own custom allow and block rule lists and just use notepad++ to edit the lists. Easy to setup on the fly once master it. My custom block list now over 17K lines long. Peerblock is just a glorified firewall program that works with windows firewalls and dont have to create custom rules every time as this program listens on text file lists and populates the block list itself.

We had a massive problem with spammers worldwide, so we had to block all country's world wide besides the US and just allow certain domains and ip addresses from outside the US.

[/quote]

Ah - this would not work for the OP as Peerblock blocks IP addresses. You'd need some sophisticated traffic analysis to successfully allow mail from one IP address to just one domain.

Thanks. Seems SSL/TLS is involved. Turned it off and this worked for most accounts. For the last I renewed the passwords and this seems to have solved the last.

Also repaired the 4.80 install, knowing now that I couldn't brake anything.

If I've another moment I'll reimplement SSL/TLS.

Thanks for the guidance. 

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] !