Haraka crashes with FATAL state. SMTP service not reachable. users with incorrect password attempts

[dev-cb]

Outgoing mail via the Cloudron mail server is not working. SMTP connections on ports 587 / 465 are refused from outside, while IMAP works as expected.

After further investigation, the Cloudron mail service (Haraka) repeatedly crashes during startup and enters a FATAL state, which explains why no SMTP ports are exposed externally.

The issue seems to be caused by a runtime error in Haraka during outbound TLS handling:

TypeError: err.map is not a function

Once this happens, Haraka shuts down and Cloudron stops retrying after multiple failures.

As a result:
• No SMTP service is reachable externally
• Mail clients cannot send mail via Cloudron
• IMAP continues to work

This appears to be a bug or incompatibility between Haraka, Node.js, and/or TLS configuration.

Relevant Haraka logs:

Starting up Haraka version 3.1.1
[NOTICE] [server] Listening on [::0]:2525
[NOTICE] [server] Listening on [::0]:2465
[NOTICE] [server] Listening on [::0]:2587
[INFO] [cloudron] Initializing queue server on port 6000
[CRIT] [core] TypeError: err.map is not a function
[CRIT] [core] at /app/code/haraka/outbound/client_pool.js:40:21
[CRIT] [core] at /app/code/haraka/tls_socket.js:79:18
[NOTICE] [core] Shutting down
WARN exited: haraka (exit status 1; not expected)
INFO gave up: haraka entered FATAL state, too many start retries too quickly

Troubleshooting Already Performed

• Verified DNS (A / AAAA records correct)
• Confirmed IMAP (993) works
• Verified SMTP ports are refused externally
• Checked listening ports inside the container (Haraka binds briefly, then crashes)
• Restarted Cloudron mail service
• Checked TLS certificate validity
• Verified this is not a firewall or provider port-blocking issue
• Confirmed issue persists across restarts

System Info

Cloudron v9.0.15
Ubuntu 22.04.4 LTS Linux 5.15.0-164-generic
8 Core "AMD EPYC 9634 84-Core Processor"
16.76 GB RAM & 4.29 GB Swap

[necrevistonnezr]

What does cloudron-support --troubleshoot (in a terminal on the server) say, just to be sure?

[dev-cb]

@necrevistonnezr

# cloudron-support --troubleshoot
Vendor: netcup Product: KVM Server
Linux: 5.15.0-164-generic
Ubuntu: jammy 22.04
Execution environment: kvm
Processor: AMD EPYC 9634 84-Core Processor x 8
RAM: 16371028KB
Disk: /dev/sda3       270G
[OK]	node version is correct
[OK]	IPv6 is enabled and public IPv6 address is working
[OK]	docker is running
[OK]	docker version is correct
[OK]	MySQL is running
[OK]	nginx is running
[OK]	dashboard cert is valid
[OK]	dashboard is reachable via loopback
[OK]	No pending database migrations
[OK]	Service 'mysql' is running and healthy
[OK]	Service 'postgresql' is running and healthy
[OK]	Service 'mongodb' is running and healthy
[OK]	Service 'mail' is running and healthy
[OK]	Service 'graphite' is running and healthy
[OK]	Service 'sftp' is running and healthy
[OK]	box v9.0.15 is running
[OK]	netplan is good
[OK]	DNS is resolving via systemd-resolved
[OK]	Dashboard is reachable via domain name
[OK]	Domain monospace.design is valid and has not expired
[OK]	unbound is running

After more investigation I can most likely say, that the problem is rooted in a stuck outbound email which was sent to a mailbox on a domain which has a MX 10 record with value ".".

So Haraka wants to deliver outbound, resolver delivers MX ".", Haraka tries to establish a connection and fails. Node is returning an error as AggregateError.

Why does Haraka crash when doing this?
As soon as an outbound error comes in as an AggregateError without a useful err.message (or message is empty), the code runs into the AggregateError branch and crashes with: TypeError: err.map is not a function.

I am not deep enough in Node development but I assume that the relevant code snippet is located here:

/* /app/code/haraka/outbound/client_pool.js:37-42 */

const errMsg = err.message ?
  err.message :
  err instanceof AggregateError ?
    err.map(e => e.message).join(', ') :
    util.inspect(err, { depth: 3 });

I am going to check if this is still the case in Haraka 3.1.2 and if not Update Cloudron to 9.0.17 which also updates Haraka to the latest version. If not I’ll address this as an issue in the Haraka Github project.

[james]

Hello @dev-cb

We were just discussing your issue.
Could you enable remote support with cloudron-support --enable-remote-support and write a mail to support@cloudron.io with your domain?
We would like to investigate this issue in detail.
Since Cloudron is one of the top contributors for haraka we then would also fix this issue upstream for everyone.

[girish]

@dev-cb if you want to test that fix:

• In your Cloudron dashboard, open System->Services click the mail service ... icon to right and press Configure, click the checkbox Enable recovery mode and press Save
• Then, docker exec -ti mail /bin/bash. Haraka code is in /app/code/haraka. After you make the change, start with /app/code/start.sh

[dev-cb]

@girish Currently trying that. But, so far no luck in recovery mode either

...
[CRIT] [-] [core] TypeError: err.map is not a function
[CRIT] [-] [core]     at pluggableStream.<anonymous> (/app/code/haraka/outbound/client_pool.js:40:21)
[CRIT] [-] [core]     at Object.onceWrapper (node:events:633:26)
[CRIT] [-] [core]     at pluggableStream.emit (node:events:518:28)
[CRIT] [-] [core]     at Socket.<anonymous> (/app/code/haraka/tls_socket.js:79:18)
[CRIT] [-] [core]     at Object.onceWrapper (node:events:633:26)
[CRIT] [-] [core]     at Socket.emit (node:events:518:28)
[CRIT] [-] [core]     at emitErrorNT (node:internal/streams/destroy:170:8)
[CRIT] [-] [core]     at emitErrorCloseNT (node:internal/streams/destroy:129:3)
[CRIT] [-] [core]     at process.processTicksAndRejections (node:internal/process/task_queues:90:21)
[NOTICE] [-] [core] Shutting down
2026-01-23 08:58:44,438 WARN exited: haraka (exit status 1; not expected)
2026-01-23 08:58:45,439 INFO gave up: haraka entered FATAL state, too many start retries too quickly

so I switched recovery mode off.

[dev-cb]

In recovery mode, I could probably manipulate the queued email in /app/data/haraka-queue/ so that the To header is another domain which has a normal MX record and allows inbound mails.

Then restart. That could to the quick fix.

Or instead of manipulating, just delete the one.

[dev-cb]

said in Haraka crashes with FATAL state. SMTP service not reachable. users with incorrect password attempts:

In recovery mode, I could probably manipulate the queued email in /app/data/haraka-queue/ so that the To header is another domain which has a normal MX record and allows inbound mails.

Then restart. That could to the quick fix.

Or instead of manipulating, just delete the one.

Yes. Moving the affected mail from haraka-queue to /app/data/tmp was helping.
Mail starts as expected now, clients can connect.

[dev-cb]

Created an issue. https://github.com/haraka/Haraka/issues/3516