Version 4.2.6: Important fixes
MailerQ 4.2.6 has been released with a couple of important bug fixes, and some nice new features. We recommend to upgrade to this version. The database structure has not been altered, and the format of the JSON messages is also the same, so you will not have to modify your applications or scripts to deploy version 4.2.6.
New features
MailerQ can now be used to modify the headers of email messages. With the special "headers" property in the JSON, you can instruct MailerQ to remove, add or modify existing headers. An example and the JSON specification has been added to the documentation.
We've added a command line switch to MailerQ. If you start MailerQ with the "--notify-cluster" command line switch, MailerQ will send an instruction to each running instance that it should reload its configuration from the database. This feature is useful if you have manually modified the database, and want to instruct all instances that they should reload their settings.
The "--purge-database" command line switch has been improved. You can use this switch without having to start up MailerQ as a daemon process. If you now run "mailerq --purge-database" it will just purge the database, and will not start up the full MTA process.
Bug fixes
A nasty bug has slipped into version 4.2.5. Some delivery errors (like timeouts or lost TCP connections) both caused a mail to be sent back to the outbox queue for later delivery, as well as an immediate delivery to a fallback IP address. This could lead to double mail delivery. This problem has been fixed in MailerQ 4.2.6.
The "smtp-defaultip" config file variable was not correctly used if it was not explicitly set. If the config file variable was not set, MailerQ did not ignore the setting (as it should have done), but treated it as if it was set to the value "0.0.0.0", which could lead to undeliverable messages.
Other bug fixes include a problem with decompressing messages that were loaded from temporary queues, and handling fatal DNS lookups (when a domain does not exist). Such fatal DNS lookups were treated identical to temporary DNS failures (when a DNS server is temporarily offline). This was not right and has been fixed. The attempts number for errors was also not always correctly incremented when a delivery failed.
