Raw message import
Preserves the original message content
InboxBridge carries the raw message bytes through the pipeline and appends them into IMAP destinations or hands them to the Gmail API.
Mailbox import without forwarding rules
Keep one inbox without giving up your other accounts.
InboxBridge imports mail from IMAP and POP3 source mailboxes into one destination mailbox. It supports Gmail API delivery, IMAP APPEND destinations, POP UIDL checkpoints, multi-folder IMAP with per-folder IMAP IDLE, encrypted UI-managed secrets, browser extensions for quick poll/status control, and a browser admin UI that does not require hand-editing configuration for day-to-day use.
What InboxBridge does
Designed for practical mailbox consolidation.
InboxBridge is broader than a simple forwarder. It keeps import history, supports multi-user deployments, and lets operators choose between env-managed and UI-managed configuration while running on a laptop, homelab server, Raspberry Pi, VPS, or dedicated host they control.
Source flexibility
Polling for everything, IDLE for IMAP
POP3 stays on polling with durable UIDL checkpoints. IMAP can poll one or many folders or opt into per-folder IMAP IDLE with scheduler fallback if a watcher stays unhealthy.
Operator choice
Web UI, remote, and browser companion
Most users can configure mailboxes in the web UI, use the lighter remote surface on a phone, or install browser extensions for quick poll-now, recent-import visibility, and error awareness without opening the full dashboard.
Top-level architecture
See the flow before you configure it.
InboxBridge sits between source mailboxes and one chosen destination mailbox, keeping import state, dedupe history, encrypted secrets, and realtime watcher state in the middle.
Sources
IMAP and POP3 accounts
Classic mailbox pull for everything, with multi-folder IMAP polling and optional IMAP IDLE watchers for eligible folders.
- Multi-folder IMAP polling
- IMAP IDLE
- POP3 UIDL checkpoints
InboxBridge core
Quarkus backend + PostgreSQL
Tracks per-folder checkpoints, dedupe, encrypted UI-managed secrets, live poll state, and post-import actions.
- IMAP and POP checkpoints
- Import history
- Token encryption
Destination
One mailbox, many imported sources
Deliver into Gmail through the Gmail API or into IMAP APPEND destinations such as Outlook and other providers.
- Gmail API
- IMAP APPEND
- Source labels and folders
Animated view
The moving mail icons represent messages progressing through detection, durable tracking, and final delivery. On IMAP IDLE sources, detection can start from a long-lived watcher instead of waiting for the next scheduled poll.
See here a lower-level runtime view A deeper view that shows which pieces handle encrypted transport, runtime coordination, and durable state.
This deeper view shows which pieces handle encrypted transport, runtime coordination, and durable state. InboxBridge processes message content only long enough to import it into the chosen destination, then keeps operational metadata such as dedupe identifiers, checkpoints, configuration, and encrypted secrets instead of maintaining its own searchable content archive.
Browser surfaces
Admin UI, InboxBridge Go, and extensions
Operators sign in, configure accounts, and trigger imports from the full admin workspace, the lighter remote surface, or browser extensions that expose quick poll and status controls.
Runtime coordinator
Quarkus polling and IDLE engine
InboxBridge manages IMAP polling, IMAP IDLE watchers, destination delivery, rate limits, retries, and source-side follow-up actions.
External providers
Source and destination mailbox services
InboxBridge connects over encrypted IMAP, POP3, Gmail API, and OAuth flows while the deployment owner keeps control over where the service runs.
Durable state
PostgreSQL for dedupe and encrypted secrets
PostgreSQL stores encrypted UI-managed secrets, IMAP checkpoints, dedupe identifiers, runtime settings, and notifications, not a second copy of mailbox contents for InboxBridge to browse.
Security highlights
Why the self-hosted runtime model matters
These cards call out the concrete security properties behind the flow above: encrypted transport, metadata-only persistence, operator-controlled deployment, and the fact that mailbox credentials stay under the owner’s control.
Transport security
Encrypted communication end to end
Mailbox access is designed around TLS-protected IMAP, POP3, HTTPS, and provider API traffic, so InboxBridge is not meant to shuttle credentials or mail over plaintext links.
Data minimization
Operational state instead of a shadow archive
InboxBridge stores the operational identifiers it needs for dedupe, checkpoints, configuration, and encrypted secret handling. It is not designed to retain its own searchable copy of email content.
Deployment control
Run it where you trust the machine
That can be your laptop, desktop, homelab server, Raspberry Pi, virtual private server, or dedicated host. The security win is that the software runs on infrastructure you control instead of a third-party mailbox aggregation service.
Source of trust
Credentials stay with the operator
InboxBridge is strongest when the operator controls the runtime, backups, disk access, and network boundary. That is the core difference between self-hosting and handing mailbox credentials to an external SaaS bridge.
How it works
Three moving parts, one clean import path.
InboxBridge reads from source accounts, deduplicates imports, and writes into one destination mailbox while tracking runtime state.
1
Connect sources
Configure one or more source mailboxes from the UI or `.env`. IMAP sources can use either scheduled polling or IMAP IDLE.
2
Import safely
InboxBridge records dedupe state in PostgreSQL and can optionally mark, move, delete, or mark-read handled IMAP source messages.
3
Deliver centrally
Messages are delivered into Gmail or IMAP APPEND destinations so the destination mailbox becomes the single place to triage mail.
FAQ
Answers to the first operator questions.
These are the common points people usually want clarified after seeing the flow, the architecture view, and the env-managed generator.
Why is the self-hosted model important for security?
InboxBridge is for people who want mailbox consolidation without handing credentials to a third-party service. Passwords, app passwords, refresh tokens, and import history stay on infrastructure you control, whether that is a personal computer, homelab server, Raspberry Pi, VPS, or dedicated host.
Are IMAP and POP3 secure enough for this?
Yes, when they are used over encrypted connections. InboxBridge is designed for TLS-protected mailbox access such as IMAPS and POP3S. The real risk is not the protocol name, but weak deployment choices like plaintext transport or careless secret handling.
Why import mail instead of using forwarding rules?
Forwarding rules relay mail onward as a new delivery step. InboxBridge instead fetches messages from the source mailbox and imports them into the destination mailbox. That keeps the flow closer to mailbox import than classic forwarding and avoids turning InboxBridge into a forwarding hop.
Does InboxBridge preserve the original message content?
Yes. InboxBridge carries the raw message bytes through the import pipeline, so IMAP APPEND destinations receive the original RFC822 message content instead of a rebuilt synthetic forward.
Is IMAP IDLE real-time?
It is near-real-time for supported IMAP sources. InboxBridge keeps a long-lived IMAP IDLE watcher per configured folder, uses durable UID checkpoints, and falls back to scheduler polling if a watcher stays unhealthy long enough.
Can I still reply from another address?
Yes, if your destination mailbox or mail client supports sending as another identity. InboxBridge handles inbound consolidation; outbound identities are still configured on the destination side.
What providers does InboxBridge work with?
Source-side support is broad: any provider that gives you usable IMAP or POP3 access can usually fit. Destination-side support depends on the import path, including Gmail API and IMAP APPEND destinations such as Outlook, Yahoo, Proton Bridge, and other standard IMAP providers.
Does POP3 have an IMAP IDLE equivalent?
No. POP3 remains polling-only. If a provider exposes only POP3, the usual way to make it feel more responsive is to shorten the poll interval rather than expecting a push-style mailbox listener.
Do I need to use the generated `.env` file?
No. The browser generator is for operators who want env-managed setup. Normal day-to-day mailbox setup can still be done from the InboxBridge admin UI with encrypted secret storage in PostgreSQL.
Is the `$Forwarded` marker standard?
Not in the same sense as `\Seen`. InboxBridge can try to add `$Forwarded` to a source message after it has already imported it, as a mailbox-side hint that the message was handled. That marker is commonly treated as an IMAP keyword rather than a standard built-in system flag, so support varies by server. InboxBridge treats it as best-effort only and does not rely on it for correctness.
Can the page generate the token encryption key safely?
Yes, when the browser exposes secure Web Crypto. The page generates 32 random bytes locally in the browser and converts them into the base64 value InboxBridge expects. If Web Crypto is unavailable, the page tells you to generate the key outside the browser instead.
Operator helper
Generate a starter `.env` for env-managed deployments.
You are usually better off starting with the minimum `.env` needed to boot InboxBridge, so you avoid leaving mailbox passwords in plain text inside `.env`, then completing destination and source mailbox setup inside the application web interface. Use this helper when you want that minimal bootstrap or when you intentionally need env-managed accounts.
Generated output
Starter `.env`
Preparing your starter configuration…
Good fit
- You want one self-hosted destination mailbox for multiple sources.
- You want IMAP APPEND or Gmail API delivery instead of forwarding rules.
- You want a real admin UI, multi-user support, and durable dedupe history.
Worth remembering
- POP3 has no IMAP IDLE equivalent, so POP3 sources stay on polling.
- The optional source-side `$Forwarded` marker is just a best-effort IMAP keyword that can be written back to a handled source message, and some servers do not support it.
- InboxBridge uses encrypted mailbox and API connections, and its database is meant to hold operational metadata, checkpoints, dedupe identifiers, and encrypted secrets rather than a shadow archive of message content.
- The generator can create the 32-byte base64 token encryption key in the browser, but it is still a convenience for operators, not a substitute for the full setup docs.