Repository navigation
Client-facing signal for which SMTP transport actually sent a message #8798
Description
The multi-transport series (#8619, #8705, #8703, #8709, #8797 merged; #8711, #8771
open; umbrella #8572) removes ConfiguredAddr and manual transport selection —
great cleanup, but it also removes the last way for a client to know which SMTP
transport a message actually went out on.
Today the SMTP loop knows the transport (e.g. #8797 resets transport_id there),
but nothing exposes it. What's left for clients:
- per-message "sent via " in the message info / UI — useful for multi-relay
users debugging delivery, and the send-side counterpart of the per-transport
connectivity view (adapt connectivity_html to multi transport #7580, Display quota for all transports in connectivity view #7591) - visible confirmation when failover (Queue messages for SMTP before encryption [send failover] #8619, If default sending relay is down/unreachable, every message sent delays #8762) switches transports mid-flight
Proposal (open to shape): record the transport used on the message at send time
and expose it — e.g. a field on the delivered message /MsgDeliveredevent, or
aget_sending_transport(msg_id)RPC. Minimal surface, no behavior change.
Happy to help with the implementation.
Activity
Hocuri commentedon Oct 6, 2026
What exactly would you like to use this information for? Is it in order to expose the info to the user, or for debugging message sending problems you have?
And, I guess you would like this for https://github.com/pbuzdin/velta?
pbuzdin commentedon Oct 6, 2026
Both, but mainly user-facing. Yes, it's for Velta.
A read-only field is all I need: a transport id or address stored on the message at send time, readable through message info or the
MsgDeliveredevent. No new UI requirements for core, and no behaviour change. If it's too niche for core, I'm also fine keeping it out of tree.Hocuri commentedon Oct 13, 2026
Thinking about it, I don't think this warrants a new (in-tree) API, because we generally want to keep the API surface small (or at least, not bigger than it already is).
But I agree that this info should go somewhere, either:
get_message_info(). This is less easy for the user to find and understand, and it will require us to store more database state, but it may be more helpful for debugging.pbuzdin commentedon Oct 14, 2026
Connectivity view is ok, and its what Velta already does.
“last used for sending” line in get_connectivity_html (the addr or id the SMTP loop is bound to, updated on connect/failover, not only after successful send) lets us delete our local smtp-via patch. That is the marker on the relay line, so Velta users see which relay messages are going through after failover.
get_message_info() debug text would not help. We would not parse it for UI, and we do not need per-message history for this.
No new API is needed. If that is too much for in-tree, we keep the patch.