MailerQ 4.1 has been released
We're happy to announce version 4.1 of MailerQ. This new version features a couple of bug fixes, as well as a couple of interesting new features.
More STARTTLS configuration options and security feedback
Security has never been a very important aspect of mail delivery. Traditionally, e-mail transport was not even secured and up to this day most senders and receivers are just as happy to send or receive an email over an unencrypted connection as over a secure connection. However, demand for security is growing, and we've therefore added a couple of interesting features to MailerQ.
For a start, you can now better control whether you want to deliver mail over secure connections or not. MailerQ 4.1 not only allows you to specify whether you want to use STARTTLS or not (this was already possible) - but you can now also control whether you want MailerQ to verify that the certificate of the receiver was indeed valid (and not self-signed).
For each domain, you can set four different security levels:
- Do not use STARTTLS, always send unencrypted mail (this is the fastest option)
- Use STARTTLS if available, otherwise send unencrypted (opportunistic TLS)
- STARTTLS is required, do not send the mail if STARTTLS is not available (but do allow self-signed certificates)
- STARTTLS is required, and the server's certificate must be valid and match the target's hostname
Besides the extra security settings, MailerQ now also includes the certificate details in the JSON data that is published back to the result queues. This allows you to check in your processing scripts whether the mail was delivered over a secure connection, and how secure that connection exactly was.
Changes to capacity settings
MailerQ now supports cascading capacity settings. This means that if you set a domain-specific or mta-specific capacity, that you no longer have to copy all the default settings to this specific capacity as well. It now is possible to set a capacity to "max 2 simultaneous connections to 'example.com', all the other settings for 'example.com' are the same as the default settings".
Reduced capacity settings (the capacity settings that come into effect when a flood-pattern matches, for example because you're sending too fast), are now only used as a reduced capacity. If the reduced setting turns out to be higher than the original capacity setting, MailerQ will keep on using the old (slower) setting instead.
Default outgoing IP
If you inject mail using SMTP, MailerQ normally sends out the mail from the same IP address. Thus, if you inject an email to IP address 188.8.131.52, MailerQ will also send out the mail from IP address 184.108.40.206. If you want to override this, you traditionally had to add an extra 'x-mq-ip' MIME header with the IP address to use instead.
However, MailerQ 4.1 now supports an extra optional config file variable to change this. With the 'smtp-defaultip' variable, you can instruct MailerQ to send out incoming emails from a fixed IP address instead of using the IP address that was used for injecting the messages.
We've been working hard on internationalization and UTF8 support for MailerQ. MailerQ 4.1 now recognizes international email addresses and domain names, and treats them in the right way. Addresses in JSON objects that are published to RabbitMQ are always UTF8 encoded.
However, although we do support international email, we recommend to stick with pure ascii email messages for the foreseeable future, and to use base64 or quoted-printable encoding to ensure that your messages only contain pure ascii code. In reality, there are still many servers and email programs out there that do not support non-ascii data, and if MailerQ (or any other MTA down the line) has to convert the UTF8 encoded message into an ASCII message, you seriously risk that DKIM signatures break.
MailerQ can now connect with a SpamAssassin daemon, and check whether incoming messages are spam or ham. The result of the this check is added to the JSON data that is published to the inbox queue.
Many other bug fixes and small improvements
Besides the changes mentioned above, we've fixed many other bugs and made many other small improvements to the code.