send-reply defaults to single-recipient unless --reply-all is passed

[vish-dini]

Summary

send-reply in the CLI appears to default to replying to sender only unless --reply-all is explicitly passed, which can cause agents to break threaded conversations with CC-heavy mail.

Finding

In src/main.rs, Commands::SendReply has reply_all: bool with no default override, and the handler injects reply_all only when the flag is set:

let mut args = json!({"in_reply_to": message_id, "body": body});
if reply_all {
    args["reply_all"] = json!(true);
}

So behavior is currently opt-in.

Why this matters for agent flows

The current MCP skill instructions in skills/*/email-reply/* treat --reply-all as an optional additional flag and include separate CC-preservation guidance. For multi-recipient chains, agents can omit it and accidentally send only a direct-reply.

Impact

• Replies on CC-heavy threads may unintentionally go only to the original sender.
• This matches the reported behavior where agents forget reply-all in threaded mail with many recipients.

Suggested fix

1. Make send-reply default to reply_all = true.
2. Keep an explicit opt-out path if needed (--reply-to-sender or --no-reply-all) for compatibility.
3. Update skill docs (skills/*/email-reply/*) and CLI docs/help examples so reply-all is the default behavior.
4. Add regression coverage: CLI tool-arg test asserting reply_all is present by default for send_reply.

Note

I did not find SMTP daemon logic in this repo; this appears to be CLI/tooling + skill-instruction behavior rather than transport-layer SMTP code.

[vish-dini]

Additional findings from a wider pass:

• The upstream MCP contract matches the current CLI behaviour. In inboxapi/mcp, SendReplyRequest.reply_all is defined with #[serde(default)] and documented as default: false = reply to sender only.
• The MCP handler only reconstructs full thread recipients when request.reply_all is true; otherwise it resolves Reply-To or the original sender only.
• The bundled reply skills across model targets (skills/codex/email-reply/SKILL.md, skills/claude/email-reply/SKILL.md, skills/gemini/email-reply/SKILL.md, skills/opencode/email-reply.md) currently teach agents to preserve CCs manually with --cc and treat --reply-all as optional, which reinforces the wrong default for multi-recipient threads.
• I did not find evidence in the inboxapi/smtp repo of thread-aware reply logic that would explain this independently. SMTP appears to just deliver the recipient set it is given.

So the bug looks systemic across CLI + MCP contract + bundled agent guidance, not an SMTP transport regression.

[vish-dini]

Sara found a few stronger bugs in the reply path:

• The current skills recommend send-reply with --cc but without --reply-all. In the MCP handler, the non-reply_all branch returns (to, None), so explicit CC values are effectively dropped unless reply_all=true.
• Reply-all ignores Reply-To. The handler loads the original reply_to, but only the sender-only branch uses it; the reply-all branch always uses the original sender in To.
• Reply-all reconstruction is naive. It rebuilds recipients by splitting stored recipients and cc strings on literal commas, which is not RFC-aware and can break on display-name forms or more complex address formatting.
• Reply-all excludes every address on the original domain, not just the agent mailbox or aliases, so it can drop legitimate participants.

So this is broader than docs and defaults: there are concrete recipient-resolution bugs in the MCP reply path too.