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.

I have ended up with a combination of approaches.  I have allowed mercury.exe and the ports used for IMAP and SMTP access.  I don't know if allowing the ports is required and didn't think to have testing capabiltity readily available to test. 

The only other issue was a firewall block of rsync.exe which is associated with the def updating of ClamAV.  A firewall block notification called that to my attention.  All seems normal since rsync was allowed.

Zgrab is apparently a kind of scan tool: https://linuxsecurity.expert/tools/zgrab/

In this case it tried to connect using the HTTP protocol, it might have tried with SMTP as well though.

[quote user="Sellerie"][quote user="Anaglypta"]

E 20180228 171521 5a1d7606 DATA state failure - 554 Message rejected on 2018/02/28 17:15:21 GMT, policy (3.2.1.1) – Your messa

T 20180228 171521 5a1d7606 Connection closed normally. 

[/quote]

Please can you post the complete entry? I think the interesting part comes after "Your message" 

[/quote]

Sellerie,

The Mercury smtpE log file has been truncated, so that is all I have. But the intertesting bit is "policy (3.2.1.1)" which from this email provider (British Telecom in the UK) means "Your message was rejected because the "FROM" field is empty." I don't blame BT for doing this, I also do this using a Transaction Filter M, "*", RSN, "554 Your message was rejected because the "FROM" field is empty."

In order to overcome this I have now set up a client to receive messages for this account and created some filter rules to achieve this:-

• Match all messages
• Reply with template
• Mark as read
• Delete message

It is annoying that I have no solution in Mercury.

John.

I inquired about this log entry on the clamav-users list and received acknowledgement that they are aware and will fix it.  Functionality is not affected.

[quote user="Anaglypta"]However, pulling up HELP from Mercury32 has a whole section on setting up automatic replies, including simple autoreplies using AREPLY.PM. [/quote]

I'm glad you posted about the help file because I was bothered by not being able to find documentation to point you to.  I didn't think to look in the help file.  I know of AREPLY.PM but Han's guide to filenames and extension for Pegasus Mail is what sparked my memory about its function.  Glad you found the details.

Nice one, Rolf old chap

G 

Hi Brian,

No, the messages pulled from user's accounts don't result in duplicates to the public folder. They will only be dropped into the inbox of the (Mercury D) assigned local user.

Finally it seems Mercury (D or Core) is checking all opportunities (defined aliases and local accounts) for local mail delivery in case no local user is assigned.

Just confirming that the problem is resolved after replacing the 64-bit version of 0.99.3 with its 32-bit version.

Hi Joerg,

I have been using ClamAV for many years, probably since ClamWall was introduced in Mercury.  Detections are very common, diverting these messages to a quarantine directory.  I enhance it by including some third party definition files from Sanesecurity.  Def updates are timed based on a setting of your choice in a configuration file.  The default setting is every 10 minutes which I thought was too often so I set it to update hourly.

One shortcoming of ClamWall/ClamAV is that there isn't a built-in detection notification mechanism.  The workaround is a utility called CWscan written by Paul Whelan.  When executed, it scans the quarantine directory for new files, creates a .cnm file for each one containing relevant info about the detection, and writes it to a directory (mounted as an added mailbox), then moves the scanned messages to an archive directory.  As for overhead, I don't have a sense that it is of significance although I believe my mail volume is a good bit lower than yours.  I don't know whether higher volume=noticeable overhead.

Is ClamAV necessary?  Probably not, but I think the Sanesecurity defs help keep suspicious messages out of the user mailboxes.  False detections occur but are very rare.

You're welcome to email me directly if you care to discuss in more detail.