Some answers here:

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

https://blog.clamav.net/2018/10/clamav-01002-has-been-released.html

[quote user="Supur"]You can now create an empty file called MSGIDS.MER in any mailbox

directory (i.e, a directory where a .CNM file gets created), and this

signals to Mercury that it should suppress duplicate messages in that

mailbox. Duplicate detection is based on a combination of sender and

message-ID, and only the last 200 messages delivered to the mailbox are

actually remembered.

It is a bit unclear what does it mean "only the last 200 messages delivered to the mailbox are

actually remembered"? I have thousands of messages in these folders - for which I would like to stay there (and not to be.. deleted). Probably it means that a new incomming message will be compared for duplicates only with last 200 messages in folder. Which would be good.[/quote]

We have msgids.mer in place for each of our local user mailbox accounts. Works fine as long as you don't use additional "public mailboxes". In that case Mercury has some problems in identifying of duplicates.

As soon as you put an empty msgids.mer into the user's mailbox directory, Mercury starts holding the incoming mails (for that user) additionally in a kind of cache. But this "cache" is limited to 200 mails to prevent an extensive memory using and/or processing duration. This "cache", after built up, will permanently renewed where new mails will be added and old mails will be removed. Whenever a new mail will be retrieved by MercuryD for that user, Mercury is checking its "last-200-mail-cache" whether this new mail was already delivered in past. And in case it's a duplicate, Mercury will drop this new mail.

Apparently there's wail2ban...

https://alternativeto.net/software/fail2ban/?platform=windows 

Five days without a problem... I've marked this thread as resolved.

For the outgoing mail, I found a solution using a "Filtering Rule / Outgoing Rule". As the first line, I have an "Always trigger" rule, with a "copy to another user" action. It copies all outgoing mail to my archiveoutgoing mailbox. At the same time it solves the problem that I had before using the General Ruleset. It does not copy all the internal traffic any more.

For the incoming mail I established a forwarder, as @Brian supposed. Now all  filtered spam is also forwarded to the archives. (I have only one testing set in my Content control and only one spam account. If one had more, he would need a forwarder for each).

Thank you Brian and Joerg.

Can't you run php on IIS?  IIRC that's what Roundcube is written in (same as Squirrelmail).

Hi Paul,

Yes, I did. Indeed, it was a problem with the ISP. But irrespective of this reason I was not aware that Mercury Core is always waiting for MercuryC. Especially internal mails between local users should be processed independent from Mercury's SMTP Client, isn't it?

Just received notice of the release of ClamAV 100.1

Details here:  https://blog.clamav.net/2018/07/clamav-01001-has-been-released.html

Hmm - checked my statistics and got the same.

Because all other entries in the list are real, existing users (have Novell Netware running) it may be, that these ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ are aliases pointing to an external mailaddress or are mailinglists. However - I don't see any entries for aliases and mailinglists.

Bye    Olaf

Thanks, Greenman. The settings available to me seemed correct, but I was awaiting the original link to do some testing. The sender has now said that the removal seems to have occurred at his end, possibly it's his AM that's over zealous.

I'm still a bit puzzled that one email client re-saves the CNM file on the server and the other doesn't, but it's not causing any issues so I'll consider the thread complete.

I wonder if we could tweak it to be a little more verbose......killed my global move filter rule..or somesuch

Thanks Joerg for the response. I eventually did the same. Great backward compatibility is maintained.

 At that time the mails just dropped all of a sudden.and didn't have time to test any upgrades in my working config.

Update to v4.8 solved it.

 Thanks Thomas but I'll have to try the Apache OpenSSL DLLs in a test environment over the weekend. 

That setting won't stop much spam anyway so no need to have it enabled. Alternatively you could add the sender address to the exception list to exclude it from compliance checks.

Thanks - most of our mail accounts are restricted to on-premise use, which means they do not require a password. Those that use IMAP anyway have their passwords listed under the SMTP module configuration page, and their IMAP+SMTP use the same credentials. I will simply assign new passwords to those accounts not using presently using passwords.

Mercury's help document has extensive help regarding setting up rules. I explained in an earlier post, and Rolf has also given you an idea of what to do (move).

The help doc is a pdf in Mercury's installation folder 'man-473.pdf'.

Well, the X-Envelope-To: header is used by MercuryD so that's probably where I would start looking. If you have the disk space you could switch on session logging and see it it happens again.

There could be ever so many problems here, the setup instructions you linked to is far from a standard setup.

Note that the sender address"postmaster@localhost" is not really usable outside a private network.

If you plan to use SSL encrypted transfer make sure you run the current version of Mercury. 

Hi Joerg, hi Olaf,

it seemed I screwed it up with my first installation. I threw it off the pc and had it completely new installed and look : now it runs seeminly without those problems I had before. Still something is uncanny : Sometimes mails get "stuck" for hours while others are transferred to the Outlook client immediately. After half a day or restart of the service of Mercury the "stuck" mails are transferred, too. Why that is I could not find out yet.  

Hmm - Mercury wants certificate in format PEM - not CER.

Bye    Olaf