NeoMail handles untrusted email content, attachments, external SMTP/IMAP servers, and LLM prompts derived from mailbox data. Safety depends on server-side authorization and deployment choices, not on prompt quality alone.
- Each user owns their own local account, sessions, settings, API keys, and mailbox rows.
- API keys are per-user only. There are no global mailbox keys in v1.
- MCP tools execute only within the authenticated user's mailbox scope.
- Admin routes are separate from end-user routes and require admin auth.
- IMAP and SMTP credentials are stored encrypted at rest.
- API keys are stored hashed and only shown once at creation.
- Session and encryption secrets are loaded from the runtime env.
- Summaries, draft improvements, subject help, label suggestions, and inbox Q&A are assistive.
- Outbound or destructive actions should require explicit user intent.
- Phrase-based filters are intentionally avoided; AI decisions should be model-driven from structured thread and message context.
- NeoMail is suitable for trusted self-hosted deployments, not hostile internet multi-tenancy.
- IMAP provider behavior varies; some flags and folder semantics differ across vendors.
- Attachments and message bodies may contain prompt injection or malicious instructions; never treat model output as authorization.
- Run NeoMail as a dedicated unprivileged OS account.
- Put HTTPS and a real reverse proxy in front of it for remote access.
- Restrict firewall exposure to the web surface only.
- Back up the runtime directory securely.
- Review API key issuance and admin access regularly.