A side affect of trying to understand the SmtpEvt daemon is that I now have a better understanding of the options in the MercuryS Compliance tab and of the potential value of transaction filtering as way to immediately blacklist an IP address that has been identified as repeated trying to gain access.  My "refuse" entries in Connection Control have been removed opting for transaction filtering rules instead. 

I've standardized the rules as per below with only the IP address changing but welcome suggestions on a better or more appropriate way of doing this. 

H, "*192.156.225.99*", BS, "554 Relaying not allowed - connection dropped" 

I'm anxious to see the effects of this change in conjunction with SmtpEvt.

From the command line, you can run the following commands to create firewall rules that ban all traffic to and from an address:

netsh advfirewall firewall add rule name="From 1.2.3.4" dir=in interface=any action=block remoteip=1.2.3.4/32
netsh advfirewall firewall add rule name="To 1.2.3.4" dir=out interface=any action=block remoteip=1.2.3.4/32

That would be a good option to check.

Another would be to see if the FQDN in a HELO resolves.

Wow!  You've done considerable work on this since 2014 when I last downloaded it.  I'm looking forward to digging into it. 

Thank you!

I have to admit that I have never used Pegasus Mail to set up an IMAP client. However, I assume the procedure is the same.

[quote user="GordonM"]

Thank you for the clarification. The fact that John from the UK was able to connect to Rogers' SMTP service presumably means that his ISP is not blocking port 25 connections from "foreign" sources. This is, perhaps, surprising these days.

Gordon 

[/quote]

Indeed - I'm with Zen Internet, and they do not block or otherwise interfere with anything. I have a /29 IP block which is fully configurable from my ISP dashboard, so I can create DNS records for my IP range without having to bother anyone at Zen.

John.

thanks!

How are you running Mercury - as an app or a service?

Also, I had an issue some time ago when it was on a multi-core processor and I had to tie it to 1 cpu.  See if that helps at all.  (I have to say this problem hasn't affected me for some years with the latest Mercury version.)

Not sure but maybe try  ~D

The manual says it is the date in proper RFC822 format

An associate of mine helped to expose this .dmp file content (similar content it multiple .dmp files):

Exception code 0xC0000005

The thread tried to read from or write to a virtual address for which it does not have the appropriate access.

Unhandled exception at 0x001A03BB (mercury.exe) in 181024-100247.dmp (interesting that this is the source .dmp file).

Access violation reading location 0x062DBCF0.

I think you missed the message previous to yours, where the solution was posted.

[quote user="Brian Fluet"]... A known solution is to use the Pegasus Mail Notsplit utility to generate message files from the .PMM for re-integration back into Pegasus Mail folders but what could the approach be when Pegasus Mail is not in the picture?  An obvious answer of placing the .cnm files into a mailbox directory isn't practical when there's hundreds if not thousands of them.[/quote]

I believe in that case you've got a problem. Also in case your server (where Mercury is running) or your accessing client is a 64bit system, any IMAP client wouldn't access the mailbox directly but always via the 32bit Mercury-I. And 32bit software can address max 2GB of RAM (except some special cases of 32 bit software which is able to address up to 4 GB). Don't know whether other (64bit) IMAP server are able to access Mercury/Pmail mailboxes? Maybe someone has tested it already?
I regularly check the mailboxes of my users and carry out a search for files larger than 1 GB. If I find something, the user get a message to remove big attachments or to create a new mail folder to avoid a further increasing.

ClamAV 0.101.1 Patch has been released.  This version fixes a header problem for developers.  It doesn't appear important to us but I expect we'll soon start seeing 'version out of date' entries in the log.

https://blog.clamav.net/2019/01/clamav-01011-patch-has-been-released.html

15:37:15.971: >> 554-Bad DNS PTR resource record.<cr><lf>

The arrows pointing to the right denote the remote server's response/query (arrows pointing to the left are your server's responses/queries).

As Rolf says you need to ask your ISP to set a PTR (PoinTeR) record (a reverse lookup record which the opposite of an A Record).

As you are probably aware a DNS query for a name requests the A record so that the name (e.g. google.com) can be resolved to an IP address. A reverse record, known as a PTR record allows you to resolve an IP address to a name. Mail servers use it as a way to ensure the name the server announces itself as matches the IP address the mail message originated from.  

I think there is no need for enable > fetch > disable or not in every case. Are the iDevices from your company? If so, then let the guys run the vpn the entire time or at least for the working hours.

[quote user="Rolf Lindby"]I sent an email June 25th with the download link, let me know if I should resend. [/quote]

Has been caught in the spam filter [:$] 

4.80 backed up and 4.81 installed (update option). Setup without any problems. Mercury is running as usual so far. I will report in case anything is weird.

Thanks Rolf.

Hallo  Brian

I find this message in every logfile since 2016, so it seems it's completely normal. Why, no idea ...

 Best wishes,

Thomas

Hello Jerry,

Transaction filtering supports the "M" command which checks the Mail From field of the header. I use commands like this to filter unwanted "From" domains

M, "*.magix.net*", BS, "554 Sender MAGIX.NET is sending unsolicited email - connection dropped."

For instance,

Hope this helps

John.

Hello Bruce,

Please see this link - I think your issue is to do with Google account security, and this KB article should help.

https://support.google.com/accounts/answer/6010255?hl=en

I would start by making sure that the settings in Pegasus are correct for Google security.

Hope this helps

John.