Delivery Test Node Pinning in Cluster?

Issues
1

Issue Description

We are testing a clustered setup with 5 nodes. 3 as SMTPS/POP/IMAP/HTTP nodes, and 2 as SMTP outgoing.

When running the mail delivery test feature, if the test lands on a node without SMTP outgoing (no outgoing connectivity except through the proxy), it will fail.

Expected Behavior

Delivery test should be pinned to only choose nodes with outgoing MTA role to replicate real delivery from outgoing MTA nodes.

Actual Behavior

Delivery test fails as IMAP/POP nodes do not have SMTP outgoing capabilities with our firewall rules.

Reproduction Steps

Configure stalwart clustered setup, put some nodes on nonroutable IP space behind a haproxy load balancer, and some nodes on routable space with outgoing firewall rules.

Attempt to send a delivery test.

Stalwart Version

v0.16.x

Installation Method

Binary (Linux)

Database Backend

FoundationDB

Blob Storage

FoundationDB

Search Engine

Internal

Directory Backend

Internal

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

Your read is right. The delivery test runs on whichever node handles the admin HTTP request and opens the outbound connection from there; it doesn’t consider the outbound_mta role, so behind the load balancer it can land on a node with no egress and fail, even though real queued delivery (which only runs on your outbound MTA nodes) would succeed. There’s no setting to pin the test to those nodes today.

As a workaround, reach the admin HTTP endpoint directly on one of the two outbound MTA nodes (bypassing haproxy) and run the test there; that reproduces the real egress path. Dispatching the diagnostic to an outbound MTA node is a reasonable enhancement.

3

That would be a welcomed enhancement. Unfortunately hitting nodes directly on HTTP(s) is something we are not going to be allowing via our security posture.