v2.4.4

A patch release of the 2.4 stable line. Upgrade promptly if clients send mail through the Submission login: in 2.4.3, after AUTH, every command got the previous command's reply, so no conforming client could send (#2271, see Fixed). If you list ihave in sieve_extensions, see Security. It also completes the JMAP submission-side objects (EmailSubmission, Identity, VacationResponse, SieveScript) and brings Sieve include parity.

Before you upgrade

These change what an existing configuration or rollout does. Read them first.

• general.xclient.trusted_nets defaults to empty (#2286). It used to be 127.0.0.1/32, 10.0.0.0/8. A ConfigMap rendered by the chart writes the list your values give; if your values never set it, the new default applies and no proxy's forwarded client address is trusted. Set the proxies' networks if you use XCLIENT. A warning at load names every listener with xclient_protocol: true while the list is empty. XCLIENT is now advertised in EHLO/LHLO only to a peer inside the list.
• Global before/after Sieve scripts are checked at load (#2300). sieve_global_before / sieve_global_after and imapsieve_global_before / imapsieve_global_after are now held to sieve_extensions plus the new sieve_global_extensions. Before, they were not checked at all. One that uses an extension in neither list is logged (global script uses a forbidden extension, skipping) and left out. Add what such scripts need to sieve_global_extensions.
• ihave answers from the whitelist (#2297). A user's script that relied on require "ihave" to use an extension sieve_extensions does not list now has that block skipped, or is refused at upload if it uses the extension outside an ihave block.
• Config schema 10 → 17. Upgrade the chart and the image together; a binary newer than its ConfigMap names the defaulted settings in a warning at start.
• Pull the new image onto the backend nodes before helm upgrade, and keep room for one more backend pod, as for 2.4.3. See DEPLOYMENT, "Upgrading the backend StatefulSet".

Security

• require "ihave" bypassed the sieve_extensions whitelist (#2297). With ihave in sieve_extensions, a user's script could use every extension of the build, vnd.yarilo.pipe and vnd.yarilo.execute included (their programs still limited to the configured directories), at delivery, in imapsieve and through ManageSieve and JMAP uploads. Only installations that had added ihave to sieve_extensions were exposed; the default list does not include it. Fixed: ihave answers from the whitelist, a block under a refused extension never runs, and require "ihave" opens nothing else.

New

• JMAP submission objects (#713). EmailSubmission (/get, /set, /query, /changes) and Identity over the Submission relay (#2273); records kept for jmap_submission_ttl_seconds (default 86400). The identities are the login address and the new userdb field identity_aliases (space- or comma-separated, one more column of user_query); without it a JMAP client has only the login address to send as. VacationResponse as the managed Sieve script, so ManageSieve and JMAP see one vacation (#2285). SieveScript (RFC 9661) over the ManageSieve store, with SieveScript/validate (#2269). Creation ids resolve across the calls of a request, and createdIds is returned (#2275).
• Submission relay as a master (#2272). submission_relay_master_user logs in to the relay as a master with the user as authzid, so the relay judges the real sender; submission_relay_user expands %u; the chart takes the relay password from a Secret (password_secret_ref). submission_relay_ssl_ca names a PEM file the relay's certificate is verified against (empty: the system roots).
• Sieve. include :global reads sieve_global, and the chart mounts sieve.sieve_global_scripts there (#2283). sieve_global_extensions names extensions only the administrator's scripts may use (#2290). LMTP takes ORCPT without DSN and lmtp-login passes it on, for sieve_vacation_use_original_recipient (#2280).
• ManageSieve quotas (#2268, #2269). sieve_max_num_scripts, sieve_max_storage, HAVESPACE and the RFC 5804 quota response codes.

Fixed

• Submission login (#2271). After AUTH, the backend's EHLO reply reached the client as the reply to its next command, and every later command got the previous one's reply. The preamble now carries the HELO domain only, drops CR/LF/TAB from every field, and the login refuses a backend reply that does not end in 250.
• Sieve include (#2282). include did not run at delivery or in imapsieve; it now runs the user's own scripts in both.
• Sieve vacation (#2277). Replies only to mail addressed to the user, honours :addresses, :mime, the default subject, In-Reply-To / References, and the period bounds, and skips list, auto-submitted and system mail. Nine new keys, all under sieve::
  • sieve_vacation_min_period / _max_period / _default_period: seconds, defaults 86400 / 5184000 / 604800, 0 = no bound.
  • sieve_vacation_default_subject / _default_subject_template: default "". A reply without :subject gets "Auto: ", or the template with %{subject}; a message with no subject gets the default subject ("Automated reply" when empty).
  • sieve_vacation_check_recipient (default true): reply only to mail naming the user, or :addresses, in To/Cc/Bcc/Resent-*.
  • sieve_vacation_use_original_recipient (default false): the LMTP ORCPT counts as the user's address. Only a relay that sends ORCPT without DSN gives one; Postfix does not.
  • sieve_vacation_send_from_recipient (default false): the reply's envelope sender is the recipient instead of <>.
  • sieve_vacation_to_header_ignore_envelope (default false): the reply's To is the first address in Sender/Resent-From/From, not the one that matches the envelope sender.
• Helm: imapsieve scripts in the co-located backend (#2292). sieve.imapsieve_scripts reached no container in the default topology; they are now mounted in the imap container of the backend StatefulSet.
• Director flush hook (#2293). A hook descendant that escaped the process group could be reported as a plain timeout; the escape is now read on the monotonic clock.
• JMAP (#2270). existingId is read from the call's starting index.

Operations

• SECURITY.md and the site say who #2297 exposed; there is no separate advisory (#2299).