MailerQ comes equipped with a full MTA management console. The management console allows you to monitor the performance of your email delivery in real-time. If necessary, the management console can be used to change settings to maximize deliverability on the fly. If you have multiple instances of MailerQ running in a cluster, you can easily switch between them.
The management console can be enabled in MailerQ's configuration file. The following variables should be used:
www-port: 8485 (default: 8485) www-ip: 220.127.116.11 (default: 0.0.0.0, meaning all available IP's) www-password: admin (empty by default) www-dir: /usr/share/mailerq/www (default: /usr/share/mailerq/current/www) www-connections: 10
www-port variable holds the port number for the management console;
8485 is the default. If you use port 80 (which is the default port for HTTP
traffic) you can access the management console with using a browser via
http://hostname.of.your.server. If you assign a different port number
(like 8485), you must include the port number in the URL:
In its default setting of
0.0.0.0, the management console is accessible via
all IP addresses that are assigned to the server on which MailerQ runs. If you
only want to make it accessible via one specific IP, you can set the
variable. Of course, the IP address that you assign must be bound to the server.
The management console is protected with a password to prevent anyone from
accessing it. This password can be set with the
variable. Besides setting a password, we also recommend to put the
management console behind a firewall so that you will not have to worry
about people breaking into it.
console are automatically installed into the
directory. If you want to run the console from out of a different
location, you can change this directory with the
To limit the number of resources that can be used by the built-in HTTP server, you can use the "www-connections" variable to limit the number of simultaneous HTTP connections that can be handled. This number includes active web sockets.
If is a good idea to secure your management console, as it will also be used to manage private DKIM keys; by definition, these should be kept private and thus not transferered over interceptable non-secure HTTP connections.
The following configuration file variables are relevant for enabling HTTPS support:
www-secure-port: 443 (empty by default) www-certificate: /path/to/certificate.crt (empty by default) www-privatekey: /path/to/privatekey.key (empty by default) www-ciphers: !aNULL:!eNULL:!LOW:!SSLv2:!EXPORT:!EXPORT56:FIPS:MEDIUM:HIGH:@STRENGTH (empty by default)
If you enable both HTTP and HTTPS, users who access the non-secure interface
will automatically be forwarded to the secure interface. The
holds the port number for the HTTPS connections (443 is the default for
this, so that you won't have to include the port number in URLS). The
certifate and key files, and the supported ciphers can be set using
Once enabled, the encrypted management console can be accessed using
https://hostname.of.your.server if you use default port 443,
https://hostname.of.your.server:port for any other port.
If you have a cluster with multiple MailerQ instances, the web interface of these interfaces contains links to the other instances. MailerQ does its best to find out the URL for each of the other interfaces (by combining the host names and port numbers), but you can use the following optional config file variables to help a hand:
www-host: your.hostname (default: auto-detected) www-url: https://your.hostname:port (default: auto-detected)
The management console allows administrators to monitor live SMTP traffic. All incoming or outgoing connections can be intercepted, and the entire SMTP handshake (EHLO, MAIL FROM, RCPT TO, DATA) is real time visible via the management console. You can thus see he raw MIME message data that is being sent or received.
In fact, the management console even has an option to not only display the raw MIME data, but to extract the HTML source code too, and render this in your browser. With this tool you can exactly see what type of messages your users are sending, and you can take action if you see messages that look like spam, phishing or other types of abuse.
However, if you use the console to look at rendered emails, your browser automatically downloads images and other resources from the mail as well. This could trigger actions (like statistics updates) on the servers where these files are hosted. If you do not want this and you have control over these servers, you can take precautionary measures, for example by ignoring downloads that come from your IP address, or by ignoring downloads from clients with a specific user agent setting.
At Copernica we use this approach. Our devops have browsers with a special user agent setting (with Firefox you can change this using the "about:config" url), so that clicks and opens from us do not pollute mailing stats. In MailerQ's config file we have set the "render-useragent" value too, so that MailerQ refuses to share emails with browsers with a different user agent setting.
render-useragent: Copernica DevOps
The "render-useragent" setting ensures that only browsers with the specified user agent can render emails. If you have also updated your tracking servers to ignore clicks and opens from browsers with this user agent setting, you can make sure that you can safely look at rendered emails on the management console, without triggering any actions on your tracking servers.
This config file option was mainly added to MailerQ to help the MailerQ web developers: they make changes to the interface all the time, and they wanted to prevent that the testers were reviewing an outdated interface. But in production environments, this setting might be useful too.
Check out the documentation on mozilla.org for a list of supported options for this header.
We are excited to announce the latest version of MailerQ - version 5.5 - which includes improved insights into deliveries that are sch...
April has been a busy and exciting month for MailerQ. Last week we attended the CSA Summit in Cologne where we held a workshop on the ...