Optimal Security on Standard ports is as follows
SMTP = 25 with StartTLS optional
SMTP Submission (from a mail client) = 587 with StartTLS required
SMTP over SSL = Port 465 with SSL/TLS
IMAP = 143 with StartTLS Required (the less secure StartTLS optional is OK until all of your mail clients are set up appropriately)
IMAP over SSL = Port 993 with SSL/TLS
POp3 = 110 with StartTLS Required (the less secure StartTLS optional is OK until all of your mail clients are set up appropriately)
POP3 over SSL = port 995 with SSL/TLS
You can use the same certificate for StartTLS Required, StartTLS Optional and SSL/TLS
#2. In your IP ranges you can choose to 'Require SSL/TLS for authentication'. Despite the wording StartTLS is ALSO acceptable. The check box forces some form of encrypted connection when someone authenticates from an IP in that range. I have that set for my internet range (and all ranges really) - but it doesn't stop would-be spammers from testing my server. They simply encrypt the connection before they try to break in.
#3. at the bottom of your hMailserver.ini file (in the /bin/ directory) if there is no section labelled '[Settings]' - including the square brackets but not including the quote markers, then add it to the bottom of the ini file.
Under that heading put this
That will stop malicious users from trying to authenticate (trying to break in) via port 25, but still allow server to server communication on port 25. If you have StartTLS Optional on port 25, then mail servers like gmail or Outlook.com will send via StartTLS
Code: Select all
DisableAUTHList=25 ; Setting DisableAUTHList allows you to specify a comma-separated list of SMTP ports which authentication should not be enabled for. ; This is useful when working with legacy systems with malfunctioning SMTP support.
If you wished to send via StartTLS whenever possible (and this doesn't require any certificates) then check the box in Protocols >> SMTP >> Advanced >> 'Use StartTLS if Available'
ALTHOUGH because you use a SMTP relay, you set the security in that section and ALL mail is sent via that security mechanism to the SMTP relayer
#4. In Advanced >> SSL/TLS settings in the hmailserver admin GUI, there is a list of SSL/TLS ciphers. The default list is OK, but you can research and remove some of the less secure ones. You can also add some tougher ones, but you need to be sure that whatever is going to send to you mail via an encrypted connection will need at least a common cipher
Also on this page is a checkbox 'Verify remote server SSL/TLS certificates'. This does little, unless you specify a route, or an SMTP relayer, then the certificates that answer will be checked against the domain name MX records. Many MANY businesses and government departments in Australia fail this test, and this is typical in much of the world, with the exception perhaps of Germany who get it right much more often. This checkbox is selected on my system without issue, but I know that others have experienced deliverability issues with this checked.
You should uncheck whichever 'Versions' you can starting from the top down.
TSL is SSL on steroids, TLS v1.2 is much better than TLS v1.1 which is much better than TLS v1.0.
SSLv3.0 is easily crackable and should be deselected if you possibly can. I have ONE legacy Video recorder that sends email, that will only support SSL3.0 and not TLSv1.X I have asked the manufacturer to upgrade this but the really don't care enough or understand this stuff enough to do anything about it. This PVR is only three years old and is a new product to market.
At present iPhones can ONLY use TLSv1.0 (my current iphone is iPhone 6PLUS and my IOS version is 10.11 - I expect that iPhone 7 is the same as they run the same IOS)
Windows systems can be MODIFIED to use TLSv1.2, by default they use TLSv1.1 or TLSv1.0. This affects the mail clients running on those systems, ie if windows can do TLSv1.2 then so can Outlook and Thunderbird running on that system.
#5. To be sure, you do realise that encrypted connections is NOT THE SAME as Encrypted messages.
Encrypted connections MAY secure the connection between your server and the next step (your SMTP relayer, another mail server or your mail clients), but does not mean that the next step in the deliver process is going to be via an encrypted connection. For example you may send mail to your SMTP relayer via an encrypted connection who then sends to the world's email servers in unencrypted connections, and there is no way that you will know.
Encrypted messages are created and decrypted by MAIL CLIENTS not mail servers. The server will see the message envelope, and the encrypted message. servers will be able to read the envelope, but not (easily) decipher the message. I work in Healthcare in Australia and we use message level encryption extensively here.