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, "*220.127.116.11*", BS, "554 Relaying not allowed - connection dropped"
I'm anxious to see the effects of this change in conjunction with SmtpEvt.
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.
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.
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.)
[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.
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.