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

Which version  of Merucry? If not V4.8 you should update to have OpenSSL.

[quote]Now I get the message

2018-04-29 08:55:05 Connection failed. Error #2:

stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL

Error messages:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert

handshake failure

[D:\testl\PHPMailer\src\SMTP.php line

404]

SMTP Error: Could not connect to SMTP host.[/quote]

 If this is with Mercury 4.8, You should check the settings of Module SmtpS. Usualy StartTLS is port 537 while SSL is port 465. Perhaps because of error on deprecated SSL V3 you have to enable "Support for deprecated  direct-connect SSL".And you have to insert or create an certificate file

You can tell I'm resistant to installing VC.  Even more so after seeing some of the office machines with 6 versions installed.  This machine only has Mercury and Firefox installed.  It's sole purpose is to run Mercury and provide online banking access.  It's a lean, clean, rock solid machine.

This is what Mercury help suggests for local domains:

"When entering domains into this section, you should usually provide three entries per local Internet domain - a fully-qualified version, a simple version, and a special entry called a domain literal version, which is the IP number of your system enclosed in square brackets."

You should be careful to only list valid domain names that you own and is going to handle email for.

It's usually recommended to list both the domain name itself (mydomain.com) and the proper host name for the server (which might be something like mail.mydomain.com). The literal (numerical) address should look like [11.22.33.44], showing the public IP address, and optionally with a similar entry for the local (LAN) address.

Two thoughts Jim..

- The .conf files are very different (more Windows user friendly).  Be sure to use the new ones.

- There's a dependency on Visual C++ 2015 Redistributable (v14) runtime library files (.dll's).  Unfortunately, they no longer package them in the .msi.  To install them you must either run the setup.exe (included in the .zip) or track them down manually. 

I went the manual route but there's probably no benefit to being as anal as I am about avoiding installation of Visual C.  If you opt to go this route, running clamd will trigger an error about a missing .dll.  The error shows the file name.  This will happen twice (two .dll files are needed).  I copied them from a different PC that had that version of Visual C installed.  The installer puts them in \system32 but I put them in \system just to keep them separate from "installed" files.

If MercuryE logs show that messages have been accepted for delivery by the receiving server this is a problem at the receiving end, most likely due to spam filtering or similar. Try contacting the helpdesk at the receiving end and ask them why messages aren't delivered.