Expose Reply-To in MessageInfo metadata - #232
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8bcd1c725d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // Collect additional headers (everything except standard ones) | ||
| let standardKeys: Set<String> = [ | ||
| "from", "to", "cc", "bcc", "subject", "date", "message-id", | ||
| "from", "reply-to", "to", "cc", "bcc", "subject", "date", "message-id", |
There was a problem hiding this comment.
When an EML containing Reply-To is parsed, this change removes that header from additionalFields and stores it only in replyTo, but neither EMLSerializer.writeHeaders nor Email.init(message:) consumes the new property. Consequently, parse→serialize and Message→Email workflows now silently drop Reply-To—whereas it previously survived through additionalFields—so replies to exported or resent messages may go to From instead.
Useful? React with 👍 / 👎.
| uid: SwiftMail.UID? = nil, | ||
| subject: String? = nil, | ||
| from: String? = nil, | ||
| replyTo: [String] = [], |
There was a problem hiding this comment.
For a message/rfc822 BODYSTRUCTURE whose embedded envelope contains a reply address, MessagePart.embeddedMessageInfo(from:) still constructs MessageInfo without passing envelope.reply. As a result, the new property is always empty for embedded messages even though the same ENVELOPE metadata is available and is populated for top-level messages.
Useful? React with 👍 / 👎.
1 participant
Resolves #217.
Adds a public,
CodableMessageInfo.replyTo: [String], populated from the IMAP ENVELOPE and from a selectively fetchedReply-Toheader. ENVELOPE keeps precedence when both are present, matching the existing standard-header fallback.Covered by regression tests for the ENVELOPE projection, the
headerFields: ["Reply-To"]path, andMessageInfoCodable round trips.🤖 Generated with Claude Code