# Reported issues for mailbox-mcp

Pod holds 12 of 12 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [mailbox-mcp](/mcp/mailbox-mcp).

## 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`:

```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

### 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

### 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](https://github.com/jgalea/mailbox-mcp/issues/8) · 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:

```ts
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](https://github.com/jgalea/mailbox-mcp/issues/6) · 2026-04-20 · closed · external user · 1 comment

### 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

## Most recent

### 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

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

`inboxSummary()` has two bugs:

```ts
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](https://github.com/jgalea/mailbox-mcp/issues/7) · 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](https://www.rfc-editor.org/rfc/rfc3501.html#section-2.3.2) 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](https://github.com/jgalea/mailbox-mcp/issues/4) · 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`:
 - [fetchMessage](https://github.com/jgalea/mailbox-mcp/blob/5904e05f02aa2d3658e90fbb666da47320418b01/src/providers/imap.ts#L79): `fetchOne(p

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

The remaining reports are on [the project's issue tracker](https://github.com/jgalea/mailbox-mcp/issues).