Reported issues for email-mcp

Pod holds 17 of 22 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 email-mcp.

Most discussed

read_only does not gate background services: a read-only server still sends scheduled mail

This is from reading the source on the default branch rather than from a runtime report, so I have left out the version and client fields in the bug template.

Description

read_only gates tool registration, but not the services started at init, so a server configured read-only still sends mail on its own.

src/tools/register.ts reads the flag at line 54 and skips registering the write tools at line 77. That part works: a client cannot call what was never registered. src/main.ts never r

Read the thread · 2026-08-27 · open · external user · 0 comments

Offer to help work through the open PR backlog

Hi Colin,

First: thank you for this. It is the best email MCP server out there, and I use it daily.

I have been reading through the open PRs and noticed they cluster into a handful of underlying problems, with a few of them converging on the same root cause. I wrote that up here in case a single view of it is useful, and to offer a hand if you want one.

1. IMAP idle drops can take down the process. #29, #44, and #64 arrive at the same fix independently: attach error and close handlers

Read the thread · 2026-08-17 · open · external user · 0 comments

get_email can miss the real body of multipart/alternative messages

Summary

get_email can return only a tiny text/plain fallback, or no useful body, for multipart messages where the meaningful content lives in a sibling text/html MIME part.

This was reproduced with a normal multipart/alternative marketing email: IMAP server-side body search could find text that was visibly present in the message, while get_email(format="text") did not expose it to the MCP client.

Current behavior

messageToEmail() parses the top-level source and then uncondi

Read the thread · 2026-08-16 · open · external user · 1 comment

stdio server never exits when the client closes stdin — orphaned processes accumulate (232 in 7 days, 5.2 GB RSS)

Description

The stdio server never terminates when the MCP client closes its stdin. Every client disconnect that does not deliver SIGTERM — closing a terminal window, SIGKILL, a client crash, or an MCP server reconnect — leaves an immortal process behind, reparented to launchd (macOS) or init/systemd (Linux).

These accumulate silently. On one workstation I found 232 orphaned email-mcp process pairs (npm exec wrapper + node child) after 7 days of uptime, holding **5.2

Read the thread · 2026-08-06 · open · external user · 1 comment

Unhandled 'error' event on ImapFlow client crashes the whole process on socket timeout

Description

Environment

• @codefuturist/email-mcp: 0.2.3
• imapflow (transitive dep): ^1.2.9
• Node.js: v24.18.0
• Deployed behind sparfenyuk/mcp-proxy (streamable HTTP, --no-stateless)

What happened

Under a burst of ~20+ concurrent tool calls (mark_email/move_email) against a single IMAP account, one underlying IMAP connection was left idle after a STATUS command. After ImapFlow's default 5-minute socketTimeout elapsed, the server closed it and ImapFlow emitted an 'error' event

Read the thread · 2026-07-23 · open · external user · 1 comment

Request for a private vulnerability-reporting contact

Hello,

I believe I have identified a potential dependency security issue in email-mcp. I followed SECURITY.md, but the linked GitHub Security Advisory reporting URL returns “Page not found” for an external contributor.

Could you please provide or enable a private reporting channel? I will share the details only through that channel.

Thank you.

Read the thread · 2026-07-10 · open · external user · 1 comment

Memory leak in long-running process — JS heap exhaustion after ~6 days

Bug: Memory leak in long-running email-mcp process

Summary

email-mcp's JavaScript heap grows steadily over days of continuous operation until it exhausts available memory and crashes with OOM. This affects any long-running deployment (HTTP server, Docker container, systemd service), not a specific transport mode.

Environment

• Transport: HTTP (Streamable HTTP), but same runServer() code path as stdio
• Node.js: 24 (node:24-slim)
• Accounts: 2 IMAP accounts
• Container memory l

Read the thread · 2026-07-09 · open · external user · 1 comment

Feature request: add savePath parameter to download_attachment to avoid base64 overhead

Problem

When using download_attachment, the tool returns the entire file content as a base64-encoded string in the MCP response. For attachments larger than ~100KB, this creates several problems:

1. The base64 string is enormous — a 3MB docx becomes ~4MB of base64 text in the response
2. MCP clients (like Claude Code) hit token limits and dump the result into a temporary JSON file, requiring additional parsing and decoding steps
3. The round-trip is slow and error-prone — what

Read the thread · 2026-03-03 · open · external user · 1 comment

Most recent

Ontheia listed as compatible client — works great with email-mcp

Hi,

We've been testing your MCP server with Ontheia — a self-hosted, open-source AI agent platform — and it works great out of the box.

We've added it to our Compatible MCP Servers page to help our users discover it.

If you'd like to list Ontheia as a compatible client in your README, we'd be happy about that — but no obligation at all.

Thanks for building this! — Wolfgang, founder of Ontheia

Read the thread · 2026-08-23 · open · external user · 0 comments

Search-backed tools silently return zero results on servers with a broken IMAP4rev2 implementation (STRATO) — please expose disableIMAP4rev2

Summary

On STRATO-hosted mailboxes (imap.strato.de), every search-backed tool returns "No emails found" even though the mailbox is connected, healthy, and list_mailboxes reports the correct message counts.

The cause is not in email-mcp's own logic. ImapFlow issues ENABLE CONDSTORE IMAP4REV2 on connect. STRATO acknowledges IMAP4rev2 and then answers SEARCH with an empty ESEARCH response. Because the tools are built on client.search(), they all return zero rows.

ImapFlow alread

Read the thread · 2026-08-21 · open · external user · 0 comments

Expose read-only sender authentication signals for safe email triage

Summary

EmailMCP already parses message headers internally (Email.headers), but MCP clients cannot access sender-authentication signals such as SPF, DKIM and DMARC. This makes it harder to distinguish legitimate marketing from brand impersonation without relying on sender display names or ad-hoc domain rules.

A focused read-only tool could expose only the security-relevant subset of headers, without returning the full raw header block.

Proposed tool

get_email_security

Inputs:

• `a

Read the thread · 2026-08-18 · open · external user · 0 comments

send_email: a retried call is indistinguishable from a new email — nothing in the path can dedupe it

First: this is a genuinely well-built server — the append-only audit log, the rate limiter, and input validation put it ahead of most MCP servers I've read. This issue is about the one gap that safety net doesn't cover.

The scenario. An agent calls send_email. The SMTP conversation is slow; the MCP client times out and retries — or the agent itself decides the call failed and tries again. The recipient gets two identical emails. With bulk or scheduled sends, the same shape amplifies.

Read the thread · 2026-08-10 · open · external user · 0 comments

Ordering by UID instead of date

Description

When using the list_emails tool the returned emails are ordered by UID. This ordering is not the same as by date. Because emails are inherently time sensitive it would seem more logical to default to sorting by date, newest first.

Steps to reproduce

Run list_emails on a mailbox where ordering by date isn't the same as ordering by UID

Expected behavior

I would expect the ordering to default to date, newest first.

Actual behavior

Emails are ordered by UID

Ve

Read the thread · 2026-08-05 · open · external user · 0 comments

Every tool call fails on llama.cpp-based local models (LM Studio, Ollama, llama-server)

This server does not work with local models. If you run a model through llama.cpp — which is what LM Studio, Ollama and llama-server all use — every tool call fails before the model writes a single token.

invalid_request_error: Failed to initialize samplers: failed to parse grammar

It is not just the email tools that die. llama.cpp turns the whole tools list into one grammar, so these three tools take down every tool in the request, including tools from other MCP servers.

**

Read the thread · 2026-07-24 · open · external user · 0 comments

send_email / reply_email / forward_email do not save to Sent folder

Bug Report

Description

The send_email, reply_email, and forward_email tools send messages via SMTP but do not save a copy to the IMAP Sent folder. This means sent emails are invisible in any email client (Apple Mail, Thunderbird, webmail, etc.).

Expected behavior

After a successful send, the message should be appended to the Sent folder via IMAP APPEND, similar to how save_draft works in imap.service.js.

Root cause

In smtp.service.js, all three send methods call

Read the thread · 2026-06-24 · open · external user · 0 comments

send_email and send_draft do not support attachments

Summary

send_email has no attachments parameter, and send_draft silently drops attachments that were saved in the draft.

Current Behavior

send_email

No attachments parameter. Only supports: account, to, subject, body, cc, bcc, html.

send_draft

save_draft and update_draft fully support attachments (path, base64, message-reference). However, send_draft extracts only bodyText/bodyHtml from the draft and sends via SMTP — the draft's attachments a

Read the thread · 2026-06-10 · open · external user · 0 comments

list_events silently returns empty on macOS: 15s timeout too short for multi-calendar AppleScript whose-query

Summary

On macOS, list_events silently returns an empty list (No events found) for every query — including date ranges that definitely contain events — while list_calendars and check_calendar_permissions work correctly. The root cause is that the AppleScript event query routinely exceeds the hardcoded 15s execFile timeout, and the timeout error is swallowed by a bare catch { return [] }, making a hard failure indistinguishable from a legitimately empty result.

Environment

Read the thread · 2026-05-22 · open · external user · 0 comments

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