Configurable reply address per channel

[jbagsik]

Parent

#1

What to build

Outgoing mail carries a configured reply address, so that a person answering it reaches a mailbox people actually read.

This is small and worth its own decision because of what it achieves for free. Automatic responders and non-delivery reports go to the envelope sender; a human pressing Reply goes to Reply-To. Setting one header therefore separates people from machines with no classification at all: answers land where someone works, while reports keep returning to the automated mailbox that expects them.

It also sidesteps a limitation that blocks the neighbouring problem. Suppressing auto-responders would need Auto-Submitted, which a structured provider payload will not carry — such payloads accept only x- prefixed custom headers. A reply address is a first-class message property on those same APIs, so this one is simply available.

Configured per channel, with no default: a package that guesses a reply address sends answers into a void.

Acceptance criteria

• With a reply address configured for a channel, sent mail carries it
• With none configured, mail is sent without one and nothing fails
• A per-message reply address set by the caller wins over the configured one
• The configured address is recorded on the send log row, so a later answer can be traced to the address that invited it
• Covered by tests that assert the outgoing message, with no transport involved
• README documents the setting and states plainly that this does not redirect bounces or auto-replies — those follow the envelope sender; CHANGELOG updated

Blocked by

• Send a mail through SendMailJob and record it in the send log #2 — sets the message and writes the log row this extends.