We have a beta version up and running, and there has been no problems reported for the new SSL parts, but no release date yet.
/Rolf
Hi All,
Just wanted to share this with you:
So far, I had the first 3 check boxes in the "relay options" active and thought that this should be OK and save. In addition to that, I use stunnel together with mercury on a windows box since the mercury SSL implementation is not really "stable". So far, so good, and I also had "127.0.0.1" added as an allowed IP to send mails through mercury because of several applications running on the same server which should be able to send mails without authentication (web mailer and other things). This made life easy for me ;-). It worked OK for over 3 years but last week I got hijacked and had a thousands of spam mail sent through my mercury installation and it took me quite a while to find out what was going on. In this is it:
So far, all spammers tried to connect to mercury through port 25 and so they needed to authenticate because of my "relay option" settings. They tried different user+pass combinations but they never made it through. But this time they tried to connect through port 465 using SSL and suddenly stunnel came into play. On windows, stunnel "forwards" the incoming traffic to the underlying application with IP 127.0.0.1 and suddenly the spammer was accepted without authentication!!!
Still not sure if this is a bug or a feature but this is how it is. I now use option #4 (only authenticated mail should be accepted) and changed all local running software to authenticate correct with user and password but I don't like this approach.
What are your thoughts about this?
Best
Konrad
stunnel is a very good tool, but every time you involve third party software things get more complicated and settings may need to be adjusted. In this case the whitelisting of 127.0.0.1 was obviously not compatible.
The upcoming 4.80 version of Mercury will use OpenSSL instead of Cryptlib, which should solve all SSL problems.
/Rolf
