So long as your relaying options are set appropriately in the SMTP module and you don't allow remote connections to send mail you can ignore these. It may look like a lot is going on but your legitimate mail, inbound and outbound, will still be delivered.

You should check all the boxes and that will only allow users that have a password to send email.   The only hole in the system (might be) that they are not all checked by default.

Nobody has replied to this in over a week and I suspect it's a problem nobody else has had before.

I've never had to change the mail destination address in the server (and I've never used "rewrite") but it seems that it can't be done by that method.

Can you give more detail one why you need to change the domain on mail (is it incoming or outgoing) and what the "issues" are that you get when the To: address doesn't match?  Maybe someone here can suggest another solution.

[quote user="Brian Fluet"]

... Some of them are "blind link clickers" and "mindless attachment openers" so if I see a message that is of concern malware-wise I want to get it out of other mailboxes as soon as possible. ...

[/quote]

Brian

I have to give security awareness training sessions where I work which educates staff so they can look for the tell-tale signs of malicious messages and social engineering techniques. If you send me a PM with your email address I will send you a copy of my notes if you'd like them (18 pages). They contain examples etc., of alerts and are useful to give out to attendees as they can use them for their personal devices as well.

Hi!

I have couple of local receiver addresses in Exclude - section,  and in spamhalter log file there is message regarding of these addresses:

I 20170214 035036.021 MG00D28E Receiver excluded

 So, I think it is for local receiver, but it is interesting, if Lukas can clear up this.

:)

 Jyrki 

 Edit: Actually, My addresses in exclude sections are remote addresses from Mercury point of view, because they are in our Exchange server. So, maybe exclude section is for to - addresses (local or remote), as you said..

Hello.

I have a Mercury site at home with this configuration from About dialog. Runs in Windows 7 Professional SP1 64 bits in Spanish.

Mercury/32 version: Mercury/32, v4.80.149, Aug 18 2015

Operating mode: Standalone

Windows version: 6.1

MERCURY.EXE directory: C:\MERCURY

Base directory: C:\MERCURY

New mailbox location: C:\MERCURY\MAIL\~N

TMP environment variable: C:\Temp\angel

TEMP environment variable: C:\Temp\angel

[No license installed]

All works fine but from time to time, the TCP/IP protocol is blocked outgoing. I can't browser any web page, all browsers fails: IExplorer, Firefox and Maxthon. But there are incoming connections: web server Apache, FTP server, etc. The solution is reboot computer.

I revised all programs use TCP/IP heavily and I found this in Mercury. The module MercuryD (POP3 client) polls mails each 5 minutes from several servers and accounts (telefonica, gmail, yahoo, etc). As you can see in the log session, first this Warning: SSL connection improperly closed by remote host. In the next poll, this error OpenSSL timed out during handshake. After that, the TCP/IP protocol blocks outgoing communications. Any ideas what it happens. Don't hesitate to request more info. 

Thanks a lot. Angel.

01:12:26.798: --- 21 Jan 2017, 1:12:26.798 ---

01:12:26.801: Connect to 'pop.gmail.com', timeout 10 seconds.

01:12:27.953: SSL/TLS session established

01:12:27.953: ECDHE-RSA-AES256-GCM-SHA384, TLSv1.2, Kx=ECDH, Au=RSA, Enc=AESGCM(256), Mac=AEAD<lf>

01:12:27.954: Peer's certificate name is '/C=US/ST=California/L=Mountain View/O=Google Inc/CN=pop.gmail.com'.

01:12:27.954: >> +OK Gpop ready for requests from 88.XXXXXXXX f35mb135943214wrf<cr><lf>

01:12:27.954: << USER XXXXXXXXXXX<cr><lf>

01:12:27.985: >> +OK send PASS<cr><lf>

01:12:27.985: << PASS XXXXXXXXXXX<cr><lf>

01:12:29.233: >> +OK Welcome.<cr><lf>

01:12:29.234: << STAT<cr><lf>

01:12:29.438: >> +OK 0 0<cr><lf>

01:12:29.439: << QUIT<cr><lf>

01:12:29.595: >> +OK Farewell.<cr><lf>

01:12:29.598: Warning: SSL connection improperly closed by remote host.

01:12:29.599: --- Connection closed normally at 21 Jan 2017, 1:12:29.599. ---

01:12:29.599:

01:17:46.538: --- 21 Jan 2017, 1:17:46.538 ---

01:17:46.541: Connect to 'pop.gmail.com', timeout 10 seconds.

01:17:57.556: OpenSSL timed out during handshake.

Well, as you probably know, make sure your data and system state is fully backed up before moving forward. The RAID card firmware may not be OK, as I recall when upgrading a server from 2000 to 2003 I had to upgrade the firmware of the PERC card so that it would interact with 2003. Can you not buy a new server, instead of upgrading an existing one?

Also, the driver will probably be OS specific so the Win 7 setup process may not recognise the card and won't see the drives. However, if you're prepared to simply perform a fresh install of Win 7, do a backup and buy a new Win 7 compatible RAID card and use that. But, I suspect that Brian's option of simply using a Win 7 desktop for Mercury may be the easiest option.

[quote user="Sr. Grumpy Bear"]Thanks for the  suggestion of Petr's daemon.  Will check into that.   Still thought though that Mercury has (had) something built into it.  

[/quote]

I think all Mercury server modules do have limits built in - but they only auto blacklist on multiple failures during the same connection.  It doesn't count attempts made on new connections.

Hi Rolf,

Is it just a coincidence?  See my next post on the number of Password failures.  :) 

I can understand and fully accept that companies need to verify email accounts, get rid of the closed and miss typed  accounts.  But like I had stated, this is a private account, not used for companies and such.  I have Gmail, Yahoo, Hotmail etc. to use for them.  Let there servers have the marketing tools requests. 

For now, I guess I will just leave it unblocked, but will watch it. 

 Thanks for your thoughts. 

We have two branch offices. Email to users at these offices comes to Mercury (v4.80) at our main office (eg user1@eslers.com.au) and is redirected to the appropriate site using aliases (eg user1@branch1.eslers.com.au).

If a user at a branch office sends an email to a user at head office with delivery confirmation, Mercury seems to attempt to send the confirmation email ignoring the alias for that user, so I can see on the MercuryE window:

15:50:48: processing job MO005185
Resolved MX for 'eslers.com.au' to 115.69.20.109
Connecting to 115.69.20.109
Connection error.

There seem to be two problems here. One is that the module handling the delivery confirmation ignores the alias, and the other is that Mercury is using MercuryE to send to a local address.

Does anyone know how to fix this?

Pat

So far that seems to have got it. Thanks!

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.***