Haraka 3.0.2 → 3.0.4

package/docs/Transaction.md

@@ -1,19 +1,16 @@
-Transaction Object
-==================
+# Transaction Object
 
 An SMTP transaction is valid from MAIL FROM time until RSET or "final-dot".
 
-API
----
+## API
 
 * transaction.uuid
 
-A unique UUID for this transaction. Is equal to the connection.uuid + '.N'
-where N increments for each transaction on this connection.
+A unique UUID for this transaction. Is equal to the connection.uuid + '.N' where N increments for each transaction on this connection.
 
 * transaction.mail\_from
 
-The value of the MAIL FROM command as an `Address`[1] object.
+The value of the MAIL FROM command is an `Address`[1] object.
 
 * transaction.rcpt\_to
 
@@ -25,13 +22,13 @@ A node.js Readable Stream object for the message.
 
 You use it like this:
 
-    transaction.message_stream.pipe(WritableStream, options)
+```js
+transaction.message_stream.pipe(WritableStream, options)
+```
 
-Where WritableStream is a node.js Writable Stream object such as a
-net.socket, fs.writableStream, process.stdout/stderr or custom stream.
+Where WritableStream is a node.js Writable Stream object such as a net.socket, fs.writableStream, process.stdout/stderr or custom stream.
 
-The options argument should be an object that overrides the following
-properties:
+The options argument should be an object that overrides the following properties:
 
     * line_endings (default: "\r\n")
     * dot_stuffing (default: false)
@@ -42,7 +39,9 @@ properties:
 
 e.g.
 
-    transaction.message_stream.pipe(socket, { dot_stuffing: true, ending_dot: true });
+```js
+transaction.message_stream.pipe(socket, { dot_stuffing: true, ending_dot: true });
+```
 
 * transaction.data\_bytes
 
@@ -50,8 +49,7 @@ The number of bytes in the email after DATA.
 
 * transaction.add\_data(line)
 
-Adds a line of data to the email. Note this is RAW email - it isn't useful
-for adding banners to the email.
+Adds a line of data to the email. Note this is RAW email - it isn't useful for adding banners to the email.
 
 * transaction.notes
 
@@ -59,8 +57,7 @@ A safe place to store transaction specific values. See also [haraka-results](htt
 
 * transaction.add\_leading\_header(key, value)
 
-Adds a header to the top of the header list.  This should only be used in
-very specific cases.  Most people will want to use `add_header()` instead.
+Adds a header to the top of the header list.  This should only be used in very specific cases. Most cases will use `add_header()` instead.
 
 * transaction.add\_header(key, value)
 
@@ -76,8 +73,7 @@ The header of the email. See `Header Object`.
 
 * transaction.parse\_body = true|false [default: false]
 
-Set to `true` to enable parsing of the mail body. Make sure you set this in
-hook\_data or before.
+Set to `true` to enable parsing of the mail body. Make sure you set this in hook\_data or before. Storing a transaction hook (with transaction.attachment\_hooks) will set this to true.
 
 * transaction.body
 
@@ -85,81 +81,62 @@ The body of the email if you set `parse_body` above. See `Body Object`.
 
 * transaction.attachment\_hooks(start)
 
-Sets a callback for when we see an attachment if `parse_body` has been set.
-
-The `start` event will receive `(content_type, filename, body, stream)` as
-parameters.
-
-The stream is a `ReadableStream` - see http://nodejs.org/api/stream.html for
-details on how this works.
-
-If you set stream.connection then the stream will apply backpressure to the
-connection, allowing you to process attachments before the connection has
-ended. Here is an example which stores attachments in temporary files using
-the `tmp` library from npm and tells us the size of the file:
-
-    exports.hook_data = function (next, connection) {
-        // enable mail body parsing
-        connection.transaction.parse_body = true;
-        connection.transaction.attachment_hooks(
-            function (ct, fn, body, stream) {
-                start_att(connection, ct, fn, body, stream)
-            }
-        );
-        next();
-    }
-
-    function start_att (connection, ct, fn, body, stream) {
-        connection.loginfo("Got attachment: " + ct + ", " + fn + " for user id: " + connection.transaction.notes.hubdoc_user.email);
-        connection.transaction.notes.attachment_count++;
-
-        stream.connection = connection; // Allow backpressure
-        stream.pause();
-
-        var tmp = require('tmp');
-
-        tmp.file(function (err, path, fd) {
-            connection.loginfo("Got tempfile: " + path + " (" + fd + ")");
-            var ws = fs.createWriteStream(path);
-            stream.pipe(ws);
-            stream.resume();
-            ws.on('close', function () {
-                connection.loginfo("End of stream reached");
-                fs.fstat(fd, function (err, stats) {
-                    connection.loginfo("Got data of length: " + stats.size);
-                    // Close the tmp file descriptor
-                    fs.close(fd, function(){});
-                });
+Sets a callback for when we see an attachment.
+
+The `start` event will receive `(content_type, filename, body, stream)` as parameters.
+
+The stream is a [ReadableStream](http://nodejs.org/api/stream.html)
+
+If you set stream.connection then the stream will apply backpressure to the connection, allowing you to process attachments before the connection has ended. Here is an example which stores attachments in temporary files using the `tmp` library from npm and tells us the size of the file:
+
+```js
+exports.hook_data = function (next, connection) {
+    // enable mail body parsing
+    connection.transaction.attachment_hooks(
+        function (ct, fn, body, stream) {
+            start_att(connection, ct, fn, body, stream)
+        }
+    );
+    next();
+}
+
+function start_att (connection, ct, fn, body, stream) {
+    connection.loginfo(`Got attachment: ${ct}, ${fn} for user id: ${connection.transaction.notes.hubdoc_user.email}`)
+    connection.transaction.notes.attachment_count++
+
+    stream.connection = connection; // Allow backpressure
+    stream.pause();
+
+    require('tmp').file((err, path, fd) => {
+        connection.loginfo(`Got tempfile: ${path} (${fd})`)
+        const ws = fs.createWriteStream(path)
+        stream.pipe(ws);
+        stream.resume();
+        ws.on('close', () => {
+            connection.loginfo("End of stream reached");
+            fs.fstat(fd, (err, stats) => {
+                connection.loginfo(`Got data of length: ${stats.size}`);
+                fs.close(fd, () => {}); // Close the tmp file descriptor
             });
         });
-    }
+    });
+}
+```
 
 * transaction.discard\_data = true|false [default: false]
 
-Set this flag to true to discard all data as it arrives and not store in
-memory or on disk (in the message\_stream property). You can still access
-the attachments and body if you set parse\_body to true. This is useful
-for systems which do not need the full email, just the attachments or
-mail text.
+Set this flag to true to discard all data as it arrives and not store in memory or on disk (in the message\_stream property). You can still access the attachments and body if you set parse\_body to true. This is useful for systems which do not need the full email, just the attachments or mail text.
 
 * transaction.set\_banner(text, html)
 
-Sets a banner to be added to the end of the email. If the html part is not
-given (optional) then the text part will have each line ending replaced with
-`<br/>` when being inserted into HTML parts.
+Sets a banner to be added to the end of the email. If the html part is not given (optional) then the text part will have each line ending replaced with `<br/>` when being inserted into HTML parts.
 
 * transaction.add\_body\_filter(ct_match, filter)
 
-Adds a filter to be applied to body parts in the email.  ct\_match should be a
-regular expression to match against the full content-type line, or a string to
-match at the start, e.g. `/^text\/html/` or `'text/plain'`.  filter will be
-called when each body part matching ct_match is complete.  It receives three
-parameters, the content-type line, the encoding name, and a buffer with the
-full body part.  It should return a buffer with the desired contents of the
-body in the same encoding.
+Adds a filter to be applied to body parts in the email. ct\_match should be a regular expression to match against the full content-type line, or a string to match at the start, e.g. `/^text\/html/` or `'text/plain'`. filter will be called when each body part matching ct_match is complete.  It receives three parameters: the content-type line, the encoding name, and a buffer with the full body part. It should return a buffer with the desired contents of the body in the same encoding.
 
 * transaction.results
 
-Store results of processing in a structured format. See [docs/Results](http://haraka.github.io/manual/Results.html)
+Store [results](https://github.com/haraka/haraka-results) of processing in a structured format.
 
-[1]: `Address` objects are address-rfc2821 objects. See https://github.com/haraka/node-address-rfc2821
+[1]: `Address` objects are [address-rfc2821](https://github.com/haraka/node-address-rfc2821) objects.

package/docs/{plugins → deprecated}/connect.rdns_access.md

@@ -1,6 +1,6 @@
 ## DEPRECATION NOTICE
 
-See the [access](http://haraka.github.io/manual/plugins/access.html) plugin
+See [haraka-plugin-access](https://github.com/haraka/haraka-plugin-access)
 for upgrade instructions.
 
 

package/docs/{plugins → deprecated}/mail_from.access.md

@@ -1,6 +1,6 @@
 ## DEPRECATION NOTICE
 
-See the [access](http://haraka.github.io/manual/plugins/access.html) plugin
+See [haraka-plugin-access](https://github.com/haraka/haraka-plugin-access)
 for upgrade instructions.
 
 

package/docs/{plugins → deprecated}/rcpt_to.access.md

@@ -1,6 +1,6 @@
 ## DEPRECATION NOTICE
 
-See the [access](http://haraka.github.io/manual/plugins/access.html) plugin
+See [haraka-plugin-access](https://github.com/haraka/haraka-plugin-access)
 for upgrade instructions.
 
 

package/docs/plugins/auth/auth_vpopmaild.md

@@ -1,26 +1,20 @@
-auth/auth\_vpopmaild
-===============
+# auth/auth\_vpopmaild
 
-The `auth/vpopmaild` plugin allows you to authenticate against a vpopmaild
-daemon.
+The `auth/vpopmaild` plugin allows SMTP users to authenticate against a vpopmaild daemon.
 
 ## Configuration
 
-Configuration is stored in `config/auth_vpopmaild.ini` and uses INI
-style formatting.
+The configuration file is stored in `config/auth_vpopmaild.ini`.
 
-There are three configuration settings:
+### settings
 
 * host: The host/IP that vpopmaild is listening on (default: localhost).
 
 * port: The TCP port that vpopmaild is listening on (default: 89).
 
-* sysadmin: A colon separated username:password of a vpopmail user with
-    SYSADMIN privileges (see vpopmail/bin/vmoduser -S). This is **only**
-    necessary to support CRAM-MD5 which requires access to the clear text
-    password. On new installs, it's best not to use CRAM-MD5, as it requires
-    storing clear text passwords. Legacy clients with MUAs configured
-    to authenticate with CRAM-MD5 will need this enabled.
+* sysadmin: A colon separated username:password of a vpopmail user with SYSADMIN privileges (see vpopmail/bin/vmoduser -S). This is **only** necessary to support CRAM-MD5 which requires access to the clear text password. On new installs, it's best not to use CRAM-MD5, as it requires storing clear text passwords. Legacy clients with MUAs configured to authenticate with CRAM-MD5 will need this enabled.
+
+* constrain_sender: (default: true). For outbound messages (due to successful AUTH), constrain the envelope sender (MAIL FROM) to the same domain as the authenticated user. This setting, combined with `rate_rcpt_sender` in the [limit](https://github.com/haraka/haraka-plugin-limit) plugin can dramatically reduce the amount of backscatter and spam sent when an email account is compromised.
 
 
 ### Per-domain Configuration
@@ -29,10 +23,12 @@ Additionally, domains can each have their own configuration for connecting
 to vpopmaild. The defaults are the same, so only the differences needs to
 be declared. Example:
 
-    [example.com]
-    host=192.168.0.1
-    port=999
+```ini
+[example.com]
+host=192.168.0.1
+port=999
 
-    [example2.com]
-    host=192.168.0.2
-    sysadmin=postmaster@example2.com:sekret
+[example2.com]
+host=192.168.0.2
+sysadmin=postmaster@example2.com:sekret
+```

package/docs/plugins/auth/flat_file.md

@@ -1,47 +1,40 @@
-auth/flat\_file
-==============
+# auth/flat\_file
 
-The `auth/flat_file` plugin allows you to create a file containing username
-and password combinations, and have relaying users authenticate from that
-file.
+The `auth/flat_file` plugin allows you to create a file containing username and password combinations, and have relaying users authenticate from that file.
 
-Note that passwords are stored in clear-text, so this may not be a great idea
-for large scale systems. However the plugin would be a good start for someone
-looking to implement authentication using some other form of auth.
+Note that passwords are stored in clear-text, so this may not be a great idea for large scale systems. However the plugin would be a good start for someone looking to implement authentication using some other form of auth.
 
-**Security** - it is recommended to switch to [auth-encfile][url-authencflat]
-to protect your user credentials.
+**Security** - it is recommended to switch to [auth-encfile][url-authencflat] to protect your user credentials.
 
-**IMPORANT NOTE** - this plugin requires that STARTTLS be used via the tls plugin 
-before it will advertise AUTH capabilities by the EHLO command.  This is to 
-improve security out-of-the-box.   Localhost and any IP in RFC1918 ranges 
-are automatically exempt from this rule.
+**IMPORANT NOTE** - this plugin requires that STARTTLS be used via the tls plugin before it will advertise AUTH capabilities by the EHLO command.  Localhost and IPs in RFC1918 ranges 
+are exempt from this rule.
 
-Configuration
--------------
+## Configuration
 
-Configuration is stored in `config/auth_flat_file.ini` and uses the INI
-style formatting. 
+Configuration is stored in `config/auth_flat_file.ini`.
 
-Authentication methods are listed in the `[core]` section under `methods`
-parameter. Lists of authentification methods are comma separated. Currently
-supported methods are: `CRAM-MD5`, `PLAIN` and `LOGIN`. The `PLAIN` 
-and `LOGIN` methods are not secure. That is why TLS is required before AUTH is
-offered.
+* [core]methods
 
-Example:
+Authentication methods are listed in the `[core]methods` parameter. Authentification methods are comma separated. Currently supported methods are: `CRAM-MD5`, `PLAIN` and `LOGIN`. The `PLAIN` and `LOGIN` methods are insecure and require TLS to be enabled.
+
+* [core]constrain_sender: (default: true). For outbound messages (due to successful AUTH), constrain the envelope sender (MAIL FROM) to the same domain as the authenticated user. This setting, combined with `rate_rcpt_sender` in the [limit](https://github.com/haraka/haraka-plugin-limit) plugin can dramatically reduce the amount of backscatter and spam sent when an email account is compromised.
 
-    [core]
-    methods=PLAIN,LOGIN,CRAM-MD5
+Example:
 
+```ini
+[core]
+methods=PLAIN,LOGIN,CRAM-MD5
+constrain_sender=true
+```
 
 Users are stored in the `[users]` section.
 
 Example:
 
-    [users]
-    user1=password1
-    user@domain.com=password2
-
+```ini
+[users]
+user1=password1
+user@domain.com=password2
+```
 
 [url-authencflat]: https://github.com/AuspeXeu/haraka-plugin-auth-enc-file

package/docs/plugins/queue/rabbitmq_amqplib.md

@@ -36,5 +36,12 @@ Configuration
 		durable = true
 		autoDelete = false
 
+        ; Optional queue arguments
+		; More information about x-arguments can be found at https://www.rabbitmq.com/queues.html#optional-arguments
+        [queue_args]
+        x-dead-letter-exchange =
+        x-dead-letter-routing-key = emails_dlq
+        x-overflow = reject-publish
+        x-queue-type = quorum
     
  More information about RabbitMQ can be found at https://www.rabbitmq.com/

package/docs/plugins/queue/smtp_forward.md

@@ -100,4 +100,4 @@ enable\_outbound can be set or unset on a per-domain level to enable or disable
 
 # Split host forward routing
 
-When an incoming email transaction has multiple recipients with different forward routes,  recipients to subsequent forward routes are deferred. Example: an incoming email transaction has recipients user@example1.com, user@example2.com, and user@example3.com. The first two recipients will be accepted (they share the same forward destination) and the latter will be deferred. It will arrive in a future delivery attempt by the remote.
+When an incoming email transaction has multiple recipients with different forward routes, recipients to subsequent forward routes are deferred. Example: an incoming email transaction has recipients user@example1.com, user@example2.com, and user@example3.com. The first two recipients will be accepted (they share the same forward destination) and the latter will be deferred. It will arrive in a future delivery attempt by the remote.

package/docs/plugins/queue/smtp_proxy.md

@@ -1,16 +1,11 @@
 # queue/smtp\_proxy
 ================
 
-This plugin delivers to another mail server. This is a common setup when you
-want to have a mail server with a solid pedigree of outbound delivery to
-other hosts, and inbound delivery to users.
-
-In comparison to `queue/smtp_forward`, this plugin makes a connection at
-MAIL FROM time to the ongoing SMTP server. This can be a benefit in that
-you get any SMTP-time filtering that the ongoing server provides, in
-particular one important facility to some setups is recipient filtering.
-However be aware that other than connect and HELO-time filtering, you will
-have as many connections to your ongoing SMTP server as you have to Haraka.
+This plugin delivers to another mail server. This is a common setup when you want to have a mail server with a solid pedigree of outbound delivery to other hosts, and inbound delivery to users.
+
+In comparison to `queue/smtp_forward`, this plugin makes a connection at MAIL FROM time to the ongoing SMTP server. This can be a benefit in that you get any SMTP-time filtering that the ongoing server provides, in particular one important facility to some setups is recipient filtering.
+
+Be aware that other than connect and HELO-time filtering, you will have as many connections to your ongoing SMTP server as you have to Haraka.
 
 ## Configuration
 -------------

package/docs/plugins/relay.md

@@ -8,7 +8,7 @@ This **relay** plugin provides Haraka with options for managing relay permission
 
 ## Authentication
 
-One way to enable relaying is [authentication](http://haraka.github.io/manual.html) via the auth plugins. Successful authentication enables relaying during _that_ SMTP connection. To securely offer SMTP AUTH, the [tls](http://haraka.github.io/manual/plugins/tls.html) plugin and at least one auth plugin must be enabled and properly configured. When that requirement is met, the AUTH SMTP extension will be advertised to SMTP clients.
+One way to enable relaying is authentication via the [auth plugins](http://haraka.github.io/plugins). Successful authentication enables relaying during _that_ SMTP connection. To securely offer SMTP AUTH, the [tls](http://haraka.github.io/plugins/tls) plugin and at least one auth plugin must be enabled and properly configured. When that requirement is met, the AUTH SMTP extension will be advertised to SMTP clients.
 
     % nc mail.example.com 587
     220 mail.example.com ESMTP Haraka 2.4.0 ready
@@ -118,7 +118,7 @@ Example:
     [domains]
     test.com = { "action": "accept" }
 
-I think of *accept* as the equivalent of qmail's *rcpthosts*, or a misplaced Haraka `rcpt_to.*` plugin. The *accept* mechanism is another way to tell Haraka that a particular domain is one we accept mail for. The difference between this and the [rcpt_to.in_host_list](http://haraka.github.io/manual/plugins/rcpt_to.in_host_list.html) plugin is that this one also enables relaying.
+Think of *accept* as the equivalent of qmail's *rcpthosts*, or a misplaced Haraka `rcpt_to.*` plugin. The *accept* mechanism is another way to tell Haraka that a particular domain is one we accept mail for. The difference between this and the [rcpt_to.in_host_list](http://haraka.github.io/plugins/rcpt_to.in_host_list) plugin is that this one also enables relaying.
 
     * continue (mails are subject to further checks)
 

package/docs/plugins/tls.md

@@ -4,9 +4,11 @@ This plugin enables the use of TLS (via `STARTTLS`) in Haraka.
 
 For this plugin to work you must have SSL certificates installed correctly.
 
+Haraka has [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) support. When the remote MUA/MTA presents a servername during the TLS handshake and a TLS certificate with that Common Name matches, that certificate will be presented. If no match is found, the default certificate (see Certificate Files) is presented.
+
 ## Certificate Files
 
-Defaults are shown and can be overridden in `config/tls.ini`.
+Defaults settings are shown and can be overridden in `config/tls.ini`.
 
 ```ini
 key=tls_key.pem
@@ -16,20 +18,39 @@ dhparam=dhparams.pem
 
 ## Certificate Directory
 
-If the directory `config/tls` exists, each file within the directory is expected to be a PEM encoded TLS bundle. Generate the PEM bundles in The Usual Way[TM] by concatenating the key, certificate, and CA/chain certs in that order. Example:
+If the directory `config/tls` exists, files within the directory are PEM encoded TLS files in one of two formats: bundles or Wild Wild West.
+
+### Certificate bundles
+
+Generate PEM bundles in The Usual Way[TM] by concatenating the key, certificate, and CA/chain certs in that order. Example:
 
 ```sh
-cat example.com.key example.com.crt ca.crt > config/tls/example.com.pem
+cat example.com.key example.com.crt ca-int.crt > haraka/config/tls/example.com.pem
 ```
 
-An example [acme.sh](https://acme.sh) deployment [script](https://github.com/msimerson/Mail-Toaster-6/blob/master/provision/letsencrypt.sh) demonstrates how to install [Let's Encrypt](https://letsencrypt.org) certificates to the Haraka `config/tls`directory.
+An example [acme.sh](https://acme.sh) deployment [script](https://github.com/msimerson/Mail-Toaster-6/blob/master/provision/letsencrypt.sh) installs [Let's Encrypt](https://letsencrypt.org) certificate bundles to the Haraka `config/tls`directory.
+
+### Wild Wild West
+
+PEM encoded TLS certificates and keys can be stored in files in `config/tls`. The certificate loader is recursive, so TLS files can be in subdirs like `config/tls/mx1.example.com`. The certificate names are parsed from the 1st cert in each file and indexed by the certs Common Name(s). Subject Alternate Names are supported. The file name containing the certificates does *not* matter. Additional certificates within each file are presumed to be CA chain (intermediate) certificates.
+
+If the TLS key is stored in the same file as the matching certificate, then the name of the file does not matter. If the TLS key is alone in a file, the file MUST be named with the keys Common Name. The file extension does not matter, `.pem` and `.key` are common. If the key is used for multiple CNs, the key must be stored in a file name matching each CN. Examples of working TLS key/cert file pairs for the Common Name mx1.example.com:
 
-Haraka has [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) support. When the remote MUA/MTA presents a servername during the TLS handshake and a TLS certificate with that Common Name matches, that certificate will be presented. If no match is found, the default certificate (see Certificate Files above) is presented.
+1. certificate bundle (see above), key & cert in same file
+    - config/tls/mx1.example.com.pem (recommended)
+    - config/tls/any-unique-name.pem (CN is extracted from 1st cert)
+2. files in TLS dir
+    - config/tls/mx1.example.com.crt
+    - config/tls/mx1.example.com.key
+3. files in subdir
+    - config/tls/example.com/mx1.cert
+    - config/tls/example.com/mx1.example.com.key
+4. wildcard bundle on Windows platform (* is not allowed in file names)
+    - config/tls/_.example.com.pem
 
 ## Purchased Certificate
 
-If you have a purchased certificate, append any intermediate/chained/ca-cert
-files to the certificate in this order:
+For purchased certificate, append any intermediate/chained/ca-cert files to the certificate in this order:
 
 1. The CA signed SSL cert
 2. Any intermediate certificates
@@ -39,8 +60,7 @@ See also [Setting Up TLS](https://github.com/haraka/Haraka/wiki/Setting-up-TLS-w
 
 ## Self Issued (unsigned) Certificate
 
-Create a certificate and key file in the config directory with the following
-command:
+Create a certificate and key file in the config directory with the following command:
 
     openssl req -x509 -nodes -days 2190 -newkey rsa:2048 \
             -keyout config/tls_key.pem -out config/tls_cert.pem

package/endpoint.js

@@ -1,7 +1,7 @@
 'use strict';
 // Socket address parser/formatter and server binding helper
 
-const fs = require('fs');
+const fs = require('node:fs/promises');
 const sockaddr = require('sockaddr');
 
 module.exports = function endpoint (addr, defaultPort) {
@@ -46,21 +46,24 @@ class Endpoint {
     }
 
     // Make server listen on this endpoint, w/optional options
-    bind (server, opts) {
-        let done;
-        opts = Object.assign({}, opts || {});
+    async bind (server, opts) {
+        opts = {...opts};
+
+        const mode = this.mode ? parseInt(this.mode, 8) : false;
         if (this.path) {
-            const path = opts.path = this.path;
-            const mode = this.mode ? parseInt(this.mode, 8) : false;
-            if (mode) {
-                done = () => fs.chmodSync(path, mode);
-            }
-            if (fs.existsSync(path)) fs.unlinkSync(path);
-        }
-        else {
+            opts.path = this.path;
+            await fs.rm(this.path, { force: true }); // errors are ignored when force is true
+        } else {
             opts.host = this.host;
             opts.port = this.port;
         }
-        server.listen(opts, done);
+        
+        return new Promise((resolve, reject) => {
+            server.listen(opts, async (err) => {
+                if(err) return reject(err);
+                if (mode) await fs.chmod(opts.path, mode);
+                resolve()
+            });
+        });
     }
 }

package/haraka.js

@@ -20,20 +20,18 @@ catch (e) {
     require('module')._initPaths(); // Horrible hack
 }
 
-const fs = require('fs');
+const utils = require('haraka-utils');
 const logger = require('./logger');
 const server = require('./server');
 
-exports.version = JSON.parse(
-    fs.readFileSync(path.join(__dirname, './package.json'), 'utf8')
-).version;
+exports.version = utils.getVersion(__dirname)
 
 process.on('uncaughtException', err => {
     if (err.stack) {
-        err.stack.split("\n").forEach(line => logger.logcrit(line));
+        err.stack.split("\n").forEach(line => logger.crit(line));
     }
     else {
-        logger.logcrit(`Caught exception: ${JSON.stringify(err)}`);
+        logger.crit(`Caught exception: ${JSON.stringify(err)}`);
     }
     logger.dump_and_exit(1);
 });
@@ -41,18 +39,16 @@ process.on('uncaughtException', err => {
 let shutting_down = false;
 const signals = ['SIGINT'];
 
-if (process.pid === 1) {
-    signals.push('SIGTERM')
-}
+if (process.pid === 1) signals.push('SIGTERM')
 
-signals.forEach((sig) => {
+for (const sig of signals) {
     process.on(sig, () => {
         if (shutting_down) return process.exit(1);
         shutting_down = true;
         const [, filename] = process.argv;
         process.title = path.basename(filename, '.js');
 
-        logger.lognotice(`${sig} received`);
+        logger.notice(`${sig} received`);
         logger.dump_and_exit(() => {
             if (server.cluster?.isMaster) {
                 server.performShutdown();
@@ -62,10 +58,10 @@ signals.forEach((sig) => {
             }
         });
     });
-});
+}
 
 process.on('SIGHUP', () => {
-    logger.lognotice('Flushing the temp fail queue');
+    logger.notice('Flushing the temp fail queue');
     server.flushQueue();
 });
 
@@ -74,7 +70,7 @@ process.on('exit', code => {
     const [, filename] = process.argv;
     process.title = path.basename(filename, '.js');
 
-    logger.lognotice('Shutting down');
+    logger.notice('Shutting down');
     logger.dump_logs();
 });