Content control progress isn't logged so there wouldn't be much of use in any of the log files.

Mercury requires very little system resources, so unless there are thousands of messages coming in every hour or very many concurrent IMAP users just about any kind of PC should handle it. If we could have a look at one or both content control files we could see if the problem is repeatable. They need to be zipped though to preserve the encoding.

I can't see any reason why content control should stop working. Try doing some controlled testing to see if it's a problem with the rule file or some general issue. (Create a new rule file with a test rule, temporarily deactivate the other rule file, and see if the new rule triggers.)

I would suggest updating to v4.80 as well, even though it should make little difference for content control.

Thanks Rolf,

I've downloaded your event daemon, and will play around with it tomorrow. It looks like this should put a crimp on AUTH LOGIN abuse.

The more I get in to Mercury the more I like it - it has some very powerful features like the transaction level filtering, and the ability to add third party daemons.

I'm liking this a lot.

Thanks again for your time Rolf.

John. 

[quote user="Rolf Lindby"]

So apparently there is something in the Windows 2000 Server environment that is causing networking issues. If there is any local anti-malware or firewall software running you could try disabling it. Doing a Telnet connection on port 25 to one of those destinations might give additional information. 

[/quote]

Hello Rolf,

Sometimes it's the simplest things that throw you!

I spent several hours going through the server's Policy, and Active Directory settings to no avail. Firing up a command prompt and Telnetting to one of the IP's as you suggested, came back with an almost instant failure. (Unusual as Telnet normally takes several seconds to time out if there's a problem). Checking the router's NAT Sessions table showed no port 25 sessions from the server,  which is a sure sign that something was blocking the connection.

Running on my ageing server is an equally ageing copy of McAfee VirusScan Enterprise which has an Access Protection definition for preventing mass mailing viruses from using port 25.

Adding Mercury.exe to the exception list solved the problem and Mercury proceeded to disgorge the contents of its queue to the wider internet, rather like a drunken British teenager empties his stomach after a Friday night binge! :D

Thanks again for your help Rolf

John. 

[quote user="Rolf Lindby"]Sorting of messages is expected to happen client-side ...[/quote]

Full Acknowledge. But K-9 Mail (Android) is reading only the last 25 (or 50/75/etc) mails from the inbox.pnm index.

[quote user="Rolf Lindby"]And I don't think the

server is aware of headers or other content in CNM files when updating

the _INBOX_.PNM file.

[/quote]

I had  the problem after a rebuild of the index.pnm, for testing a lots of new problems with Mercury, like permanent mail downloads & out of disk space messages, which were present due the update from Thunderbird 24.x to Thunderbird 38.x. on some PCs.

Hi!

 I think you should use some status code after "R". From transaction filter example file:

 H, "*192.156.225.44*", R, "554 Get out of here, you worthless scumbag."

Regards

Jyrki 

If you retrieve messages using MercuryD and Mercury logs show no incoming connections at all it could be that the Windows firewall on the server is blocking access. If that's not the case you could try establishing a connection to the server with Telnet to see what happens. To connect using SMTP (port 25) open a command window and enter telnet mailserver 25 (replace "mailserver" with the IP address of the server). 

If you are sure Mercury won't at all be connected to the Internet you can consider unchecking all checkboxes in  in MercuryS configuration/Connection control/Relaying control, which will stop having Mercury require authentication for non-local mail. Other than that it's up to the connecting client to handle authentication in a suitable way - either not try to authenticate, or authenticate with a username/password that exists in the AUTH password file (same configuration tab).

A couple of thoughts...

The path where you placed the copy must be identical to what you had on the Win7 machine.  Same goes for the configured paths to mail folders, logs, queues, etc.  A subsequent install would require removal of the copy first as Greenman noted.

Be sure Mercury is not be installed inside of \Program Files.

As for any commandline options, the help file mentions mercury.exe commandline switches in the section about loader.exe but only by reference.  I can not find details on what they are either.

I am half a step ahead of you. In a funny sort of way. It has been determined that there has to be a diagnostic text in the rule.  Which I have not been including.  I have added the text "Bad HELO greeting".  This now shows in the SMTP log.  So we now know that the file is being processed.  However, the 'D' command has been ignored as in the session log it still shows as connection being made.  As a test I have just now changed the drop command to refuse and will see what happens from there. 

I suppose you could try"

if sender matches "*pkginfo@ups.com*" AND body matches  "*<my company name>*" weight -100 TAG "likely genuine UPS message"

I'm not sure why your rule wouldn't work but I kind of remember having some kind of problem with the contains rule myself which is why I only use matches - don't forge that you need the * at the start and end of whatever you want to match

Mercury will by default store the password for POP3 and IMAP in a file named PASSWD.PM in the user's mailbox directory. If these files are included in the backup then passwords are preserved. The exception is if an addon for verifying against another source such as Active Directory or Netware has been installed, but if so there is presumably already backup for that.

Well, Internet routing issues, certificate issues, bad wifi connections, bad 3G/4G connections or pretty much anything that is part of the network connection between the mobile device and the web server that provides the images. 

There are many ways to do this in Mercury, and which one is best or easiest depends on what you are trying to achieve. If you want to forward incoming mail for a specific mailbox the easiest is probably to use the automatic mail forwarding feature (Configuration / Manage local users), which is available if "Allow file-based forwarding specification using FORWARD file" in Core configuration / Advanced is selected. You can add as many recipients as you like.

Filtering rules are much more powerful tools that allow you to control delivery of messages passing through Mercury in different ways, but they may require some basic understanding of programming logics to use. Brian's example of a global set of rules (each line is a separate rule!) was based on having a rule (in this case triggered by a specific sender) jump to a label to execute a number of rules, finally exiting rule processing. Check Mercury help or the PDF manual for more information about rules.

A third option would be to create aliases and link to general rulesets. If you have a lot of different forwarding cases based on recipient address this will be more manageable than creating very many global rules.

Hi Rolf,

wow ... thank you very much! Seems in future I should look for some more reasons for those errors.

[quote]It checks to see whether the user part refers to a Group that has been defined in the “Groups” page of the Mercury Core Module configuration dialog.[/quote]

Did know that and have some groups defined in Mercury pointing at groups in NDS/eDirectory (Novell User Management Database).

But I didn't realize what happens if the userpart of the mailaddress is the same than a groupname in NDS. The problem was: no errormessage by Mercury than a mail with "Recovery from abnormal termination" to Postmaster and similar entries in Loader.log. A hint like "New mailbox directory missing" would have been nice ... because a existing user in NDS, who deleted his new mailbox directory located in his home directory on the server, results in same behaviour of Mercury.

I think even without NDS and simply defined usernames/mailboxes with Mercury and Pegasus, the result would be the same if that directory is deleted or renamed: termination of Mercury. Can't test it due to NDS ... perhaps somebody else?

thanks    Olaf

I've basically given up on Mercury IMAP. IMAP problems are the #1 reason I'm having to migrate our company from Mercury to Exchange. Granted we're probably a worst-case small business scenario for any IMAP server.

* 50 employees, half of whom carry iPhones or iPads for email.

* Outlook 2007, 2010, 2013, and 2016 are all in use around the company. And the CEO carries a MacBook.

* Half our workforce works from home or travels 75%+.

* We have staff who assume it should be possible to have slashes and ampersands in folder names, and deeply nested folders.

It's perfectly typical for me to see some employee mailboxes with 10 connections to their mailbox, given the way they "flip" between iPhone/iPad and Outlook client throughout the day, or attempt to use email while traveling/in flight on dodgy airline WiFi. 

Most other Mercury features have been flawless: POP3, forwarding, aliases, mailing lists, you name it.

IMAP with mobile devices + Outlook clients is a disaster. I reconstruct a mailbox each month, on average.

A user needs to be connected to the server to authenticate, so if you immediately refuse the connection (based on IP address) there will never be a chance to authenticate.

There is however an option in transaction-level filtering (found under MercuryS configuration / Compliance) to use deferred HELO processing. Connections that otherwise would be refused will then be allowed to attempt to authenticate to avoid being shut down.

Locate something in the rejection notice that you can filter on then add a global rule that deletes the rejection and breaks the cycle.  For instance, I have an expression filter that detects "*550 5.7.1 Backscatter DSNs not accepted*" and deletes those messages.  I don't specifically remember the service the generates this content though.

No, Rolf. I'm using "Refuse messages that have no or empty 'subject' fields" in the SMTP server module.

It seems, the folded subject-header is not properly interpreted.

Some minutes later: There is only a space and not a whitespace in the folded  header and that isn't RFC conform [:@].

my very first rule is
If expression headers matches "*received*from bouncejimmyspam*" Goto "jimmyjim"

 bunch of other filtering rules here....

my last two rules are:
Label "jimmyjim"
Always Exit ""

I then configured Pegasus mail to use this name in the helo

bouncejimmyspam

The odds of a spammer using that exact string is pretty remote