mail +reply / +reply-all: In-Reply-To header missing + default signature not attached

Summary

Two related defects observed when sending threaded replies via lark-cli mail +reply-all. Both produce subtly wrong outbound mail that looks fine from the CLI's perspective but renders incorrectly in the Feishu mail UI and to recipients' mail clients.

Environment

• lark-cli version: 1.0.38
• Identity: --as user
• Mailbox: a *.feishu.cn Feishu mail account
• Reproduced via both +reply and +reply-all

Issue 1: In-Reply-To header omitted → reply renders as a new email

Repro

# 1. Pick a parent message in an existing thread
PARENT_MSG_ID=…   # any Feishu message_id

# 2. Reply via the shortcut
lark-cli mail +reply-all --as user \
  --mailbox me@example.com \
  --message-id "$PARENT_MSG_ID" \
  --body "<p>Test reply</p>" \
  --confirm-send

Expected

Sent message has In-Reply-To: <parent-smtp-message-id@feishu.cn> (per RFC 5322), so the Feishu mail UI shows the circular-arrow "已回复" indicator next to the parent in the thread view.

Actual

$ lark-cli mail user_mailbox.messages get --as user \
    --params '{"user_mailbox_id":"me@example.com","message_id":"<SENT>"}' \
    --format json | jq '.data.message | {in_reply_to, references, thread_id}'

{
  "in_reply_to": null,
  "references": "<…parent-1…@feishu.cn> <…parent-2…@feishu.cn> <…parent-3…@feishu.cn>",
  "thread_id": "…matches parent thread…"
}

References is correctly populated (3 ancestors) and thread_id correctly matches the parent thread — but In-Reply-To is null. As a result, the Feishu mail UI displays the reply as a fresh thread (no "replied" icon), and external recipients' mail clients (Outlook, Gmail, Apple Mail) treat it as a new message rather than threading it under the original.

Workaround

Patch the draft with +draft-edit before sending:

# 1. Create the reply draft (omit --confirm-send)
DRAFT_ID=$(lark-cli mail +reply-all --as user --mailbox me@example.com \
  --message-id "$PARENT_MSG_ID" --body "<p>…</p>" | jq -r '.data.draft_id')

# 2. Fetch parent's smtp_message_id
SMTP_ID=$(lark-cli mail user_mailbox.messages get --as user \
  --params "{\"user_mailbox_id\":\"me@example.com\",\"message_id\":\"$PARENT_MSG_ID\"}" \
  --format json | jq -r '.data.message.smtp_message_id')

# 3. Patch the draft
cat > /tmp/p.json <<PATCH
{
  "ops": [
    {"op":"set_header","name":"In-Reply-To","value":"<$SMTP_ID>"}
  ],
  "options": {"allow_protected_header_edits": true}
}
PATCH
lark-cli mail +draft-edit --as user --mailbox me@example.com \
  --draft-id "$DRAFT_ID" --patch-file /tmp/p.json

# 4. Send
lark-cli mail user_mailbox.drafts send --as user --yes \
  --params "{\"user_mailbox_id\":\"me@example.com\",\"draft_id\":\"$DRAFT_ID\"}"

After this 4-step flow, in_reply_to is correctly populated on the sent message.

Suggested fix

+reply / +reply-all build the EML internally — the parent's smtp_message_id is already fetched (visible in the dry-run output). Adding it as an In-Reply-To header to the generated EML should fix this without a flag change. It would also be reasonable for the CLI to expose --in-reply-to for manual override.

Issue 2: Default signature not attached

Repro

lark-cli mail +reply-all --as user --mailbox me@example.com \
  --message-id "$PARENT_MSG_ID" --body "<p>Reply body</p>" --confirm-send

The user's mailbox has a personal signature with is_send_default: true and is_reply_default: true:

$ lark-cli mail +signature --as user --from me@example.com
{
  "signatures": [{
    "id": "7507…",
    "is_reply_default": true,
    "is_send_default": true,
    "name": "Signature",
    ...
  }]
}

Expected

Outbound reply automatically includes the default signature (matching the Feishu UI behavior when composing through the web client).

Actual

The signature is omitted entirely from the sent message. The user has to explicitly pass --signature-id <id> on every send — even though the signature is marked default.

Suggested fix

When --signature-id is omitted, look up the user's is_send_default (or is_reply_default for reply / reply-all / forward paths) signature and attach it. Match the UI's behavior.

Why it matters

Both defects produce outbound mail that looks fine from the CLI but breaks expectations on the receiving end. For senior-stakeholder and customer-facing communication where threading clarity and signature presence are signals of professionalism, these silent defaults cause real harm.

Related

• CLI version 1.0.39 is available (noticed in _notice output); not verified whether the new release fixes either issue.

Start with the +reply and +reply-all mail command paths, then compare their generated EML with the +draft-edit workaround. Verify that replies set In-Reply-To from the parent smtp_message_id and select the appropriate default signature when no --signature-id is provided; confirm both behaviors on sent messages and reply variants.