pod
Other formats agents might prefer:
markdownjsonllms.txt

Agent? You probably want markdown or json, or Pod over MCP.

Reported issues for mailbox-mcp by jgalea

Pod holds 13 of 13 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects.

Back to mailbox-mcp by jgalea.

Most discussed

create_filter passes add_label straight to addLabelIds, so a filter can apply TRASH or SPAM

Summary

create_filter passes add_label straight into Gmail's addLabelIds with no validation of the value. Gmail's system label IDs are literally TRASH and SPAM, so a single call can install a permanent filter that silently destroys or junks all future matching mail.

Verified against v0.10.0 (2833b26).

Where

src/tools/gmail-only.ts:

const action: Record<string, any> = {};
if (args.add_label) action.addLabelIds = [args.add_label as string];
if (args.remove_label) a

[Read the thread](https://github.com/jgalea/mailbox-mcp/issues/23) · 2026-08-14 · open · external user · 2 comments

### Gmail Date: header reaches the model outside the UNTRUSTED fences (all four read tools), and the fences are never explained to the model

## Summary

The Gmail `Date:` header is the one attacker-controlled field that never passes through `fenceEmailContent`/`fenceEmailHeader`, so it reaches the model outside every fence. An attacker does not need to defeat `escapeFenceTags`; they use the field the escaper never sees.

Separately, the `[UNTRUSTED_*]` markers are never explained to the model, so even correctly fenced content carries no instruction about how to treat it.

Verified against `v0.10.0` (`2833b26`).

## 1. `Date:` is emit

[Read the thread](https://github.com/jgalea/mailbox-mcp/issues/22) · 2026-08-14 · open · external user · 2 comments

### download_attachment: lookup by filename fails (only numeric part id works); contradicts tool docs

## Summary

`download_attachment` fails with `Attachment <name> not found` on IMAP accounts, even when the attachment exists and the exact filename is the one reported by `read_email`. The attachment data itself is retrievable (`export_email` returns the full `.eml` with a valid file inside), so the problem is in resolving the attachment id/part, not in fetching from the server.

## Steps to reproduce

1. On an IMAP account, find a message with a single PDF attachment.
2. `read_email` shows the 

[Read the thread](https://github.com/jgalea/mailbox-mcp/issues/16) · 2026-05-26 · closed · external user · 2 comments

### IMAP search_emails returns no results for non-ASCII (Cyrillic) queries

## Summary

`search_emails` on IMAP accounts returns no results when the query contains non-ASCII (e.g. Cyrillic) characters, even when matching messages clearly exist. ASCII/Latin queries on the same account work fine.

## Steps to reproduce

1. Use an IMAP account that has messages with non-ASCII text in the subject (e.g. a Cyrillic subject).
2. Confirm the message exists, e.g. via `inbox_summary` (it lists a message whose subject contains the word).
3. Call `search_emails` with that non-ASCII

[Read the thread](https://github.com/jgalea/mailbox-mcp/issues/15) · 2026-05-26 · closed · external user · 2 comments

### IMAP search() and messagesSince() call imap.search() without {uid:true} — sequence/UID coincidence breaks on mid-query expungement

## Summary

`ImapProvider.searchMessages` (via `searchByText`) and `ImapProvider.messagesSince` call `imap.search(...)` without the options-level `{ uid: true }` argument. imapflow's `search` returns **sequence numbers** in that mode, but the code then passes those numbers to `fetchAll(...)` without `{ uid: true }` either, so the resulting calls are seq-based throughout.

This works by coincidence in most cases — on mailboxes where messages haven't been expunged, sequence numbers are dense and c

[Read the thread](https://github.com/jgalea/mailbox-mcp/issues/10) · 2026-05-24 · closed · 2 comments

### Security claims in README don't match implementation (body not fenced, audit evidence missing)

Heia,

This looks promising. That said:

Actually secured. 6 rounds of security auditing. Encrypted credentials (AES-256-GCM), prompt injection fencing on every email field, rate limiting, TLS enforcement, SSRF protection with IP encoding evasion detection, input validation. Most MCP servers skip security entirely.

This should be accompanied with proof.
I'd suggest to either:
1. Provide links/dates for the external audits, or
2. Reword to "internal review" / "self-audited" so users can ma

[Read the thread](https://github.com/jgalea/mailbox-mcp/issues/1) · 2026-04-12 · closed · external user · 2 comments

### Bug: read_email returns empty body for multipart messages on IMAP (bodyStructure uses node.type for full MIME, not type+subtype)

## Summary

On IMAP accounts, `read_email` (and `read_thread`) returns an **empty body** for any multipart message (e.g. `multipart/alternative` with `text/plain` + `text/html`, which is virtually every real-world email). Envelope metadata (from/to/subject/date) is correct, but `body` comes back as `""`. The same root cause also breaks the MIME type reported for attachments.

This is independent of the UID/seqno fixes in #11/#13 — those are working; the body just never gets extracted.

## Reprod

[Read the thread](https://github.com/jgalea/mailbox-mcp/issues/14) · 2026-05-25 · closed · external user · 1 comment

### Bug: IMAP searchByText returns sequence numbers instead of UIDs — read_email/export_email fetch wrong message

## Summary

`searchMessages` on IMAP accounts returns results with `id: "${folder}:${seqno}"` instead of `${folder}:${uid}`. When the same ID is later passed to `read_email` / `export_email` / `mark_read` / `star_email`, the client parses the number as a UID and fetches a **different message** — whichever one currently has UID equal to that sequence number.

## Reproduction

1. Configure any IMAP account (tested on Gmail via `imap.gmail.com:993`).
2. Call `search_emails` with a narrow query (e.g

[Read the thread](https://github.com/jgalea/mailbox-mcp/issues/9) · 2026-04-24 · closed · external user · 1 comment

## Most recent

### IMAP provider: all message operations hardcode "INBOX", making multi-folder mailboxes unusable

Every IMAP operation — `search_emails`, `read_email`, `read_thread`, `modify_email`, `batch_modify_emails`, `trash_emails`, and `download_attachment` — opens a lock on `"INBOX"` regardless of what the caller needs:

```ts
const lock = await this.imap.getMailboxLock("INBOX");

This means any message that lives outside INBOX (Sent, Spam, custom folders like INBOX.Work) is completely unreachable. Attempting to read or modify such a message by UID returns Message not found, because the UID n

Read the thread · 2026-04-20 · closed · external user · 1 comment

IMAP provider: inbox_summary reports wrong unread count and empty recent list

inboxSummary() has two bugs:

const status = (this.imap as any).mailbox;
const recent = await this.searchMessages("*", 5);
return { total: status?.exists ?? 0, unread: status?.unseen ?? 0, recent };

Bug 1 — stale unread count: mailbox.unseen is read from imapflow's internal cache rather than queried from the server. The cached value does not reflect the current mailbox state and returns an incorrect count.

Potential fix: issue an IMAP STATUS command via `client.status()

Read the thread · 2026-04-20 · closed · external user · 1 comment

IMAP provider: search_emails wildcard * returns wrong results; inboxSummary recent list broken

searchMessages() passes the query string directly to an IMAP text search:

await this.imap.search({ or: [{ subject: query }, { body: query }] })

When called with query="*", this searches for the literal asterisk character in subject and body. It returns only messages that happen to contain * in their text — a meaningless and inconsistent subset of the mailbox, not "all messages".

This manifests in two places:

  1. search_emails with no meaningful query — callers expecting

Read the thread · 2026-04-20 · closed · external user · 1 comment

IMAP provider: modify_email passes label names as IMAP flags instead of RFC 3501 system flags

modify_email passes caller-supplied strings (UNREAD, FLAGGED, etc.) directly to imapflow's messageFlagsAdd/messageFlagsRemove. These are not valid IMAP flags — RFC 3501 system flags use backslash-prefixed names (\Seen, \Flagged, \Answered, \Deleted, \Draft).

As a result, remove_labels: ["UNREAD"] sends STORE -FLAGS (UNREAD) to the server. Servers may silently accept an unknown keyword removal without error, but

Read the thread · 2026-04-20 · closed · external user · 0 comments

IMAP provider: UID vs sequence number mismatch breaks read_email, modify_email, trash, and download_attachment

All IMAP operations that accept a messageId treat it as an IMAP sequence number, but the IDs exposed to callers (via search_emails, inbox_summary) are UIDs. On any mailbox with more than a handful of messages, the sequence number and UID diverge, so these operations silently fail or hit the wrong message.

Affected methods in src/providers/imap.ts:

Read the thread · 2026-04-20 · closed · external user · 0 comments

The remaining reports are on the project's issue tracker.