Haraka 3.1.4 → 3.1.6

package/docs/plugins/aliases.md

@@ -1,143 +1,3 @@
 # aliases
 
-This plugin allows one to configure aliases that may perform an action or
-change the RCPT address in a number of ways. All aliases are specified in
-a JSON formatted configuration file, and must have at very least an action.
-Any syntax error found in the JSON format config file will stop the server
-from running.
-
-IMPORTANT: this plugin must appear in `config/plugins` before other plugins
-that run on hook_rcpt
-
-WARNING: DO NOT USE THIS PLUGIN WITH queue/smtp_proxy.
-
-## Configuration
-
-- aliases
-
-  JSON formatted configuration file that must contain, at very least, a key
-  to match against RCPT address, and a value that is an associative array
-  with an "action" : "<action>" key, value pair. An example:
-
-        { "test1" : { "action" : "drop" } }
-
-  In the above example the "test1" alias will drop any message that matches
-  test1, or test1-_ or test1+_ (wildcard '-' or '+', see below). Actions
-  may in turn have 0 or more options listed with them like so:
-
-        { "test3" : { "action" : "alias", "to" : "test3-works" } }
-
-  In the above example the "test3" alias has an action of "alias", and
-  a required "to" field. If this "to" field were missing the alias would
-  fail to run, and an error would be printed in the logs.
-
-  Now aliases of 'user', '@host' and 'user@host' possible:
-
-        { "demo" : { "action" : "drop" } }
-        or
-        { "@example.com" : { "action" : "drop" } }
-        or
-        { "demo@example.com" : { "action" : "drop" } }
-
-  Aliases may also be exploded to multiple recipients:
-
-        { "sales@example.com": { "action: "alias", "to": ["alice@example.com", "bob@example.com"] } }
-
-  - wildcard notation
-
-    In an effort to match some of the functionality of other alias parsers
-    we've allowed wildcard matching of the alias against the right most
-    string of a RCPT address. The characters '-' and '+' are commonly used
-    for subaddressing and this plugin has built-in support to alias the
-    "user" part of the email address.
-
-    That is, if our address were test2-testing@example.com (or
-    test2+testing@example.com), the below alias would match:
-
-          { "test2" : { "action" : "drop" } }
-
-    The larger, and more specific alias, should always match first when
-    using wildcard '-' notation. So if the above RCPT were put up against
-    this alias config, it would not drop, but rather map to another
-    address:
-
-          {
-              "test2" : { "action" : "drop" },
-              "test2-testing" : { "action" : "alias", "to" : "test@foo.com" }
-          }
-
-  - chaining and circuits
-
-    In short, we do not allow chaining of aliases at this time. As a
-    side-effect, we enjoy protections against alias circuits.
-
-  - optional one line formatting
-
-    Any valid JSON will due, however, please consider keeping each alias
-    on its own line so that others that wish to grep the aliases file
-    have an easier time finding the full configuration for an alias.
-
-  - nondeterministic duplicate matches
-
-    This plugin was written with speed in mind. That means every lookup
-    hashes into the alias file for its match. While the act of doing so
-    is fast, it does mean that any duplicate alias entries will match
-    nondeterministically. That is, we cannot predict what will happen
-    here:
-
-          {
-              "coinflip" : { "action" : "alias", "to" : "heads@coin.com" },
-              "coinflip" : { "action" : "alias", "to" : "tails@coin.com" }
-          }
-
-    Truth be told, one result will likely always be chosen over the other,
-    so this is not exactly a coinflip. We simply cannot say what the
-    language implementation will do here, it could change tomorrow.
-
-- action (required)
-
-  The following is a list of supported actions, and the options they require.
-  - drop
-
-    This action simply drops a message, while pretending everything was
-    okay to the sender. This acts much like an alias to /dev/null in
-    other servers.
-
-  - alias
-
-    This action will map the alias key to the address specified in the
-    "to" option. A note about matching in addition to the note
-    about wildcard '-' above. When we match an alias, we store the
-    hostname of the match for a shortcut substitution syntax later.
-    - to (required)
-
-      This option is the full address, or local part at matched hostname
-      that the RCPT address will be re-written to. For an example of
-      an alias to a full address consider the following:
-
-            { "test5" : { "action" : "alias", "to" : "test5@foo.com" } }
-
-      This will map RCPT matches for "test5" to "test5-works@foo.com".
-      This would map "test5@somedomain.com" to "test5-works@foo.com"
-      every time. Now compare this notation with its shortcut
-      counterpart, best used when the "to" address is at the same
-      domain as the match:
-
-            { "test4" : { "action" : "alias", "to" : "test4" } }
-
-      Clearly, this notation is more compact, but what does it do. Well,
-      mail to "test4-foo@anydomain.com" will map to "test4@anydomain.com".
-      One can see the clear benefit of using this notation with lots of
-      aliases on a single domain that map to other local parts at the
-      same domain.
-
-### Example Configuration
-
-{
-"test1" : { "action" : "drop" },
-"test2" : { "action" : "drop" },
-"test3" : { "action" : "alias", "to" : "test3-works" },
-"test4" : { "action" : "alias", "to" : "test4" },
-"test5" : { "action" : "alias", "to" : "test5-works@success.com" },
-"test6" : { "action" : "alias", "to" : "test6-works@success.com" }
-}
+Repackaged as [haraka-plugin-aliases](https://github.com/haraka/haraka-plugin-aliases).

package/docs/plugins/auth/auth_ldap.md

@@ -1,41 +1,4 @@
 # auth/auth_ldap
 
-The `auth/auth_ldap` plugin uses an LDAP bind to authenticate a user. Currently
-only one server and multiple DNs can be configured. If any of the DN binds succeed,
-the user is authenticated.
-
-## Configuration
-
-Configuration is stored in `config/auth_ldap.ini` and uses the INI
-style formatting.
-
-Only the `LOGIN` authentication method is supported assuming that passwords in the
-LDAP database are not stored in cleartext (which would allow for CRAM-MD5). Note
-that this means passwords will be sent in the clear to the LDAP server unless
-an `ldaps://` conection is used.
-
-Current configuration options in `[core]` are:
-
-    server - the url of the LDAP server (ldap:// or ldaps://)
-    timeout - time in miliseconds to wait for the server resonse before giving up
-    rejectUnauthorized - boolean (true or false) as to whether to reject connections
-        not verified against a CA. Meaning, a "false" allows non-verified.
-
-Example:
-
-    [core]
-    server=ldaps://ldap.opoet.com
-    timeout=5000
-    rejectUnauthorized=false
-
-The `[dns]` section (that is plural DN and not domain name system), is a list of DNs to use
-to bind. The `%u` in the strings is substituted with the user name used in the SMTP
-authentication. Note that the keys have no meaning and the DNs are tried in series until
-the first successful bind. The LDAP RFC does not allow for parallel binds on a connection,
-so it is suggested that the most commonly used DN be placed earlier in the list.
-
-Example:
-
-    [dns]
-    dn1=uid=%u,ou=Users,dc=opoet,dc=com
-    dn2=uid=%u,ou=people,dc=opoet,dc=com
+Repackaged as [haraka-plugin-auth-ldap](https://github.com/haraka/haraka-plugin-auth-ldap).
+Loading `auth/auth_ldap` in `config/plugins` is auto-redirected to `auth-ldap`.

package/docs/plugins/max_unrecognized_commands.md

@@ -1,20 +1,6 @@
 # max_unrecognized_commands
 
-This plugin places a maximum limit on the number of unrecognized commands
-allowed before recognising that the connection is bad.
-
-If the limit is reached the connecting client is sent an error message and
-immediately (and rudely - technically an RFC violation) disconnected.
-
-**IMPORTANT**:
-This plugin should be listed near the bottom of `config/plugins` so that it
-runs after any plugins that use the unrecognized_command hook to implement
-other SMTP verbs and extensions (such as the auth/\* plugins), otherwise
-commands valid for these plugins will be counted as unknown by this plugin.
-
-## Configuration
-
-- max_unrecognized_commands
-
-  Specifies the number of unrecognized commands to allow before disconnecting.
-  Default: 10.
+The functionality of this plugin was folded into
+[haraka-plugin-limit](https://github.com/haraka/haraka-plugin-limit).
+Loading `max_unrecognized_commands` in `config/plugins` is auto-redirected
+to `limit`.

package/docs/plugins/process_title.md

@@ -37,6 +37,6 @@ across all workers, with the exception of outbound stats.
 All of the counts shown are since the process started, so if a
 worker has been re-started then the counts may not add up.
 
-Note: this plugin will only work on node >= 0.8 and should be
-added at the top of config/plugins to ensure that it functions
-correctly.
+Note: this plugin should be added at the top of `config/plugins` so
+that its `connect_init`, `rcpt`, `data`, and `disconnect` hooks run
+before any plugin that might short-circuit those hooks.

package/docs/plugins/reseed_rng.md

@@ -1,18 +1,16 @@
 # reseed_rng
 
-The V8 that ships with node 0.4.x uses an unsophisticated method of
-seeding its random number generator- it simply uses the current time
-in ms. Worse, that version of V8 (at least) doesn't provide a way
-to explicitly reseed the RNG.
+Reseeds `Math.random()` in each cluster worker at start-up using
+`crypto.randomBytes(256)`. Without this, workers forked at nearly the
+same time can end up with correlated PRNG state, which can produce
+UUID collisions and other "this should be impossible" bugs.
 
-In situations where multiple processes can spawn in the same
-ms, processes can be seeded with the same value, leading to bad
-problems like UUID collisions. When using the 'cluster' module, it's
-quite easy to observe this behavior.
+The plugin relies on [seedrandom](https://www.npmjs.com/package/seedrandom)
+being loaded so that `Math.seedrandom()` is available.
 
-This plugin uses David Bao's reseed.js (see http://davidbau.com/archives/2010/01/30/random_seeds_coded_hints_and_quintillions.html)
-to provide a reseedable Math.random(), and hooks the init_child event
-to reseed the RNG with a sligtly better seed at spawned-process startup
-time.
+Anyone running with `nodes=...` in `smtp.ini` (i.e. cluster mode) should
+consider enabling this plugin.
 
-All users of the 'cluster' module should consider using this plugin.
+## Configuration
+
+No configuration.

package/docs/plugins/tls.md

@@ -155,9 +155,9 @@ Specifies minimum allowable TLS protocol version to use. Example:
 
      minVersion=TLSv1.1
 
-If unset, the default is node's tls.DEFAULT_MIN_VERSION constant.
-
-(**Node.js 11.4+ required**, for older instances you can use _secureProtocol_ settings)
+If unset, the default is Node's `tls.DEFAULT_MIN_VERSION` constant
+(currently `'TLSv1.2'`). Valid values: `'TLSv1.3'`, `'TLSv1.2'`,
+`'TLSv1.1'`, `'TLSv1'`.
 
 ### honorCipherOrder
 
@@ -195,10 +195,10 @@ requireAuthorized[]=465
 
 ### secureProtocol
 
-Specifies the OpenSSL API function used for handling the TLS session. Choose
-one of the methods described at the
-[OpenSSL API page](https://www.openssl.org/docs/manmaster/ssl/ssl.html).
-The default is `SSLv23_method`.
+Legacy. Specifies the OpenSSL API function used to negotiate TLS — see
+the [OpenSSL API page](https://www.openssl.org/docs/manmaster/ssl/ssl.html).
+Prefer `minVersion` for modern setups; `secureProtocol` is only useful
+to lock to a specific historic protocol.
 
 ### requestOCSP
 

package/docs/plugins/toobusy.md

@@ -5,11 +5,17 @@ latency is too high.
 
 See https://github.com/STRML/node-toobusy for details.
 
-To use this plugin you have to install the 'toobusy-js' module by running
-'npm install toobusy-js' in your Haraka configuration directory.
+To use this plugin you must install the [`toobusy-js`](https://www.npmjs.com/package/toobusy-js)
+module — it is not bundled with Haraka. From your Haraka install
+directory:
 
-This plugin should be listed at the top of your config/plugins file so that
-it runs before any other plugin that hooks lookup_rdns.
+```sh
+npm install toobusy-js
+```
+
+This plugin registers on the `connect` hook with priority `-100`, so it
+runs ahead of other `connect`/`lookup_rdns` plugins. Listing it near the
+top of `config/plugins` is still a good idea for clarity.
 
 ## Configuration
 

package/docs/tutorials/SettingUpOutbound.md

@@ -1,70 +1,62 @@
 # Configuring Haraka For Outbound Email
 
-It is trivially easy to configure Haraka as an outbound email server. But
-first there are external things you may want to sort out:
+It is straightforward to run Haraka as an outbound (submission) mail server. Before turning on the server itself, get a few external things in order:
 
-- Get your DNS PTR record working - make sure it matches the A record of the
-  host you are sending from.
-- Consider implementing an SPF record. I don't personally do this, but some
-  people seem to think it helps.
+- **DNS PTR record** — make sure it matches the A/AAAA record of the host you are sending from. Receivers that disagree on `HELO`/PTR will treat your mail with suspicion.
+- **SPF, DKIM, and DMARC** — publish records for any domain you send from. Most receivers downgrade or reject mail without them. Haraka signs outbound with [haraka-plugin-dkim](https://github.com/haraka/haraka-plugin-dkim).
+- **Reverse DNS at the IP owner** — if your hosting provider controls the PTR, set the value through their console.
 
-There's lots of information elsewhere on the internet about getting these
-things working, and they are specific to your network and your DNS hosting.
+How to provision DNS varies by provider; the records are network-specific so no one-size-fits-all command applies.
 
-## First Some Background
+## Background
 
-Sending outbound mail through Haraka is called "relaying", and that is the
-term the internals use. The process is simple - if a plugin in Haraka tells
-the internals that this mail is to be relayed, then it gets queued in the
-"queue" directory for delivery. Then it will go through several delivery
-attempts until it is either successful or fails hard for some reason. A
-hard failure will result in a bounce email being sent to the "MAIL FROM"
-address used when connecting to Haraka. If that address also bounces then
-it is considered a "double bounce" and Haraka will log an error and drop it
-on the floor.
+Haraka treats outbound mail as "relaying". When any plugin sets `connection.relaying = true`, the message is queued for outbound delivery once `DATA` ends. The outbound engine then tries each MX in sequence; on permanent failure a DSN is generated and sent to the `MAIL FROM` address. If the DSN itself bounces, Haraka logs the "double bounce" and drops it.
 
-## The Setup
+## Setup
 
-Outbound mail servers should run on port 587 and enforce authentication. This
-is slightly different from the "old" model where there would simply be a
-check based on the connecting IP address to see if it was valid to relay.
-Note however that Haraka doesn't stop you doing it this way - we just don't
-provide a plugin to do that by default - you will have to write one. The
-reason is purely based on security and personal preference.
+Modern submission uses **implicit TLS on port 465** (RFC 8314); port 587 with `STARTTLS` is also still common. Plain port 25 is for server-to-server traffic and should not be used for submission.
 
-Let's create a new Haraka instance:
+Create a new Haraka instance:
 
-    haraka -i haraka-outbound
-    cd haraka-outbound
+```sh
+haraka -i haraka-outbound
+cd haraka-outbound
+```
 
-Now edit config/smtp.ini - change the port to 587.
+In `config/smtp.ini`, set the listener:
 
-Next we setup our plugins - all we need is the tls and auth plugin. AUTH capability is only advertised after TLS/SSL negotiation (except for connections from the local host):
+```ini
+listen=[::0]:465,[::0]:587
+smtps_port=465
+```
 
-    echo "tls
-    auth/flat_file" > config/plugins
+Anything in `smtps_port` runs implicit TLS; the other ports advertise `STARTTLS`.
 
-Now edit the flat file password file, and put in an appropriate username
-and password:
+Enable just the TLS and auth plugins. AUTH is only advertised after TLS is established (except for connections from localhost):
 
-    vi config/auth_flat_file.ini
+```sh
+cat > config/plugins <<'EOF'
+tls
+auth/flat_file
+EOF
+```
 
-See the documentation in docs/plugins/auth/flat_file.md for information about
-what can go in that file.
+Add a user to `config/auth_flat_file.ini`. See [`docs/plugins/auth/flat_file.md`](../plugins/auth/flat_file.md) for the format.
 
-Now you can start Haraka. That's all the configuration you need.
+Start Haraka:
 
-    haraka -c .
+```sh
+haraka -c .
+```
 
-Now in another window you can run swaks to test this - be sure to substitute
-an email address you can monitor in place of youremail@yourdomain.com, and the
-username and password you added for the --auth-user and --auth-password params:
+In another shell, test with [swaks](https://www.jetmore.org/john/code/swaks/) — substitute your real test address and the credentials you configured:
 
-    swaks --to youremail@yourdomain.com --from test@example.com --server localhost \
-      --port 587 --auth-user testuser --auth-password testpassword
+```sh
+swaks --to youremail@yourdomain.com --from test@example.com \
+    --server localhost --port 587 --tls \
+    --auth-user testuser --auth-password testpassword
+```
 
-Watch the output of swaks and ensure no errors have occurred. Then watch
-the recipient email address (easiest to make this your webmail account) and
-see that the email arrived.
+For port 465 (implicit TLS), use `--tls-on-connect` instead of `--tls`.
 
-You are done!
+Watch the swaks output for errors and confirm the message arrives. That's all the basic configuration you need; once you're satisfied, turn on DKIM signing for the domains you send from.

package/endpoint.js

@@ -2,12 +2,42 @@
 // Socket address parser/formatter and server binding helper
 
 const fs = require('node:fs/promises')
-const sockaddr = require('sockaddr')
+const net = require('node:net')
+
+function parseSockaddr(addr, defaultPort = 0) {
+    let match
+    if (/^[0-9]+$/.test(addr)) return { host: '::', port: parseInt(addr, 10) }
+
+    const lastColon = addr.lastIndexOf(':')
+    if (lastColon !== -1) {
+        const host = addr.slice(0, lastColon)
+        const port = addr.slice(lastColon + 1)
+
+        if (host.includes(':') && /^\d+$/.test(port) && net.isIP(host) === 6) {
+            return { host: host.toLowerCase(), port: parseInt(port, 10) }
+        }
+    }
+    if (net.isIP(addr) === 6) return { host: addr.toLowerCase(), port: defaultPort }
+
+    if ((match = /^(\d{1,3}(?:\.\d{1,3}){3})(?::(\d+))?$/.exec(addr)))
+        return { host: match[1], port: match[2] !== undefined ? parseInt(match[2], 10) : defaultPort }
+    if ((match = /^\[([0-9a-fA-F:]+)\](?::(\d+))?$/.exec(addr)))
+        return { host: match[1].toLowerCase(), port: match[2] !== undefined ? parseInt(match[2], 10) : defaultPort }
+    if (
+        (match =
+            /^([a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?)*)(?::(\d+))?$/.exec(
+                addr,
+            ))
+    )
+        return { host: match[1].toLowerCase(), port: match[2] !== undefined ? parseInt(match[2], 10) : defaultPort }
+    if (addr.includes('/')) return { path: addr }
+    throw new Error(`Invalid socket address ${addr}`)
+}
 
 module.exports = function endpoint(addr, defaultPort) {
     try {
         if ('string' === typeof addr || 'number' === typeof addr) {
-            addr = sockaddr(addr, { defaultPort })
+            addr = parseSockaddr(addr, defaultPort)
             const match = /^(.*):([0-7]{3})$/.exec(addr.path || '')
             if (match) {
                 addr.path = match[1]

package/outbound/hmail.js

@@ -87,9 +87,10 @@ class HMailItem extends events.EventEmitter {
             this.file_size = stats.size
             this.read_todo()
         } catch (err) {
-            // we are fucked... guess I need somewhere for this to go
+            // The file is unreadable (deleted, permissions, I/O error) and this.todo
+            // is still null, so there is no sender to bounce to. Release the queue slot.
             this.logerror(`Error obtaining file size: ${err}`)
-            this.temp_fail('Error obtaining file size')
+            this.next_cb()
         }
     }
 

package/outbound/index.js

@@ -248,6 +248,9 @@ exports.send_trans_email = function (transaction, next) {
 
         let todo_index = 1
 
+        // See haraka/Haraka#3551
+        await new Promise((resolve) => setImmediate(resolve))
+
         try {
             for (const deliv of deliveries) {
                 const todo = new TODOItem(deliv.domain, deliv.rcpts, transaction)

package/package.json

@@ -9,7 +9,7 @@
     "server",
     "email"
   ],
-  "version": "3.1.4",
+  "version": "3.1.6",
   "homepage": "http://haraka.github.io",
   "repository": {
     "type": "git",
@@ -20,71 +20,58 @@
     "node": ">=20"
   },
   "dependencies": {
-    "address-rfc2821": "^2.1.5",
+    "address-rfc2821": "^2.2.0",
     "address-rfc2822": "^2.2.3",
-    "daemon": "~1.1.0",
     "haraka-config": "^1.5.0",
     "haraka-constants": "^1.0.7",
     "haraka-dsn": "^1.1.0",
-    "haraka-email-message": "^1.3.1",
-    "haraka-message-stream": "^2.0.0",
-    "haraka-net-utils": "^1.7.2",
+    "haraka-email-message": "^1.3.3",
+    "haraka-net-utils": "^1.8.2",
     "haraka-notes": "^1.1.1",
     "haraka-plugin-redis": "^2.0.11",
     "haraka-results": "^2.3.0",
-    "haraka-tld": "^1.3.1",
+    "haraka-tld": "^1.3.4",
     "haraka-utils": "^1.1.4",
-    "ipaddr.js": "~2.3.0",
-    "node-gyp": "^12.2.0",
+    "ipaddr.js": "~2.4.0",
+    "node-gyp": "^12.3.0",
     "nopt": "^9.0.0",
-    "npid": "~0.4.0",
-    "redis": "~5.11.0",
-    "semver": "^7.7.4",
-    "sockaddr": "^1.0.1",
-    "sprintf-js": "~1.1.3"
+    "redis": "~5.12.1",
+    "semver": "^7.8.0"
   },
   "optionalDependencies": {
-    "haraka-plugin-access": "^1.1.10",
+    "@haraka/ocsp": "^1.2.0",
+    "haraka-plugin-access": "^1.2.0",
     "haraka-plugin-aliases": "^1.0.3",
     "haraka-plugin-asn": "^2.0.6",
     "haraka-plugin-attachment": "^1.2.0",
-    "haraka-plugin-avg": "^1.1.0",
     "haraka-plugin-bounce": "^2.1.2",
     "haraka-plugin-clamd": "^1.0.2",
     "haraka-plugin-dcc": "^1.0.3",
-    "haraka-plugin-dkim": "^1.0.11",
+    "haraka-plugin-dkim": "^1.1.2",
     "haraka-plugin-dns-list": "^1.2.4",
     "haraka-plugin-early_talker": "^1.0.2",
-    "haraka-plugin-elasticsearch": "^8.1.6",
-    "haraka-plugin-esets": "^1.0.1",
     "haraka-plugin-fcrdns": "^1.1.2",
     "haraka-plugin-geoip": "^1.1.2",
-    "haraka-plugin-greylist": "^1.1.0",
+    "haraka-plugin-greylist": "^1.1.1",
     "haraka-plugin-headers": "^1.1.0",
     "haraka-plugin-helo.checks": "^1.1.0",
-    "haraka-plugin-karma": "^2.1.8",
+    "haraka-plugin-karma": "^2.4.1",
     "haraka-plugin-known-senders": "^1.1.3",
     "haraka-plugin-limit": "^1.2.7",
-    "haraka-plugin-mail_from.is_resolvable": "^1.1.0",
+    "haraka-plugin-mail_from.is_resolvable": "^1.2.0",
     "haraka-plugin-messagesniffer": "^1.0.1",
-    "haraka-plugin-p0f": "^1.0.11",
-    "haraka-plugin-qmail-deliverable": "^1.3.2",
-    "haraka-plugin-recipient-routes": "^1.3.1",
+    "haraka-plugin-qmail-deliverable": "^1.3.5",
     "haraka-plugin-relay": "^1.0.1",
-    "haraka-plugin-rspamd": "^1.4.2",
-    "haraka-plugin-spamassassin": "^1.0.3",
+    "haraka-plugin-rspamd": "^1.5.0",
+    "haraka-plugin-spamassassin": "^1.0.4",
     "haraka-plugin-spf": "^1.2.11",
     "haraka-plugin-syslog": "^1.0.7",
-    "haraka-plugin-uribl": "^1.0.10",
-    "haraka-plugin-watch": "^2.0.9",
-    "@techteamer/ocsp": "^1.0.1"
+    "haraka-plugin-uribl": "^1.0.10"
   },
   "devDependencies": {
     "@haraka/eslint-config": "^2.0.4",
-    "haraka-test-fixtures": "^1.4.1",
-    "mocha": "^11.7.5",
-    "mock-require": "^3.0.3",
-    "nodemailer": "^8.0.4"
+    "haraka-test-fixtures": "^1.4.3",
+    "mock-require": "^3.0.3"
   },
   "bugs": {
     "mail": "haraka.mail@gmail.com",

package/plugins/queue/smtp_forward.js

@@ -247,7 +247,7 @@ exports.queue_forward = function (next, connection) {
         )
 
         function get_rs() {
-            return connection?.transaction?.results ? connection.transaction.results : connection.results
+            return txn?.results ?? connection.results
         }
 
         function dead_sender() {
@@ -320,10 +320,10 @@ exports.get_mx_next_hop = (next_hop) => {
         exchange: dest.hostname,
     }
     if (dest.protocol === 'lmtp:') mx.using_lmtp = true
-    if (dest.auth) {
+    if (dest.username) {
         mx.auth_type = 'plain'
-        mx.auth_user = dest.auth.split(':')[0]
-        mx.auth_pass = dest.auth.split(':')[1]
+        mx.auth_user = dest.username
+        mx.auth_pass = dest.password
     }
     return mx
 }

package/run_tests

@@ -1,23 +1,11 @@
 #!/bin/sh
 
 # Files using node:test
-NODE_TEST_FILES="test/transaction.js test/connection.js test/outbound/*.js"
-
-# Mocha scans test/ but skips transaction.js, connection.js, and outbound/
-MOCHA_IGNORE="--ignore=test/transaction.js --ignore=test/connection.js"
-MOCHA_TESTS="test test/plugins/auth test/plugins/queue test/plugins"
+NODE_TEST_FILES="test/*.js test/outbound/*.js test/plugins/*.js test/plugins/auth/*.js test/plugins/queue/*.js"
 
 if [ -n "$1" ]; then
-    case "$1" in
-        test/transaction.js | test/connection.js | test/outbound/*)
-            node --test "$1"
-            ;;
-        *)
-            npx mocha --exit --timeout=4000 "$1"
-            ;;
-    esac
+    node --test "$1"
 else
     # default, run 'em all
-    node --test --test-concurrency=1 $NODE_TEST_FILES && \
-    npx mocha --exit --timeout=4000 $MOCHA_IGNORE $MOCHA_TESTS
+    node --test --test-concurrency=1 $NODE_TEST_FILES
 fi