This page is out of date, please use our new website

Securing the Server SSL settings

SurgeMail SSL / TLS support

SSL is fully supported on all protocols to ensure username and password are safely encrypted when sent over the internet so that they can't be stolen 'on the way past'. If you are running a mail server that doesn't support this feature then essentially anyone with access to your network can steal passwords. Almost all popular email clients now support SSL/TLS. Data is also encrypted, however be aware that when sending mail to other mail systems the data will be unencrypted on the journey, so only local Email is fully secure.

POP: Secure to regular port using STARTTLS, secure to dedicated port.

SMTP: Secure to regular port using STARTTLS

HTTPS: All web based administration tasks can be done either using secure HTTPS or standard HTTP.

Mirrorring: The in-built server mirrorring feature mirrors the server over a secure link.

SurgeMail SSL/TLS Frequently Asked Questions

What is SSL/TLS and how secure is it?

SSL/TLS is the same encryption system used by 'https' web pages. It is generally considered to be the most secure method for sending sensitive information across the internet, and is the basis of most ECommerce security systems used today.

You will need a server private key (do not give this to anyone) and a matching Certificate which the server sends to the clients upon SSL handshake. The intermediate step is the Certificate Signing Request (CSR). This is generated from your private key and used to generate the certificate.

Settings to allow/enable SSL

The basic settings you need are:
g_ssl_allow "*"
g_ssl_try_out "*"

If you want a certificate for each domain then also set: 
          g_ssl_per_doimain "true" 

Lastly, surgemail does support SNI (which allows you to use multiple SSL domains on a single ip address), but be sure to specify a mail 'a' host entry using URL_HOST for each domain.

How to generate a Certification Signing Request to get a CA signed key

Stop, instead of this process, use LetsEncrypt if possible (it is simpler and free).

SurgeMail automatically generates untrusted certificates when required. For high level security you should consider getting your own trusted server certificate. This means that clients can be sure that they are talking to 'your' server and not just someone pretending to be your server and means that warning messages do not get displayed when connected using a browser or mail client attempting to use secure connections.

CSR generation is now built in to the surgemail. Simply go to the " SSL Certificates Configure" link on the globals page of the web admin. From here you can check the state of the current certificates for your domains and create a CSR and update SurgeMail with your signed key. Press the New CSR button to generate a new private key and matching CSR and untrusted certificate. Copy the CSR text and send this to your certification authority. You should be sent back a signed certificate to replace the automatically generated certificate - just paste this in the SSL Certificate(s) pane and press save. You will need to restart SurgeMail to get SurgeMail to use the new certificate.

Some certifying authorities issue trusted certificates based on a trust chain that involves an intermediate certificate. It you are required to install an intermediate certificate by your signing authority you can just place this in the surge_cert.pem file as follows (SurgeMail 1.5e+):

    <begin surge_cert.pem file>
    # Issued certificate for
    -----END CERTIFICATE-----

	# Certifying authority intermediate certificate(s)
    -----END CERTIFICATE-----
    <end file>

Some certification authorities you could use are:

DigiCert (

As an alternative you can manually generate the the same files using the openSSL binary (not distributed with SurgeMail ):

openssl req -new -nodes -keyout surge_priv.pem -out surge_csr.pem -newkey rsa:2048

WARNING: If using GoDaddy certificates, be aware of a reported naming convention clash. To get your intermediate certificate you will want to download the "bundle" and not the "intermediate certificate".

Restricting Access by IP Number

Many of SurgeMails features can be restricted to certain IP number ranges. This can be used to make the system more secure.

One feature that is that should probably be restricted is the g_admin_ip setting to limit the valid IP addresses for SurgeMail server admin users.

You should also look into the following settings that control which connections will use SSL:

Relay restrictions

It is important to ensure that your system is not setup as an "open relay", as this is likely to result in spam being sent through your system and your mail server getting black listed by open relay databases.

SurgeMail "out of the box" is configured to not relay other than allow relay after POP login which, in general is safe and allows people using old mail clients (that do not know how to do SMTP authentication) to still send through your server without making your server an open relay.

A setting you may want to enable is g_relay_allow_ip for your mailserver's own IP address as this will enable other programs running on the system to send mail without needing to use SMTP authentication. Do not set this to * as this will make your system an open relay.

Other ways of enabling relaying is by destination domain (g_relay_to) or known from address (g_relay_allow_from).

Restricting mail services per user

Groups can be setup with rights to access POP, IMAP or SMTP services that will allow per user setting of access privileges. See managing accounts for more information.


SurgeMail supports CRAM-MD5 SMTP authentication, but ONLY when using the NWAuth authentication module. To enable CRAM-MD5 set the g_smtp_cram_enable setting and restart SurgeMail.

This setting will cause NWAuth to begin converting the stored passwords from their existing format into one that can be used for CRAM-MD5, as such users will have to login once to pop or imap before they can use CRAM-MD5.

WARNING: The stored CRAM-MD5 passwords are not as secure as NWAuth's default SSHA passwords, they are only marginally more secure than plain text. A better solution to password security is to use SSL / TLS.

Certificate file format conversion

You can convert pfx certificates to pem using the following openssl command:

openssl pkcs12 -in {something}.pfx -out {something}.pem -nodes

If the certificate is protected by a password, you will be prompted for the password. Enter your password and the export is done.