What’s new

Performance

• New purchases select Backup MX, Email Protection or SMTP Sending, each billed per domain per calendar month. Incoming plans are alternatives; SMTP Sending has its own period.

Security

• Expired SMTP sending does not stop a paid incoming plan. Device credentials may send from other active authorized domains while an anchor domain expires.

Design

• Per-service prices, orders, invoices, renewal reminders and administrator extensions.
• Existing legacy customers, periods, captured prices and routing are preserved.
• SMTP activation still requires administrator approval, enabled device accounts and sender DNS configuration.

Performance

• This fixes the nil-task error observed by the native local probe. The current signing policy is still cached and invoked with the real task.

Security

• Existing keys, selectors, DNS records and authorization checks are retained. The native signing probe and recipient DKIM PASS remain the release acceptance checks.

Design

• The spam filter 3.12 signing chunk explicitly binds its current message task from the vararg supplied by the native callback invoker.
• Regression tests use direct chunk execution with a task argument, matching the observed installed runtime, rather than a named task-wrapper assumption.

Performance

• The policy function is cached within the worker Lua runtime and is reset when spam filter restarts.

Security

• Existing DKIM keys, selectors, public DNS records, ownership bindings and signing eligibility checks are preserved.
• Regression tests execute the configured callback through the spam filter 3.12 task-wrapper contract. Actual DKIM PASS requires one live recipient test after installation.

Design

• The signing condition now calls the customer policy with the current message task and returns signing parameters, instead of returning the policy function itself.

Performance

• Enabling, repeated application and disabling retain distribution comments and restore the original worker limit.

Security

No changes were recorded in this category.

Design

• Disabled sample settings in SMTP service master.cf are now ignored when checking incoming listener conflicts. Both unindented and indented full-line comments are preserved.
• Existing active listener overrides still require review. Long-form overrides with whitespace around braces and equals signs are recognized.
• Installation does not enable DoS or change its numeric limits. Save the intended limits from the administrator panel after installation.

Performance

No changes were recorded in this category.

Security

• Domain DKIM setup now explains the required order: administrator sending approval, an enabled device account authorized for the domain, key creation, public TXT publication and DNS activation.
• Existing multi-domain devices can authorize another domain without separate mailbox credentials. Existing DKIM records, authentication requirements and cleanup controls are retained.

Design

• When sending is approved but no device account exists, customers are directed to Create a new SMTP device account and the affected domain is named.
• Disabled devices, missing approval, unavailable domain verification and changed registration bindings have distinct explanations.

Performance

No changes were recorded in this category.

Security

• DKIM creation and DNS activation now require customer sending approval and an enabled SMTP device account authorized for the domain. The root helper checks current account and registration bindings, so a manually submitted form cannot bypass the restriction.
• Unavailable actions are hidden with an explanation. An existing DKIM key can still be disabled or deleted without sending approval, active device accounts or a fresh domain DNS check.
• Disabling one device does not disable other independently authorized devices for the same domain. Disabling customer approval stops new submissions across all devices.
• Disabling retains the key. Explicit deletion removes the managed signing record and private key; the customer removes its public TXT record separately. The exact DNS name is shown beneath Close in the completion dialog. A DKIM public record does not grant SMTP authentication or relay access.

Design

No changes were recorded in this category.

Performance

No changes were recorded in this category.

Security

• SMTP sending now offers a separate RSA 2048-bit DKIM key and public TXT value for each customer sending domain.
• Signing is enabled after an exact DNS public-key match. Existing provider DKIM records and DMARC policies are retained.
• Only authenticated customer submissions with matching envelope and visible From domains are signed. Incoming and forwarded customer messages are not signed as customer-originated mail.
• Keys bind to the domain owner and registration proof. Repeated creation preserves an existing key; disabling retains it. Private keys are never shown in the portal.
• Existing gateway notification signing is retained. Installation does not enable customer signing or send a test message. Live DKIM PASS must be verified after publishing DNS.

Design

No changes were recorded in this category.

Performance

No changes were recorded in this category.

Security

• Authenticated submission on ports 587 and 465 uses a dedicated cleanup service that preserves the authorized envelope sender.
• Incoming mail keeps the existing sender rewriting path. SRS remains available for redirected mail; authenticated customer sending no longer adopts the gateway bounce domain.
• Preserving the envelope sender allows aligned SPF when the customer domain authorizes the gateway IP. Existing provider sources must be retained in the same SPF record.
• SMTP authorization, recipient quotas, From-domain enforcement, TLS, antivirus and spam checks remain active. This change does not provision customer DKIM keys or weaken DMARC policy.

Design

• A read-only diagnostic checks the live cleanup routes. Existing bounced messages are not automatically resubmitted; customer DNS and inbox acceptance need separate verification.

Performance

• Other callers retain copy-on-normalization behavior. Default policy objects remain independent, and no state or user text is cached.
• Local WSGI comparison shows reduced state-processing cost; server HTTP and mixed-workload validation are still required before claiming 500-user capacity.

Security

• An open root-owned state file may lose its directory link during an atomic publication. Its complete in-flight snapshot is now accepted; the next read opens the new revision. Files with multiple hard links, unsafe ownership, writable permissions or world access remain rejected.
• The same isolated JSON-reader HTTP model is retained for comparable post-update measurements. Production worker count, SQLite mode, DNS, SMTP routes, TLS settings and queues remain unchanged.

Design

• Fresh JSON state already belongs to a single reader. The portal now normalizes that private object without copying every customer and domain again.
• Legacy text replacement order is prepared once at import. Plain ASCII text with no possible legacy replacement skips the unnecessary replacement loop; customer text and HTML attributes retain protection.

Performance

• Only the existing state JSON is root-owned and group-readable by gatepanel. The portal cannot write it. Payment configuration, SMTP credential files and private keys retain their separate protections.
• A read-only diagnostic measures helper-process count and latency. The isolated HTTP experiment now exercises the fresh JSON reader against a private synthetic fixture; it does not grant access to production state.
• Production worker count and SQLite journal mode are unchanged. Full 500-user validation remains in progress.

Security

• No TTL or shared mutable snapshot is used. Atomic state replacements are visible to the next read, including owner changes, account suspension and SMTP approval changes.
• The reader verifies root ownership, regular-file type, non-writable group/other permissions, a trusted directory and bounded content. Symlinks, hard links and malformed content are rejected.
• Writes and privileged operations retain the restricted root helper and revision checks. Legacy deployments with unreadable state can use the previous helper path; invalid or unsafe readable state is an error.

Design

• The portal can read the current root-published state directly, removing a sudo and Python helper launch from each state read.

Performance

• Normal pages skip implementation-name parsing when no replacement is possible. Customer-provided names, script content and URL attributes remain protected. Full customer neutralization includes the payment-provider pass, avoiding repeated HTML parsing.
• The packaged HTTP diagnostic uses an isolated Gunicorn listener, a synthetic database and 500 test tenants to compare two and four sync workers. Production workers, database journal mode, routes, queues and credentials are unchanged by this release.
• Baseline testing reached approximately 4.43-second p95 with nine timeouts at 500 synthetic clients and four workers. Post-update HTTP measurements are required; this release does not certify 500-user capacity.

Security

• Unchanged domain registrations use one bulk owner query instead of one query per domain on each customer page.
• Actual owner changes still reset verification tokens. Concurrent first registrations recheck ownership under a SQLite writer reservation so the registration token stays consistent.

Design

No changes were recorded in this category.

Performance

• Manual delivery accepts up to four ordered IPs or hostnames on one SMTP port. Existing single targets and automatic Backup MX routes are preserved; no fallback is added automatically.
• A separate loopback SMTP service diagnostic verifies native failover using synthetic .invalid mail. Production queues and DNS are not changed by the diagnostic or upgrade. 500-user capacity still requires measured validation.

Security

• Targets are resolved through the gateway resolver and pinned to eligible public IPv4 addresses. Configuration validates every member; a later unsafe or unresolved member is excluded while an eligible fallback can continue.
• All targets share one TLS policy. Verified TLS requires an explicit certificate hostname valid on every target. TLS requirements remain active during failover.
• Multiple recipient probes share a bounded connection pool and deadline. Any acceptance prevents a permanent rejection; unknown recipients are rejected only when every eligible address is covered and all replies explicitly confirm 5.1.1. Partial or uncertain checks continue to queue delivery.
• Adding, removing or reordering a multi-target route, or changing its port, requires the current portal password. Unchanged-route policy saves retain their workflow.
• Native multi-target connection, greeting and STARTTLS waits use Server Settings connection/reply limits. Fast fallback health results publish without waiting for a slow primary.
• All destinations must serve the same domain and recipient directory. Permanent destination rejections remain authoritative; this feature does not synchronize mailboxes.

Design

No changes were recorded in this category.

Performance

• Refresh after success performs a GET and does not repeat the mutation. Domain filtering and clear success notices remain available.
• No queued message is released, deleted or resubmitted by installation. Domain policies, routing and retention remain unchanged.

Security

• Release and Delete now redirect to the quarantine list after a successful operation, removing the stale held-message preview from the URL. A released or deleted message is no longer reread as if it were still held.
• Message identity, arrival time, registration generation, owner and queue age checks remain enforced. A failed or stale operation never becomes a success response.

Design

• Operation failures use a portal warning dialog with Close and a return link. Successful operations remain audited once.

Performance

• Transactional notifications now use the normal SMTP service recipient transport selection. Notifications to a registered gateway domain follow its guarded customer delivery route, avoiding a self-MX loop after a Primary Gateway cutover.

Security

• External recovery contacts keep normal SMTP service routing. Existing destination, ownership, billing and TLS guards are honored for managed domains.
• Rspamd/DKIM integration is preserved. The notification-only after-queue filter override is removed; public SMTP listeners and customer transport maps are preserved.
• Accepted or bounced historical notifications are not automatically resubmitted. No DNS, product pricing, queue retention or SMTP account permissions change.

Design

• The private notification listener stays bound to 127.0.0.1:10027. Closed public relay rules and notification cleanup remain unchanged.

Performance

• Incoming domains can now use Backup MX or Primary Gateway. Existing domains retain Backup MX.

Security

• Mode changes require confirmation and the current account password. DNS is never changed automatically.
• TXT ownership, billing, safe destination checks and closed-relay restrictions remain enforced. Unresolved or unsafe Primary Gateway destinations temporarily pause new acceptance.
• Offline destinations queue accepted mail. Live recipient probes, configurable TLS, Rspamd/ClamAV policies and optional quarantine retain their existing behavior.
• Outbound SMTP account permissions and pricing are independent of incoming mode. Existing queues and Backup MX settings are preserved. BATV is excluded.

Design

• Primary Gateway requires gate.securawall.com as the only published MX and a manually configured real delivery hostname or IP. Public MX lookup cannot be the delivery route in this mode.
• This configuration feature does not certify 500-user capacity or create a separate commercial service plan.

Performance

• Per-listener SMTP worker caps and concurrent connections per host are enforced by SMTP service.
• DoS counters are bounded, held in memory and reset on service restart. Loopback notifications are exempt. Policy or counter failure temporarily defers new work.

Security

• Maximum recipients per message is enforced before DATA. SMTP device authorization and closed-relay protections remain active.

Design

• Administrator Server Settings now includes separate incoming and submission flood controls. New controls are off by default and do not change durable customer quotas.
• MAIL attempts per connection and per-host per-minute message rates are tracked by the private policy service. Connections per host have a separate one-second window.
• Limits apply to source IPs; shared NAT addresses share budgets. These controls do not replace upstream volumetric DDoS protection.
• BATV is not included in these controls.

Performance

No changes were recorded in this category.

Security

• Server defaults and owner-scoped domain overrides now include independent invalid HELO and missing rDNS rejection switches, plus selectable DKIM verification.
• Explicit DKIM actions replace the matching legacy score. No additional action does not bypass other spam, SPF/DMARC, antivirus or content checks.
• Temporary DKIM errors can defer mail for retry; they cannot be configured as permanent rejection.
• Authenticated SMTP device sending and local notifications bypass incoming identity enforcement; outbound DKIM signing is retained.
• Mixed recipient policies use the strictest enabled setting for the whole SMTP transaction. Strict rejection occurs after DATA, before queuing.
• Existing deployments retain their scoring behavior; HELO and rDNS rejection are off by default. SMTP DoS controls and BATV are separate upcoming stages.

Design

• Invalid signatures, unsigned messages, permanent key or format errors and temporary verification failures have separate actions.

Performance

• All device accounts and assigned sender domains share a customer budget. Domain and device ceilings are also checked in the same transaction.
• Behavior-based automatic suspension, outbound queue isolation, complaint handling, dedicated IP pools and Primary Gateway remain further development.

Security

• Approval is checked at authentication, RCPT and DATA. Disabling approval blocks new submissions; already queued messages are not automatically held.
• The customer Account Sign-in security card is removed; existing two-step verification settings remain intact.

Design

• New customers require administrator approval for SMTP sending. Administrators set recipient budgets per minute, hour and day; customers cannot raise their own sending limits.
• UTC-aligned quota counters persist across service restarts. An unavailable counter store temporarily defers sending; it never grants an unlimited fallback.
• Existing enabled SMTP accounts are migrated with approval retained and a Review required notice. Administrators should review their inherited quotas.

Performance

• No order records, billing dates, credentials or mail queues are deleted by this interface change.

Security

• SMTP authentication sockets are stopped before their service during upgrade, preventing socket activation while files are being replaced.

Design

• Customer My orders opens with the service period cards, followed by online purchases. Empty legacy request tables are hidden.
• Existing manual requests remain available in a collapsed Earlier order requests section with concise columns and their original controls. Admin request management is unchanged.

Performance

No changes were recorded in this category.

Security

• Manual DNS cooldown uses its own atomic, owner-scoped timestamp. Background checks no longer prevent a manual request.

Design

• Service period cards show the domain first. SMTP account actions share a row on desktop and stack on mobile. Domain editor fields are stacked, with grouped save/reset actions.
• A repeated manual request displays the standard dialog with the domain, remaining wait and Close, while keeping domain settings available.
• Domain statistics and My orders shortcuts are removed from the domain editor. Overview domain Statistics shortcuts are removed; the navigation page remains available.
• Mail routes, credentials, thresholds, quotas and MX modes are unchanged.