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.

Hmm ... in the not so far future Mercury should be able to handle IPv6. This means i.e. filtering on IP should be upgraded to V6.

Bye    Olaf

I have the same setup outlook 2010 and mercury.  It works fine for me.  Just did a session log which I provided below in case you can see something in it that helps.

It doesn't look like yours is logging in?  The peer certificate thing popped up for me as well.

I wonder if you try providing the username and password instead of saying use same as pop will fix it.  That is how mine is set. under More settings | Outgoing server i have "my server requires authentication" but I am providing the username and password.

00:26:25.244: --- 15 Dec 2017, 0:26:25.244 ---
00:26:25.244: Accepted connection from '24.224.215.188', timeout 900 seconds.
00:26:25.307: Connection from 24.224.215.188, Fri Dec 15 00:26:25 2017<lf>
00:26:25.307: << 220 mercurymailsystem.ca ESMTP server ready.<cr><lf>
00:26:25.322: >> EHLO JimmyB<cr><lf>
00:26:25.322: << 250-mercurymailsystem.ca Hello JimmyB; ESMTPs are:<cr><lf>250-TIME<cr><lf>
00:26:25.322: << 250-SIZE 107286400<cr><lf>
00:26:25.322: << 250-8BITMIME<cr><lf>
00:26:25.322: << 250-AUTH CRAM-MD5 LOGIN<cr><lf>
00:26:25.322: << 250-AUTH=LOGIN<cr><lf>
00:26:25.322: << 250-STARTTLS<cr><lf>
00:26:25.322: << 250 HELP<cr><lf>
00:26:25.400: >> STARTTLS<cr><lf>
00:26:25.416: << 220 OK, begin SSL/TLS negotiation now.<cr><lf>
00:26:25.588: [*] SSL/TLS session established
00:26:25.588: [*] AES256-GCM-SHA384, TLSv1.2, Kx=RSA, Au=RSA, Enc=AESGCM(256), Mac=AEAD<lf>
00:26:25.588: [*] No peer certificate presented.
00:26:25.588: >> EHLO JimmyB<cr><lf>
00:26:25.588: << 250-mercurymailsystem.ca Hello JimmyB; ESMTPs are:<cr><lf>250-TIME<cr><lf>
00:26:25.588: << 250-SIZE 107286400<cr><lf>
00:26:25.588: << 250-8BITMIME<cr><lf>
00:26:25.604: << 250-AUTH CRAM-MD5 LOGIN<cr><lf>
00:26:25.604: << 250-AUTH=LOGIN<cr><lf>
00:26:25.604: << 250 HELP<cr><lf>
00:26:25.666: >> AUTH LOGIN<cr><lf>
00:26:25.666: << 334 HDFSLKjdfskchnge<cr><lf>
00:26:25.682: >> sdflkjfchangea;<cr><lf>
00:26:25.682: << 334 dfsalkjYUYsdlkjchange<cr><lf>
00:26:25.682: >> dfsalkjdfschange<cr><lf>
00:26:25.697: << 235 Authentication successful.<cr><lf>
00:26:25.697: >> MAIL FROM: <jbanks@APM.ca><cr><lf>
00:26:25.713: << 250 Sender OK - send RCPTs.<cr><lf>
00:26:25.713: >> RCPT TO: <jameshaven@outlook.com><cr><lf>
00:26:25.713: << 250 Recipient OK - send RCPT or DATA.<cr><lf>
00:26:25.729: >> DATA<cr><lf>
00:26:25.729: << 354 OK, send data, end with CRLF.CRLF<cr><lf>
00:26:25.760: >> From: "Jim Banks" <jbanks@APM.ca><cr><lf>
00:26:25.760: >> To: <jameshaven@outlook.com><cr><lf>
00:26:25.760: >> Subject: test 2<cr><lf>

Thanks. Yes, I understood you, and checked there were no connections at all and no .lck file when the problem client tried to log in. Although, for info, I have tested with another remote client and in that case it will connect even if there is a .lck file as result of a local client being connected.

I suspect it is to do with SSL and will try setting that up again from scratch.

It is solved. The solutions are:

1. Create an admin account for the Mercury Service: Create account 'Mercury Service'. Make this account member of the group 'Administrators'.

2. At the Mercury Service set this account for starting the service.

3. Restart service. 

For Outlook:

When delete the folder use the key 'shift' and click with your right mouse button on the folder for deleting. Select 'Delete Folder'.

If you don't use the key 'shift' Outlook want to move the folder to 'Deleted Items' and that's failing.

Mat 

I forgot about the synonym.mer file. I'm sure that's the puzzle piece I was looking for. 

Thanks Joerg!

Thanks Brian.  What you are doing makes complete sense to me, as you are only running one instance of Mercury D.  I am now rebuilding my server using the new installation of Mercury.

Gordon

Thanks.

This works: Putting the full file path 'C:\Mercury\smtp.txt'. In physical host there is only the name and works.

Angel.

[quote user="Joerg"]

...  They immediately recommend to remove programs like Mercury because it is no real server software and longer not maintained by the developer.

[/quote]

That's the easy way out - does not require thinking on their part. A bit like throwing the baby out with the bath water - they don't consider for a moment why the issue might be occurring, not realising that if you understand the cause you may be able to mitigate it, even if they think software is unsupported.

After working through the problem it became apparent that the problem isn't with the certificate but with iOS 10.3 and it's inability to replace an expired certificate with a new one.

Joerg,

Well your suggestion got the gear moving....I tried pausing MercD, then closing Mercury and restarting and pausing it, both no go.  What did do it was a machine restart, pause all services, and then add!  Not sure the pausing all was necessary but that is what I did and it finally stuck.

Got it saved now.

Thanks!

MP

Ok, thanks everyone for the help!

MP