Support Binding Outbound SMTP Connections to a Specific Network Interface

Feature Ideas
1

Reference discussion:
https://github.com/stalwartlabs/stalwart/discussions/1849#discussioncomment-16841134

Summary

In Kubernetes/Talos Linux environments where nodes have multiple public IP addresses (for example provider-assigned IPs plus Elastic/Floating IPs), Stalwart currently cannot reliably bind outbound SMTP traffic to the intended secondary IP address using only the existing source-ip configuration.

This becomes particularly problematic in clustered StatefulSet deployments using hostNetwork: true, where each node may expose multiple interfaces or routed secondary addresses.

Current Behaviour

Stalwart currently allows specifying only a source IP for outbound SMTP connections.

However, on some Linux networking setups (In my particular case Talos Linux and certain cloud providers using routed Elastic IPs), the secondary/public IP is not directly attached to the interface visible inside the pod namespace. As explained in the maintainer response, a plain bind() to the secondary IP may fail with:

EADDRNOTAVAIL

because Linux selects a different NIC/interface during routing resolution.

Proposed Enhancement

Add an optional interface/device configuration field alongside the existing outbound source-ip setting.

Example conceptually:

[queue.source-ip."203.0.113.10"]
interface = "eth0"

When specified, Stalwart would apply:

SO_BINDTODEVICE

before the socket bind() call.

Benefits

  • Reliable outbound IP pinning in multi-IP environments

  • Better support for Kubernetes + hostNetwork deployments

  • Improved compatibility with Talos Linux networking and possibly others

  • Proper support for routed Elastic/Floating IP architectures

  • More predictable SMTP egress identity and reputation management

Real-World Use Case

Environment:

  • Kubernetes StatefulSet

  • Talos Linux

  • One Stalwart pod per node

  • hostNetwork: true

  • Cluster mode enabled

  • Nodes with:

    • provider-assigned primary IP

    • secondary Elastic/Floating IP used for SMTP egress

Goal:

Ensure each Stalwart instance can explicitly bind outbound SMTP traffic to the correct interface associated with the designated Elastic IP.

Additional Notes

This request is based on the maintainer recommendation in the linked discussion, where it was explained that the issue cannot be solved reliably with an IP-only configuration and that interface-aware binding via SO_BINDTODEVICE would address the problem cleanly.