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

David confirms the issue and has now added a fix for it in the upcoming maintenance release. Thanks for pointing it out! 

[quote user="ruler"]hi, i seem to have a few problems with someone hacking my mercury mail server and sending thousands of spam emails. Is there a way to limit how many emails can be sent per user or total sent per day? it is not a fix i know but it may help limit the amount of junk sent out. thanks[/quote]

How are you using Mercury/32 on your network? If you have disabled relaying controls and have open SMTP access then your server will be abused (and then blacklisted).

 We've investigated further and actually the killfile was working fine. Our mail client (not Pegasus) writes addresses to the killfile but also sends an automated response telling the mail sender that their address has been blacklisted (just in case they are genuine). It was a bug in the automated response that was causing the crashes. We haven't found out exactly what, but we have definitely pinpointed the root cause. Again, many thanks for everyone's help.

Best Regards

Duncan

Thanks Rolf.  I have been waiting for more evidence of this problem.

Today, I have received three messages from the same person.  One containing only text and one with images and a subject line were forwarded as expected to the two external accounts for which I have set up entries in Mercury's Global Filtering.  The third message had images but no subject line and wasn't received by the external accounts.   The transactions for all three messages were shown as successful in the SMTPRelay file (in verbose mode).

It occurs to me that my antivirus application might be the culprit.  I am investigating this as well.

 GordonM 

Ah, that's great news.

Glad I could help.  ^_^

MercuryB offers mailing list support via a web interface. Have you disabled it now?

[quote]ifnot subject has "a,e,i,o,u,1,2,3,4" and body matches "*http://*" weight 51 tag "empty subject link"

but it is catching a lot of messages maybe all that obviously have something in the subject.

Does anyone know where I am going wrong.[/quote]

"has" wants a wordlist. Normaly letters are indicated to be a word by having a blank in front and afterwords: " word " (OK - may be a point or so afterwords and no blank at beginning of subject :-). I think, most subjects will not include these letters and numbers standing more ore less alone. That's gone wrong.

I'm not shure, if one of these is possible, so try it yourself:

ifnot subject matches "" and body matches "*http://*" weight 51 tag "empty subject link"

ifnot subject matches "?*" and body matches "*http://*" weight 51 tag "empty subject link" 

 bye    Olaf

Thanks for the update :)

It DOES hit, and that's the problem.  Numerous false positive hits in headers searches due to detections in the content of the X-Ham-Report header.