Vexim Web Plugin Rspamd Core Laravel Package

Technical Evaluation

Architecture fit. Note first that this is not a Laravel package in the conventional sense: vexim-web-plugin-rspamd-core is a plugin for Vexim, the legacy procedural PHP mail-administration front end for Exim/Dovecot estates. There is no service provider, no config publishing, no Eloquent models, no Composer-first distribution story. Its architecture assumes the Vexim schema, Vexim's session/auth model, and a co-located Rspamd instance reachable over its controller API. Fit inside a Laravel application is therefore indirect: you either operate Vexim alongside your Laravel estate and consume this plugin's whitelist capability there, or you lift the Rspamd whitelist client logic into a native Laravel service (HTTP client + queued jobs) and drop the plugin wrapper. The former is a day-one option, the latter is the strategically coherent one.

Integration feasibility. The v1.0.2 change is narrow and functional: the Rspamd whitelist API now recognises DMARC-verified From addresses. In practice this means mail whose From domain passes DMARC alignment is auto-admitted to the whitelist path rather than falling through to scoring, which reduces false positives on legitimate bulk/transactional senders. Feasibility is high because the change is additive — no schema migration, no config surface change, no API contract break. The realistic integration work is not the plugin itself but the surrounding plumbing: Rspamd API reachability, credential handling, and a policy for how whitelist entries are created, expired, and audited.

Technical risk. Three risks dominate. First, behavioural risk: a patch version bump (1.0.1 → 1.0.2) hides a filtering policy change. Silently widening the whitelist is a security-adjacent decision — a whitelist is only as trustworthy as the DMARC verification it depends on, and DMARC alignment fails routinely on legitimate forwarders (mailing lists, ticketing systems) unless ARC is honoured. Expect both over-admission and under-admission in the first weeks. Second, implementation risk: whether "DMARC-verified" is derived from a trusted Authentication-Results header written by your own MTA, or evaluated in-process, determines whether the check is spoofable. This is the single most important thing to verify before enabling. Third, supply-chain risk: a single-maintainer repository (one contributor on this PR) with a very small release history and no visible CI/test posture.

Key questions. (1) Is DMARC verification sourced from a trusted local Authentication-Results header, or recomputed from DNS? (2) Are ARC-sealed forwarded messages handled? (3) What is the whitelist entry TTL and eviction policy — does an auto-added entry persist indefinitely? (4) Which Rspamd and PHP versions are supported, and is there a compatibility matrix? (5) Is there any audit trail of auto-whitelisted senders for post-incident review? (6) Is there a test suite, and does it cover the DMARC branch added here?

Integration Approach

Stack fit. Treat this as a companion service, not a library. Your Laravel app should not require it; instead, if you need whitelist automation inside Laravel, implement a thin Rspamd API client (Illuminate\Support\Facades\Http, retries, circuit breaker) and reuse the plugin only as a reference implementation for endpoint shapes and payloads. If you are already running Vexim, install the plugin there and let Laravel own the surrounding orchestration.

Migration path. Do not jump to enforcement. Run v1.0.2 in a shadow configuration for two to four weeks: log what would have been whitelisted, compare against your existing allowlist and against actual spam-trap outcomes, then promote. Because this is a patch bump, pinning v1.0.1 is a viable rollback with no data migration — confirm first that the plugin does not write new whitelist rows in a format v1.0.1 cannot read.

Compatibility. Validate against your exact matrix before rollout: PHP minor version, Vexim release, Rspamd version and whether its controller API is bound to localhost with an auth token, and MySQL/MariaDB schema drift if you have customised Vexim tables. The DMARC branch may assume an Authentication-Results header format produced by a specific MTA — confirm your Exim configuration writes it, and that it is stripped on ingress from untrusted sources.

Sequencing. (1) Fork and pin at v1.0.2 with a recorded upstream SHA. (2) Stand up a staging Rspamd + Vexim pair and replay a corpus of real messages, including known forwarding/list traffic. (3) Enable DMARC recognition in log-only mode. (4) Review deltas with the mail ops owner and set an explicit allow/deny decision. (5) Enable enforcement with a named rollback owner and a 24-hour watch window. Parallel-track the decision on whether to replace the plugin with a native Laravel client.

Operational Impact

Maintenance. Low bus factor is the headline. One maintainer, a repository with three tagged releases, and no evidence of CI. Budget for an internal fork you control rather than upstream dependence; the delta here is a few hundred lines at most, so fork cost is trivial and optionality is high.

Support. Community-only, no SLA, no vendor. Escalation path is the GitHub issue tracker. For a component that sits on the mail path and can affect deliverability, this is acceptable only because the blast radius is containable — a whitelist regression degrades filtering, it does not stop mail flow, provided you never make the whitelist lookup a hard dependency of delivery.

Scaling. Two cost centres. Per-message DMARC evaluation (DNS lookups, signature verification) adds latency and resolver load — Rspamd typically caches DMARC results, so verify caching is effective and that the plugin is not bypassing it with its own lookups. Second, whitelist lookups: if each check hits the Vexim database, you have a per-message query on the hot path. Prefer Rspamd maps or Redis with a periodic sync from the authoritative store.

Failure modes. (a) Rspamd API unreachable — must fail open for delivery, closed for whitelist admission; make this explicit in config. (b) Spoofed or attacker-injected Authentication-Results header — catastrophic, bypasses all filtering for a forged From domain. (c) Forwarded/list mail failing DMARC alignment — legitimate mail not whitelisted, i.e. status quo behaviour, tolerable. (d) Whitelist poisoning via a compromised but DMARC-passing sender — mitigated only by entry expiry and monitoring. (e) Silent divergence after a future upstream patch release.

Ramp-up. The integration code is a day's work. The domain knowledge is the real cost: whoever owns this needs working fluency in SPF, DKIM, DMARC alignment, ARC, and Rspamd's scoring pipeline to judge whether the v1.0.2 behaviour is correct for your traffic. Budget one to two weeks for an engineer with mail-auth background, materially more without it. Recommend a single named owner from the mail/platform side, not the Laravel application team.