The certificate files are set by browsing from the Mercury configuration dialog and this works as expected. No, the files for MercuryS expression filtering and for MercuryI.ACL are not saved in the same directory as mercury.exe and i have to specify a path.

If you have the certs in the same directory of mercury.exe: then

it works as expected

If you browse to a different directory for the certs: then you have to specify the path:  

But the directory for MercuryI.ACL is not configurable. This means

if you have saved your certs outside the directory with the mercury.exe

then the MercuryI.ACL and other files are saved in the cert folder.

PS: The forum software need really an update. 

[quote user="Rolf Lindby"]

Pegasus and Mercury share the same file format for storing mail folders (PMM/PMI). If a mailbox is accessed only using POP3 no such folders will be created, but IMAP users are able to instruct Mercury to do so.

[/quote]

Ah! This makes perfect sense (why didn't I think of that!).

Are you able to post what is in your content file for us to have a look at.  Also do you edit the file inside mercury where you have the option to click "check syntax"?

Can you place a rule at the very top of the file that you know will trigger

if header "from" matches "*@*" weight 99

and see if it does, if it does then place it at the very bottom and see if it still triggers. 

I recall that mine stopped working once even though mercury reported it not having any syntax errors and it turned out ( I can't remember exactly) but it only stopped working after a certain point in the file.  I found the problem by simply moving a rule I knew would trigger in different spots in the file. 

Hope that makes sense.

Thanks Rolf, for that.   Makes sense.........

 I'll see if someone can help with fixing the Content Filter as a work around.

.les.

Hello Rolf

Thank you for your answer.

 You are correct. I was so confused of this buggy program megaraid monitor, that I mixed something up.

a sniff by wireshark showed that:

The problems were

a) the router that was not forwarding the non standard port 2529 to 25

b) the buggy megaraid, that did not take the port 2529 but sent the message to port 25

Uff

Moin Bernward,

Nothing heard from you since I've provided you with the screenshots of our spamhalter settings. Could you solve the problem in the meantime?

BTW: We are not using honeypots like Jyrki, just a simple "train yourself" setup.

Gruß

Joerg

Thank you John,

I am not sure how many times I had read through the manual and missed that.  That line has been added to the Tranflt.mer file.  

That's what I thought. Thanks Paul.

LINUX: How to use privileged/root ports (ports below 1024) as an unprivileged user running Mercury rather than utilizing port forwarding to higher ports.

---------------------------------------------

These instructions are for Ubuntu server 14.04.4 32bit with a minimal install of the MATE desktop environment. You may have to make instruction alterations to meet the requirements of your linux release, flavor and desktop environment.

For the sake of simplicity the unprivileged user in this tutorial will be steve. The default ***LINUX*** path to Mercury's home will be /lmc/D/Mercury. You MUST adjust the unprivileged user and LINUX path to your Mercury to fit your situation. I won't be mentioning this again.

Most of this setup work is done in a non-root terminal. In a couple of instances a text editor is called to edit files. I use MATE's pluma text editor when possible. Substitute your desired/available text editor in those instances.

---------------------------------------------

Step 1: privbind

Per the website:

"Privbind is a small tool allowing secure running of unprivileged programs, but allowing them to bind to privileged (<1024) TCP/UDP ports. Privbind has a secure design, with no SUID executables and no daemons."

Known to work on 2.6 kernel or better. uname -r in a terminal will display the kernel you're using.


Installation:

sudo apt-get install privbind


To manually run privbind:


sudo privbind -u steve wine /lmc/D/Mercury/mercury.exe


This will start Mercury by unprivileged user steve and allow you to configure Mercury to utilize port 25, 587, 110, etc.

---------------------------------------------

Auto-Starting:

You are probably going to want to automatically start Mercury at startup and maybe have a desktop or panel launcher, etc. That can be done utilizing the manual start command given above but there is a caveat. Steve starts Mercury with the command but root is required to run privbind to initiate that Mercury start. That requires sudo and sudo requires a password. An entry can be made in /etc/sudoers that allows steve to run a specific command without a password being entered for sudo.

Here's How:

sudo pluma /etc/sudoers


Add this after your other sudo user rules:

steve ALL=(ALL:ALL) NOPASSWD:/usr/sbin/privbind -u steve wine /lmc/D/Mercury/mercury.exe


Now, you can use the command ---

             sudo privbind -u steve wine /lmc/D/Mercury/mercury.exe

--- as the command in a desktop or panel launcher or Startup Applications entry because a password is no longer asked for for that specific command when run by steve. 

-----------------------------

That's about it.

I am not going to go into how to make launchers, Startup Applications, etc. Google is your friend.

*** Don't forget to update your firewall rules to open up the new ports you plan to use.***

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