Okay, I will unload MercuryC... and using Mercury/32... well, that means I will have to run an extra machine which I really have no idea to do. Maybe I can be forced to, but I will do a lot not to do it. One of the things I need to check is if there was a SMTP-server in the old Border Manager 3.0 (I can't find the licence to 3.5 although we had it) and that it can run on Netware 6.5 - a co advantage will be that I may run my own VPN which is handy when it comes to going to China etc. The downside is that I think I have to change my NAT and so on...

Other alternatives is to have all my stuff hosted outside or change to a Novell Linux server... but I am really not in any mood to look into a another system.

 

But still if somebody knows a way to move port and to ad user and password to a MercuryC.nlm let me know... 

Rolf

 

This sounds just the ticket. I'll look forward to buying the new release. Thanks for the response.

 

Duncan

Does anyone know how "secret" the password used to encrypt the private key that Mercury uses in it's cryptlib interface is?  I wrote a C# program to import an OpenSSL certificate/private key into the PKCS #15 file that cryptlib uses that I think others might find of use.  But, since it's un-obfuscated C#, and such a small program, it's much easier to discover the private key used from it than by looking at Mercury, a much larger C/C++ program.

I had previously been using stunnel which worked well for many years; but, an increasing amount of mail was incorrectly being marked as possible spam by SpamAssassin.  Something easily resolved by having clients connect directly to Mercury and whitelisting certain IP addresses.  I use a self-signed certificate created in OpenSSL and didn't want to distribute a new one, thus the reason for creating the import program.

You know you have to start the GUI in addition to the service? Mercury installed as service won't start the GUI.

bye    Olaf

 

Hi,

Since I have arranged an additional content filter (content control) in Mercury (v4.74), which is forwarding particular incoming e-mails to special mobile devices, some temp files ($$$) remain in the Mercury mail outbox queue. These files have to be removed manually from time to time.

Why Mercury does not remove them by itself?

Cheers

Joerg

[quote user="Rolf Lindby"]To allow for local users connecting from the Internet and authenticating use operation D instead of H in the rule.[/quote]

*Facepalm* I could not see for looking. Thanks!

[quote user="Rolf Lindby"]Mercury 4.74 does not use OpenSSL, so it's not at risk. In the upcoming v. 4.80 there will be a corrected version of OpenSSL.[/quote]I know but i must use SSL. Without SSL get i no connection to my mail-provider and with SSL have I annoying crashes of Mercury32.

 

[quote user="Konrad Hammerer"]If so, make sure to use the latest stunnel v5.01 as the prior versions are affected as well![/quote]Jep. Installed, old keys revoked and new keys created.

 

[quote user="bfluet"]

Following up to report my experience with adding Sanesecurity signatures including the Foxhole signatures.  They dramatically increase the number of quarantined message but a significant percentage of them have already been tagged as Spam by my domain host so would have been detected by existing spam filters.  I am still receiving messages containing a .scr file inside of an attached .zip so my original problem remains.  Some of these messages appear to come from a financial institution and are genuine looking enough that I hesitate to tell POPFile they are spam for fear of increasing the possibility of false positives.  I have considered creating a ZIP user and diverting all messages containing .zip attachments to it so I could review them messages before forwarding to the intended user but this does not seem very practical and would certainly cause delays. 

I remain open to new suggestions.

[/quote]

If you have executables inside zip files which are being missed by foxhole_all then please report them as errors to the relevant address found in Sanesecurity.

Thanks for you help, much appreciated.

Ahha, scratch the above I think I have found it, the new firewall has a slightly odd setting method....

I don't have an answer to your question but

you've solved my problem !

My Mercury D started refusing to accept configuration of servers to be polled.

It turns out, MercuryD.DAT had decided to abscond - don't know why...

However, creating an empty MercuryD.DAT seems to have got it working again.

So thanks for the hint.

If, meanwhile, having got my config up and running (it will include SSL connections)

I see an answer to your query, I'll let you know.

 Peter

 

Thanks a lot for your help, Brian.

"IP Interface to use" should in most cases be left blank to allow connections from all interfaces, as pointed out in Mercury help.

autosystems.com is a local domain but supplier.autosystems.com is not, so that should probably be added. (While you are at it you might as well switch on strict relaying restrictions for MercuryS too!) Please restart Mercury after making the changes. 

As for the Telnet problem when connecting from the DMZ it could be that the firewall/router is blocking access to it's external address when connecting from a local network.

 

Fixed.

The issue was with an autocomplete entry. Autocomplete was placing the alias in the To: field when clicking Reply. The solution was to delete the autocomplete entry from Outlook's list.

Could STATE.PMJ be the culprit?

Try creating an alias pointing to a general rule with a list of recipients, and use that in the content control action. 

Thanks.  That was it.  mercury is installed :-)

Now all I have to figure out is how to do the setup again.  I did it once, I can do it again.

Ride safe,

Joe

Hi, tank you for the information.

I have solved this issue. The problem was that those particular mails have been forwarded (bounced) by our own system from another of our e-mail address. That's why our own domain name was also listed in the mail header. And our domain was white-listed. Now I have removed our own domain from the whitelist.