Important Changes

External images in mail load directly

HTML mail is now displayed entirely by the browser: the middleware hands the message over unchanged, and App Suite UI cleans and renders it. The visible part is external images — the pictures a newsletter pulls from the sender's server — which now load in the browser after the usual prompt to allow them, instead of through a server-side proxy.

Why the proxy had to go. A central proxy fetches images for all users from one server address, which content delivery networks such as Cloudflare or Akamai read as bot traffic and block — so images stop loading for an entire deployment at once. A browser fetching its own images looks like ordinary web traffic. That is inherent to proxying, not a defect of ours: Apple Mail and Outlook fetch directly too, and Gmail gets away with proxying only because the delivery networks effectively whitelist Google's servers.

Security is not affected — it is handled in a better place. Mail is displayed in an isolated frame under a strict Content-Security-Policy, which blocks the same attacks regardless of how images load. It also closes a subtle phishing trick the proxy had been masking: a message could reference an external font or stylesheet whose response demands a password, making the browser pop up its native sign-in dialog — with wording the attacker chooses — over App Suite, as though App Suite were asking the user to log in again. The message itself looks harmless; the trick lives in the network response, which is why refusing the load is the fix and more cleaning is not. The same isolation now covers replies, drafts, signatures and previews, so no image loads before someone asked for it.

One visible side effect: external fonts are blocked too, so a sender's brand font falls back to a system font. Administrators who need a particular font can allow-list a trusted source via io.ox/mail//csp/fontSrc.

Nothing has been taken away. The proxy was built as a security measure — it kept the browser from contacting the sender's server, which is also how it masked the attack above. Hiding the recipient's IP address was a by-product, read as a privacy feature of its own only later. With the security job now done where it belongs, that by-product is all the proxy still contributes — and it never covered what is usually meant by privacy in mail: a tracking pixel confirms that a message was opened the moment it loads, proxied or not. The real protection is blocking images from senders you do not trust, and that is unchanged.

Switching the proxy back on. Configure the image proxy in the middleware and set io.ox/core//features/proxy in the UI — that setting only enables use of the proxy, it does not configure it. Expect images to fail more often; when they do, App Suite reports how many could not be shown and offers to load them directly for that one message.

Further details are available in the email security documentation.

Database

SCR-1853

Summary: New table deputy_mail_acl_baseline holding the mail ACL baseline of a deputy permission

Effective: 8.53.242 and later; also delivered in 8.53.243

In order to record a deputy permission's mail ACL baseline reliably, the mailboxes on which the deputy already held an ACL before the permission was granted are now kept in the new table deputy_mail_acl_baseline instead of in the granting user's INBOX metadata entry /shared/vendor/vendor.open-xchange/deputydir-<deputyId>.

The baseline is now recorded once, at the first grant. It was previously re-captured on every grant, so a mailbox outside the permission's folder list that had only received its ACL through the grant itself, typically a subfolder Dovecot inherits from INBOX, counted as pre-existing and kept the deputy's ACL when the permission was revoked.

CREATE TABLE deputy_mail_acl_baseline (
  cid INT4 UNSIGNED NOT NULL,
  uuid BINARY(16) NOT NULL,
  user INT4 UNSIGNED NOT NULL,
  account INT4 UNSIGNED NOT NULL DEFAULT 0,
  fullname VARCHAR(256) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  rights VARCHAR(32) CHARACTER SET latin1 NOT NULL DEFAULT '',
  PRIMARY KEY (cid, uuid, account, fullname),
  KEY userId (cid, user)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

Deputy permissions granted before this change are not migrated; their baseline is still read from the metadata entry, and both locations are cleared when the permission is revoked. The update task only creates the table and does not touch existing rows. No operator action is required.