YariloMail 2.4.6: one host, Redis Sentinel and per-protocol limits ​

4 November 2026

YariloMail 2.4.6 is a release of the 2.4 stable line. It brings YariloMail to a single Linux or FreeBSD host, adds an optional Redis Sentinel mode, and applies the per-protocol and per-user connection limits operators asked for. Read "Before you upgrade" first: usernames are now lowercased before every lookup, each process reads only its own services entry, and an old hand-written yarilo.yaml stops at start until it is renamed.

New ​

  • A single host. systemd units for every component, a yarilo.target, separate accounts per role and a hardened sandbox, with a .deb spec. The tree builds on FreeBSD, NetBSD and OpenBSD, and the FreeBSD port mail/yarilo builds this release.
  • Unix sockets for the internal services: yarilo-auth, yarilo-warden, yarilo-locks and yarilo-dict listen on unix:/path with a mode and group you set. On a Unix master socket only the delivery proxy may issue sessions.
  • Redis Sentinel mode: the lock service, auth tokens, warden and Redis dicts can follow Sentinel to the master themselves. One address stays the default.
  • auth_username_format: the username is formatted once, before any passdb or userdb is asked, so Bob@Example.com and bob@example.com are one user and one cache entry. The name the client gave is kept as original_user.
  • Connection limits per protocol: mail_max_userip_connections can differ for IMAP, POP3, Submission, LMTP, ManageSieve and JMAP, and the userdb's own per-user limits now apply. A reached JMAP limit answers 429 with Retry-After.
  • JMAP behind a proxy: client_ip_header reads the client address from a header such as CF-Connecting-IP, only from a trusted proxy and only when it is a bare IP address.
  • JMAP without the search service: Email/query answers subject, address and header conditions by reading headers when full-text search is not configured or cannot answer.
  • Threads catch up: a message that was saved without its conversation joins it on its first read.

Fixed ​

  • Lock client: a lock store outage reaches IMAP clients as NO [UNAVAILABLE] instead of a server error, and a release cut off by the outage no longer leaves the session unable to expunge. Measured on a Valkey failover under load: every client error was UNAVAILABLE, and no YariloMail process restarted.
  • METADATA: server annotations no longer appear under INBOX, and GETMETADATA (DEPTH infinity) INBOX (/private) reads the whole scope.
  • Full-text search: a short word in a search is matched as a substring, as IMAP SEARCH requires, instead of being lost or matching neighbours.
  • IMAP QUOTA lists only resources that have a limit, so an account without one no longer looks full.
  • POP3 SCRAM gave two answers to one command; Sieve programs past their timeout no longer hold the call.
  • Shutdown: yarilo-auth, yarilo-warden and the director stop as soon as their connections close instead of always waiting 30 seconds.

Before you upgrade ​

  • Usernames are lowercased before every lookup (auth_username_format: "%Lu"). If your passdb stores names in mixed case and compares them exactly, lowercase them or set %u to keep the 2.4.5 behaviour.
  • One services entry per process. Login proxies read imap_login, imaps_login and so on, backends read imap, pop3 and so on, with no fallback. The old imaps, pop3s, submissions, managesieve_be and jmap_be entries stop the start and name the new one. The Helm chart renders the new entries for you.
  • Outside Kubernetes, internal listeners default to loopback. The chart keeps listening as before.
  • Client Services keep the client address with externalTrafficPolicy: Local. Services that share one MetalLB address must all be set to Cluster.
  • The director moves a domain only above 50 sessions on the busiest backend, so a quiet tag no longer kicks live sessions.
  • Config schema 18 → 29: upgrade the chart and the image together. Pull the new image onto the backend nodes before helm upgrade, and keep room for one more backend pod.

Read the release notes before you run helm upgrade: they list every change that affects an existing configuration.

How it was tested ​

The release image ran a full acceptance run on the stand, then a window against 2.4.5 in the same slot: 2.4.6 was not slower on any storage format. A rollback from 2.4.6 to 2.4.5 on the same store kept mail, ACLs and METADATA readable, and a single-host run on FreeBSD passed on the code of this release.

Get it ​