fix(reply): prefer Reply-To over From when choosing recipients - #68
Merged
Conversation
Closes #67. Reported by Kendell by email. `expand_reply_recipients` seeded the recipient list from `From` and never looked at `Reply-To`, though the model carries the field and the fetch already requests it. Support and transactional senders put a branded, often undeliverable address in `From` and the real inbox in `Reply-To`, so replies bounced. Reply-To replaces From rather than joining it: on reply-all the branded address is no more deliverable than on a plain reply. An empty Reply-To list is not a Reply-To and still falls back. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016ri9XAwMqKiHLrDyTuA3np
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #67. Reported by Kendell (kendell@kendell.dev) by email — interaction limits blocked them filing it.
The bug
expand_reply_recipientsseeded the recipient list fromoriginal.fromand never consultedoriginal.reply_to, though theEmailmodel carries the field andEMAIL_FULL_PROPERTIESalready fetchesreplyTo. Their reply bounced:Not cosmetic — support and transactional senders routinely brand the
Fromdomain and put the inbox that actually receives mail inReply-To.The fix
One helper, so the CLI's
replyand GraphQL'sreplyToEmailwere wrong together and are fixed together — the send preview included, which had been reporting the address it was about to fail to deliver to.Reply-ToreplacesFrom, it does not join it. On a reply-all the branded address is no more deliverable than on a plain reply, so adding it alongside would just bounce a copy.An empty
Reply-Tolist is not aReply-Toand falls back toFrom—Some(vec![])is a shape JMAP can return, and treating it as authoritative would reply to nobody.Verifying
215 tests green. Three added next to the existing recipient tests: preference over
From, reply-all usingReply-Toas the sender while still appending the originalTo, and the fallback for both absent and empty.