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.

There are issues if the fairly old SSL libraries in Mercury 4.74 and earlier if used together with clients that follow newer SSL standards. For that reason v4.80 of Mercury, that is in release candidate state at the moment, will switch to use OpenSSL.

paul- thank you.

Rolf, I am using xampp control panel 1.8.1  Mercury is one of component in xampp package.  I do not understand third-party tool-xampp?. thank you

Hi Rolf

Thanks for the info, that explains that. Will wait for the update before using the service.

Rolf, I see. I think that I am going to keep it as default. It is good to know that there is no bug here. thank you! have a great day! 

If a client isn't allowed to establish a connection to the server it won't even be able to try to authenticate. To prevent unwanted relaying I would suggest checking both "Use strict local relaying restrictions" and "Authenticated SMTP Connections may relay mail" to have all clients connecting from a mobile device or otherwise from a not trusted IP address authenticate. If you want users on your trusted IP ranges to be able to send mail without authenticating you can check "Connections from this address range may relay mail through this server" for each trusted range.

[quote user="bryroller"]

Sounds like a viable option because (I believe) there is much less administration than I currently have to do and it is free. Change my MX records and it should start working - sounds similar to Postini, et al.

I currently use transaction filters, content filters, blacklisting, DNSBLs, SpamHalter, ClamWall (with optional spam definitions) and my Mercury/32 system processes 69,000+ messages daily. Keeping on top of the spammers is still difficult. I cannot block delivery from any part of the world (I add that because I am sure someone will offer that as a "solution"). GrayWall has caused me some issues due to form messages (PHP, etc.) not being able to "retry" delivery so I have it turned off.

Very interested in any opinions or alternatives anyone has to offer.

[/quote]

Like you I have turned GrayWall off and that appears to have made little difference - my spam levels remain very low.  DNSBL & transaction filters stop the majority from even entering the server, and ClamWall & SpamHalter stop most of those that are accepted.  I don't bother with content filters.

I have not used MX Guarddog but it seems a novel way to provide a free solution.

Oalf, thank you!

 I checked the three options under "compliance" tab.

1) limited maximum number of failed RCPTS to 4  

2) require clients to use an ESMTP size declaration.

3) Refuse messages that have not "date" field.

Thank you for helping!!!

To be able to use MercuryS to receive mail you will first need to verify that your ISP allows access to port 25 (SMTP). If this is the case you will then need to point the MX record for your domain to the public address of your mail server. The MX record is expected to contain a hostname (like mail.mydomain.com), not a numerical IP address.

[quote user="bfluet"][quote user="PaulW"]Usually STARTTLS is offered by a server to a connecting client.  If the client doesn't want to use it, it can ignore it and just use plain text.  Do you know how Printboss uses the mailserver - in, out, or both?[/quote]

Print Boss is primarily a Quickbooks check printing app but has the capability to email and fax documents from other apps.  From what I can determine, it only sends documents.[/quote]

OK, but the info you quote from Wellspring Software is puzzling as STARTTLS is nothing to do with authentication or authorisation.  I'm guessing that what they mean is that Print Boss can't authenticate to a relay server (MercuryS config / Connection control - Relaying control, last 2 checkboxes).   You will have to allow relaying through the IP address in the top part of that tab.

Rolf, I see. thank you for helps!!!