Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Imap Laravel Package

ddeboer/imap

A modern PHP IMAP library for reading mailboxes and messages. Connect to servers, list folders, fetch and search messages, inspect headers, bodies and attachments, flag or move mail, and work with UTF-8 folder names through a clean, object-oriented API.

Deep Wiki
Context7

Product Decisions This Supports

  • Build vs. buy for inbound email ingestion. This package makes "poll an existing mailbox" a credible in-house option versus per-message inbound-parse providers (Mailgun Routes, SendGrid Inbound Parse, Postmark). The decision turns on cost model: no per-email fees and no email content leaving our infrastructure, traded against ops work we now own (workers, retries, dedupe).
  • Onboarding model: "connect your mailbox" vs. "forward to a generated address." Forwarding is cheap to build on top of any inbound provider; connecting a user's real Gmail/Outlook/shared mailbox at the folder level generally requires IMAP (or a vendor sync API). If that onboarding path is on the roadmap, this is the enabling dependency.
  • Roadmap features it unlocks: email-to-ticket / shared support inbox, AP invoice and receipt ingestion, attachment extraction into a document pipeline, CRM/logged-email sync, automated mailroom rules (route by sender/subject, archive, flag), and mailbox hygiene jobs.
  • Scope discipline. It reads and manages mailboxes (folders, messages, flags, attachments, search); it does not send mail. Outbound stays with Symfony Mailer/Laravel Mail or an ESP — don't let this package expand into the sending path.
  • Commodity-dependency signal. A ~32 score with ~25 opportunity indicates a mature, well-understood capability rather than a differentiator. That's a buy/adopt, don't build signal for the IMAP layer: use the library, invest our engineering in ingestion idempotency and routing logic instead of protocol handling. It also means the dependency is thin and replaceable, so adoption risk is low.

When to Consider This Package

Adopt when:

  • The stack is PHP/Laravel and the requirement is reading from arbitrary or customer-supplied IMAP servers, not a single provider.
  • Volume per mailbox is modest and batch latency is acceptable — polling every 1–5 minutes for new messages, not sub-second delivery.
  • We can own the operational surface: a supervised worker, backoff on connection failures, and idempotent processing keyed on UIDVALIDITY + UID so restarts don't double-ingest.
  • Mailbox credentials or OAuth2 tokens can be obtained and refreshed by us; validate the OAuth2 path for Gmail/Microsoft explicitly before committing.
  • ext-imap is available in the runtime. Verify this against the target PHP version — the extension is unbundled in recent PHP releases and may need a PECL/container step, which is a real deployment constraint.

Look elsewhere when:

  • High volume or strict delivery SLAs. IMAP is stateful, servers throttle, and per-mailbox connections don't fan out. Use an inbound webhook provider or a dedicated sync vendor.
  • Deep Gmail/Microsoft integration is the actual requirement (labels, threads, push notifications, calendar). Graph/Gmail APIs beat IMAP-over-OAuth for anything beyond plain message retrieval.
  • Outbound email is in scope — wrong tool.
  • Multi-tenant mailbox sync at scale — Nylas, Merge, or a Graph-based sync service will be cheaper than the ops burden.
  • The team isn't PHP, or we can't staff ongoing mailbox-connection support (credential rotation, provider quirks, rate limits).

Recommendation: adopt behind a thin MailboxReader interface with a spike (2–3 days) against one real shared mailbox to confirm OAuth2, runtime support, and throughput; keep the provider-swap option open.

How to Pitch It (Stakeholders)

For executives: This is an MIT-licensed, mature, actively released library (919 stars, releases through December 2025) that lets us read customer mailboxes directly. It enables the "connect your inbox" and internal mailroom-automation features without paying per-email inbound fees and without shipping email content to a third party — a privacy and compliance win. The risk is operational, not commercial: no license cost, no lock-in, and it sits behind our own interface, so we can swap to a paid inbound provider later if volume outgrows it. Ask: approve a short technical spike, not a platform commitment.

For engineering: Object-oriented and fully tested, covering folders, message retrieval, attachments, flags, and search — it removes roughly one to two weeks of IMAP protocol quirks. Two caveats to design around: the ext-imap dependency and its availability on our target PHP version, and IMAP's stateful, throttled nature. Wrap it in an adapter, run ingestion in a queued worker with backoff, and dedupe on UIDVALIDITY + UID. Keep outbound mail on Laravel's existing mail stack.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
novasa/laravel-language-center
opencage/geocode
adolfoholzer/parameters
livenetworks/ln-starter
shitoudev/permissionmanager
johannesclimacus/laravel-tui
hocvt/seotools
vitalybaev/sypexgeo
amphibee/themosis-ignition
gito-me/fast-excel
frankyso/laravel-ipaymu
geolize-studio/laravel-chile
boomerangui/chat
cgv/localized-resource
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox
pairus/product-data
fayne/laravel-filament-cms-core