Laravel Sieve Laravel Package

Product Decisions This Supports

• Server-side email filtering / rule management features. This package wraps the ManageSieve protocol (RFC 5804) and Sieve scripting (RFC 5228), letting a Laravel app list, read, upload, activate, and delete filter scripts on a user's mail server, and build filter rules programmatically. It directly enables roadmap items like "user-defined inbox rules," "vacation auto-reply," "forward/redirect rules," "flag or file messages by sender/subject," and "reject with custom message."
• Build vs. buy on mail-rule infrastructure. The cheap path for inbox rules is to implement filtering inside your own application at delivery time — viable only if you control the MTA or ingest pipeline. If mail lands in a third-party or customer-owned mail server and rules must execute there (works while the mailbox is offline, before your app sees the message), you need Sieve. This package is the shortest credible route to that capability in Laravel; the alternative is hand-rolling a ManageSieve client plus a Sieve script generator, which is a multi-week protocol-and-escaping exercise with real consequences when it goes wrong.
• Hosting / control-panel and multi-tenant mail products. The natural fit: per-mailbox script management for many tenants, where the panel writes and activates scripts on behalf of end users. Also relevant if you resell or manage mail for customers and want to offer filtering without owning the mail stack.
• Feature scoping: where filtering actually runs. A useful forcing question for the roadmap — "do rules need to run when our app is down, or only when our app processes mail?" If the former, Sieve is the answer and this package is in scope. If the latter, a database-backed rules engine plus your own worker is simpler, testable, and doesn't depend on a mail server's Sieve support.
• Compliance and user-control narratives. Vacation responders, blocklists, and forwarding rules are frequently requested by support and are often part of enterprise procurement checklists; a Sieve-backed implementation lets you ship them without touching the mail server config per customer.
• Not a decision driver: the Sieve feature language is expressive but not a full programming environment, and ManageSieve is a separate service that must be enabled per mail server. Budget for ops verification on every mail backend you support.

When to Consider This Package

Adopt when most of the following hold:

• Your product must write filtering rules onto the mail server itself, and the mail servers you target expose ManageSieve (Dovecot, Cyrus, many hosted IMAP providers; commonly port 4190 or 2000, often TLS-only and sometimes firewalled off by default).
• You are on — or are prepared to move to — PHP 8.5 and Laravel 13. This is the headline of v2.0.0 and the main gate: the release pins to the newest PHP and Laravel majors rather than widening support, so v2.0.0 is effectively a "latest-stack only" package. If you are on Laravel 10/11/12 or PHP 8.2–8.4, you stay on v1.2.0 or skip the package.
• You want Laravel-native ergonomics — config file, service provider, facade, and a fluent rule builder — rather than a raw protocol library.
• Your filter needs are in the standard Sieve/ManageSieve envelope: conditions on headers, size, address parts; actions like fileinto, redirect, reject, keep, vacation, stop. Extensions beyond that (e.g. body tests, regex, variables, spam/test integrations) depend on server support and are not something to assume.
• You can live with a small, single-maintainer-ish package (ans-group, a UK hosting/cloud provider; v2.0.0 added a first-time contributor). It is a thin, well-bounded wrapper, so the risk is mostly "is it maintained?" rather than "will it corrupt my data" — but pin the version and read the changelog on every upgrade.

Look elsewhere or build in-house when:

• You don't control or can't reach the mail server. No ManageSieve endpoint, no credentials, no port access — the package has nothing to talk to. Many SaaS mail providers do not expose ManageSieve to tenants at all; confirm with your provider before committing.
• You are not on Laravel 13 / PHP 8.5 and cannot upgrade soon. v2.0.0's support floor is a hard blocker, not a soft preference.
• You need filtering only inside your own pipeline. A rules table plus a queue worker is easier to test, version, and debug than a remote script push, and avoids per-mailbox protocol round-trips.
• You need vendor-backed SLAs or a large maintainer base. This is not a commercially supported product; if mail filtering is a contractual commitment, plan for the ability to fork the ManageSieve client in-house.
• You need deep Sieve extension coverage or script round-tripping of hand-written user scripts. Verify the package preserves scripts it did not generate before promising "edit your rules directly."

How to Pitch It (Stakeholders)

For executives (one paragraph). We are evaluating ans-group/laravel-sieve, a small open-source Laravel component that lets our application read and write mail-filtering rules directly on customers' mail servers using the standard Sieve protocol. It is the fastest route to shipping inbox rules, vacation replies, and forwarding as first-class product features, instead of building and maintaining a mail-protocol client ourselves. Cost is effectively zero in licence terms; the real costs are (a) an engineering dependency on a small open-source project we may need to fork, and (b) an operational dependency on each mail server having Sieve enabled and reachable. The new v2.0.0 release is a compatibility release, not a feature release: it adds PHP 8.5 and Laravel 13 support and, by implication, raises our minimum runtime. That makes the decision a scheduling question as much as a technical one — the capability is sound, but we should adopt it only when we are ready to be on the latest PHP/Laravel stack.

For engineering leads. The package is a focused ManageSieve client plus a fluent Sieve-script builder, wired into Laravel via config, a service provider, and a facade. It is not a rules engine and does not persist anything — we own the storage of who has which rule, and the package owns the conversation with the mail server. v2.0.0 is a breaking major whose only stated change is the PHP 8.5 / Laravel 13 floor; treat it as a platform-upgrade gate, not a feature win. Recommended posture: prototype against one real Dovecot/Cyrus target early to confirm port reachability, TLS, and auth; pin the version; keep our own abstraction over the facade so the ManageSieve layer is swappable; and validate script escaping and error handling against hostile input (subjects and addresses containing quotes, newlines, non-ASCII) before exposing rule editing to end users. If we cannot commit to Laravel 13 / PHP 8.5 in the same window, stay on v1.2.0 and revisit — do not adopt v2.0.0 speculatively.