Merge pull request 'Point links at the new git host' (#13 ) from fix/links-after-move into main

Point links at the new git host
GitHub went dark with the account suspension on 2026-09-20 and GitLab was retired on 2026-09-22, so links to either no longer resolve. Repository, file, release and download links now point at git.coffeylabs.org, images at registry.coffeylabs.org, and old GitHub issue and pull request links at coffey-labs/ihasmail-github-archive, whose numbers match GitHub's.
2026-09-22 16:09:55 +00:00 · 2026-09-22 09:02:57 -07:00 · 2026-09-22 13:58:09 +00:00 · 2026-09-22 06:45:35 -07:00 · 2026-09-22 00:52:10 -07:00 · 2026-09-21 23:20:47 -07:00
23 changed files with 846 additions and 29 deletions
@@ -74,7 +74,7 @@ APP_NAME=ihasmail
 # asks whoever runs a modified version to offer *that* version's source -- so if
 # you have patched it, point this at your own tree. Shown on the sign-in page
 # and in Settings > About.
-SOURCE_URL=https://github.com/Coffey-Labs/ihasmail
+SOURCE_URL=https://git.coffeylabs.org/coffey-labs/ihasmail

 # ---- Settings this installation decides (all optional) ----
 #
@@ -0,0 +1,170 @@
+# CI on the self-hosted Gitea, ported from .gitlab-ci.yml during the move off
+# GitLab (2026-09-22). Gitea reads .gitea/workflows and ignores .github/ once
+# this directory exists; .github/workflows stays as it was for GitHub.
+#
+# Every job runs in an image pinned by digest (tag in the trailing comment),
+# and the only action used is coffey-labs/actions/checkout pinned by SHA. The
+# instance resolves short `uses:` against itself, never GitHub, so nothing
+# unreviewed can be pulled in. Read the comment for the version; the digest is
+# what runs. Do not "simplify" one back to a bare tag.
+#
+# Jobs run on the runner's `ci-net` network and clone from Gitea's internal
+# address, never through the Cloudflare-proxied public name, which caps
+# request bodies at 100 MB. Images go to the registry's own DNS-only name
+# (vars.REGISTRY, an org variable).
+#
+# The weekly release is its own workflow, weekly-release.yml.
+name: ci
+
+on:
+  push:
+    branches: [main]
+    tags: ['**']
+  pull_request:
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  # -------------------------------------------------------------- test ------
+  node:
+    runs-on: light
+    container:
+      image: node:26-bookworm-slim@sha256:582460f614631b59b824ac6020533b9bf339c7fdf3a6d7db31abb6b4065f0212 # 26-bookworm-slim
+    env:
+      NPM_CONFIG_CACHE: ${{ github.workspace }}/.npm
+    steps:
+      # version.test.ts shells out to git to resolve a build version, and the
+      # slim image ships without it; the checkout action installs it when it
+      # is missing, so it is there for the tests too. Full history, because
+      # the version is computed from it.
+      - uses: coffey-labs/actions/checkout@fab0c4d45e0162963965f1555df27b7bed5e20ec
+        with:
+          fetch-depth: 0
+      # config.test.ts chmods a directory to 0555 and expects the write to be
+      # refused. Root ignores the permission bits, so as root that assertion
+      # can never hold. The tests run as the image's unprivileged `node` user
+      # for that reason; -p keeps the environment.
+      #
+      # imageproxy.test.ts needs IPv6 as well, which is not set here but on the
+      # runner: jobs run on the `ci-net` docker network, created with --ipv6.
+      # Without a non-loopback IPv6 address on the container, getaddrinfo's
+      # AI_ADDRCONFIG drops ::1 from the results entirely, localhost resolves
+      # to IPv4 only, and the test's control case connects to a port nothing
+      # is listening on. That is a runner property, so it cannot be fixed from
+      # this file -- if these tests ever fail again with ECONNREFUSED on
+      # 127.0.0.1, check that the runner still puts jobs on an IPv6-enabled
+      # network.
+      - run: chown -R node:node "$GITHUB_WORKSPACE"
+      - run: su node -p -c "npm ci --ignore-scripts"
+      - run: su node -p -c "npm run typecheck"
+      - run: su node -p -c "npm test"
+      - run: su node -p -c "npm run build"
+
+  # ------------------------------------------------------------- build ------
+  # Proves the Dockerfile still builds on every change, without pushing. The
+  # equivalent of ci.yml's final `docker build -t ihasmail:ci .` step. The
+  # Dockerfile builds everything itself, so nothing is handed over from the
+  # node job; `needs` only keeps the order.
+  docker-build:
+    if: ${{ !startsWith(github.ref, 'refs/tags/') }}
+    needs: [node]
+    runs-on: docker
+    container:
+      image: docker:28-cli@sha256:625d9431a9f54c5a2bc90f24f0e1c3d55b1349fd857dd85035f98c2c9acbdd4d # 28-cli
+      volumes:
+        - /var/run/docker.sock:/var/run/docker.sock
+    steps:
+      - uses: coffey-labs/actions/checkout@fab0c4d45e0162963965f1555df27b7bed5e20ec
+      - run: |
+          tag="ihasmail:ci-$(echo "$GITHUB_SHA" | cut -c1-8)"
+          docker build -t "$tag" .
+          docker image rm "$tag"
+
+  # ----------------------------------------------------------- publish ------
+  # Tag-driven. GitHub needed a release -> publish workflow_call chain because
+  # a release cut with GITHUB_TOKEN raises no event -- and Gitea behaves the
+  # same way, which is why weekly-release.yml cuts its release with
+  # RELEASE_TOKEN: a tag made with that token is an ordinary push, and starts
+  # this workflow.
+  #
+  # The version the image is built with, computed the way publish.yml did it:
+  # scripts/version.mjs, which needs node and the full history. The build is
+  # *told* the real form (IHASMAIL_VERSION, what About and /api/health
+  # report); the Docker tag gets the same string with '+' turned into '-',
+  # because a tag may not contain '+'. Leaving the build arg out would ship an
+  # image reporting itself unversioned -- which is exactly what
+  # version.test.ts calls looking wrong.
+  version:
+    if: ${{ startsWith(github.ref, 'refs/tags/') }}
+    runs-on: light
+    container:
+      image: node:26-bookworm-slim@sha256:582460f614631b59b824ac6020533b9bf339c7fdf3a6d7db31abb6b4065f0212 # 26-bookworm-slim
+    outputs:
+      version: ${{ steps.v.outputs.VERSION }}
+      docker_tag: ${{ steps.v.outputs.DOCKER_TAG }}
+    steps:
+      - uses: coffey-labs/actions/checkout@fab0c4d45e0162963965f1555df27b7bed5e20ec
+        with:
+          fetch-depth: 0
+      - id: v
+        shell: bash
+        run: |
+          V="$(node scripts/version.mjs)"
+          echo "VERSION=$V" >> "$GITHUB_OUTPUT"
+          echo "DOCKER_TAG=${V/+/-}" >> "$GITHUB_OUTPUT"
+          echo "VERSION=$V DOCKER_TAG=${V/+/-}"
+
+  # arm64 is built under QEMU on this amd64 host, not on a native runner as
+  # GitHub's free `ubuntu-24.04-arm` did. It is slow -- tens of minutes for the
+  # npm install and Vite build through instruction translation -- which is
+  # tolerable for a weekly tag and would not be for every push. That is why
+  # this job is tag-only. If arm64 ever starts timing out, the fix is an arm64
+  # runner, not dropping the platform: TrueNAS and Unraid users pull it.
+  #
+  # The push logs in with PACKAGE_TOKEN (jcoffey-dev, write:package): Gitea's
+  # per-job token is refused by the container registry. The registry hands out
+  # its push tokens from its own name, so unlike on GitLab nothing here has to
+  # be pointed at a public address.
+  publish:
+    if: ${{ startsWith(github.ref, 'refs/tags/') }}
+    needs: [node, version]
+    runs-on: docker
+    container:
+      image: docker:28-cli@sha256:625d9431a9f54c5a2bc90f24f0e1c3d55b1349fd857dd85035f98c2c9acbdd4d # 28-cli
+      volumes:
+        - /var/run/docker.sock:/var/run/docker.sock
+    env:
+      DOCKER_BUILDKIT: "1"
+      REGISTRY: ${{ vars.REGISTRY }}
+      IMAGE: ${{ vars.REGISTRY }}/${{ github.repository }}
+      VERSION: ${{ needs.version.outputs.version }}
+      DOCKER_TAG: ${{ needs.version.outputs.docker_tag }}
+      PACKAGE_TOKEN: ${{ secrets.PACKAGE_TOKEN }}
+    steps:
+      - uses: coffey-labs/actions/checkout@fab0c4d45e0162963965f1555df27b7bed5e20ec
+      - run: |
+          test -n "$REGISTRY" && test -n "$VERSION" && test -n "$DOCKER_TAG"
+          test -n "$PACKAGE_TOKEN" || { echo "PACKAGE_TOKEN secret is not set on this repository" >&2; exit 1; }
+          echo "$PACKAGE_TOKEN" | docker login -u jcoffey-dev --password-stdin "$REGISTRY"
+          docker run --privileged --rm tonistiigi/binfmt --install arm64
+          docker buildx create --use --name gitea-builder --driver docker-container || docker buildx use gitea-builder
+      - run: |
+          docker buildx build \
+            --platform linux/amd64,linux/arm64 \
+            --build-arg IHASMAIL_VERSION="$VERSION" \
+            --provenance=false --sbom=false \
+            --tag "$IMAGE:$DOCKER_TAG" \
+            --tag "$IMAGE:latest" \
+            --push .
+          docker buildx imagetools inspect "$IMAGE:$DOCKER_TAG"
+      # Gitea keeps a container package on its owner; linking it shows it on
+      # the repository's Packages tab. Idempotent.
+      - run: |
+          apk add --no-cache -q curl
+          curl -fsS -o /dev/null -X POST -H "Authorization: token $PACKAGE_TOKEN" \
+            "$CI_SERVER_INTERNAL/api/v1/packages/${GITHUB_REPOSITORY%%/*}/container/${GITHUB_REPOSITORY#*/}/-/link/${GITHUB_REPOSITORY#*/}" \
+            || echo "package already linked (or link refused); not fatal"
+      - if: always()
+        run: docker logout "$REGISTRY" || true
@@ -0,0 +1,101 @@
+# Weekly release, ported from the weekly-release job in .gitlab-ci.yml (itself
+# a port of .github/workflows/release.yml): cut a release once a week, but
+# only when there is something in it. The decision is unchanged -- count the
+# commits on main since the newest published release, and skip the week if
+# there are none or if the tag already exists (the version comes from the
+# commit, so an unchanged commit is an existing tag).
+#
+# Mondays 09:17 UTC, the same odd minute as before. Run it by hand from the
+# Actions tab (workflow_dispatch); dry_run defaults to true, so a manual run
+# shows the decision and stops unless you untick it.
+#
+# SIDE-BY-SIDE PERIOD: until the GitLab cutover, GitLab's own schedule is
+# still live and still cuts the real release, and its tags reach this copy
+# through the sync. Two releasers would race to create the same tag, so this
+# workflow only ever dry-runs unless the variable RELEASE_LIVE is '1'. Set
+# RELEASE_LIVE=1 (repo or org Actions variable) at cutover, when GitLab's
+# schedule is switched off -- not before.
+#
+# Reads use the job's own token. The release -- and with it the tag -- is
+# created with RELEASE_TOKEN (jcoffey-dev, write:repository), because a tag
+# Gitea creates for the job token raises no event (checked 2026-09-22), and
+# the tag has to start ci.yml's version and publish jobs.
+name: weekly-release
+
+on:
+  schedule:
+    - cron: '17 9 * * 1'
+  workflow_dispatch:
+    inputs:
+      dry_run:
+        description: Show the decision and stop
+        type: boolean
+        default: true
+
+# One at a time: two overlapping runs would race to create the same tag.
+concurrency:
+  group: weekly-release
+  cancel-in-progress: false
+
+jobs:
+  weekly-release:
+    runs-on: light
+    container:
+      image: node:26-bookworm-slim@sha256:582460f614631b59b824ac6020533b9bf339c7fdf3a6d7db31abb6b4065f0212 # 26-bookworm-slim
+    env:
+      READ_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      RELEASE_TOKEN: ${{ secrets.RELEASE_TOKEN }}
+      # Live only with RELEASE_LIVE=1 AND either the schedule or a manual run
+      # with dry_run unticked.
+      DRY_RUN: ${{ (vars.RELEASE_LIVE == '1' && (github.event_name == 'schedule' || inputs.dry_run == false || inputs.dry_run == 'false')) && '0' || '1' }}
+    steps:
+      - uses: coffey-labs/actions/checkout@fab0c4d45e0162963965f1555df27b7bed5e20ec
+        with:
+          fetch-depth: 0
+      - run: apt-get update -qq && apt-get install -y -qq --no-install-recommends curl jq >/dev/null
+      - shell: bash
+        run: |
+          set -euo pipefail
+          # Internal address, as for everything else CI does: never through the proxy.
+          API="${CI_SERVER_INTERNAL}/api/v1/repos/${GITHUB_REPOSITORY}"
+          # The newest published release, or empty on a project that has never
+          # had one -- in which case everything counts as new.
+          previous="$(curl -fsS -H "Authorization: token ${READ_TOKEN}" "${API}/releases?draft=false&pre-release=false&limit=1" | jq -r '.[0].tag_name // ""')"
+          # A release can outlive its tag. Falling back to the whole history
+          # over-counts, which cuts a release that was due anyway;
+          # under-counting would skip one that was.
+          # Tag lookups use show-ref, which matches an exact ref and nothing
+          # else. `rev-parse --verify refs/tags/<name>` does not: on the git in
+          # this image (2.39) a name ending in -g<hex> falls back to being read
+          # as git-describe output, resolves to that commit, and so "exists"
+          # whether or not the tag does. Every commit not merged through a pull
+          # request has a -g<hex> version, so that check reported every such
+          # week as already released.
+          if [ -n "$previous" ] && git show-ref --verify --quiet "refs/tags/${previous}"; then
+            count="$(git rev-list --count "${previous}..HEAD")"; range="${previous}..HEAD"
+          else
+            count="$(git rev-list --count HEAD)"; range="HEAD"
+          fi
+          version="$(node scripts/version.mjs)"
+          # A Docker tag may not contain '+', and neither should the git tag,
+          # so the two always agree about what to call a build.
+          tag="v${version/+/-}"
+          title="v${version%%+*}"
+          sha="$(git rev-parse HEAD)"
+          if [ "$count" -eq 0 ]; then
+            echo "Nothing to release: no commits since ${previous}."; exit 0
+          fi
+          if git show-ref --verify --quiet "refs/tags/${tag}"; then
+            echo "Nothing to release: tag ${tag} already exists."; exit 0
+          fi
+          echo "Releasing ${tag} -- ${count} commit(s) since ${previous:-the beginning}, at ${sha}."
+          if [ "$DRY_RUN" = "1" ]; then echo "Dry run (RELEASE_LIVE='${{ vars.RELEASE_LIVE }}'): stopping here."; exit 0; fi
+          # Notes bounded to what is new, from the first-parent history of
+          # main -- one line per merge, which is what GitHub's generated notes
+          # listed.
+          notes="$(git log --first-parent --format='- %s' "$range")"
+          jq -n --arg tag "$tag" --arg ref "$sha" --arg name "$title" \
+                --arg body "$(printf '%s commit(s) since %s.\n\n%s' "$count" "${previous:-the beginning}" "$notes")" \
+                '{tag_name:$tag, target_commitish:$ref, name:$name, body:$body}' > release.json
+          curl -fsS -H "Authorization: token ${RELEASE_TOKEN}" -H "Content-Type: application/json" \
+               --data @release.json "${API}/releases" | jq -r '"created release " + .tag_name'
@@ -0,0 +1,250 @@
+# CI for the self-hosted GitLab that replaced GitHub Actions when the account
+# was suspended on 2026-09-20. This is a port of .github/workflows/ci.yml and
+# publish.yml, which are kept in the tree for reference and for the day the
+# appeal succeeds.
+#
+# Every `image:` here is pinned to a digest, with the tag it belonged to in the
+# trailing comment. That is the direct replacement for the SHA-pinned `uses:`
+# in the Actions workflows: GitLab has no equivalent of an action allowlist, so
+# the only thing standing between this pipeline and whatever the publisher
+# pushes to a tag next is the digest. Read the comment for the version; the
+# digest is what runs. Do not "simplify" one back to a bare tag.
+#
+# The runner is a group runner on Web_Host with the host docker socket bound
+# in, reached over the internal container network rather than
+# https://git.coffeylabs.org -- that name is Cloudflare-proxied on the Free
+# plan, which caps request bodies at 100 MB and would break artifact uploads.
+
+stages: [test, build, publish, release]
+
+variables:
+  # Jobs talk to the registry directly on its DNS-only name, never through the
+  # proxy, for the same 100 MB reason.
+  IMAGE: $CI_REGISTRY_IMAGE
+  GIT_DEPTH: "0"
+
+default:
+  interruptible: true
+
+# ---------------------------------------------------------------- test ------
+node:
+  stage: test
+  image: node:26-bookworm-slim@sha256:582460f614631b59b824ac6020533b9bf339c7fdf3a6d7db31abb6b4065f0212 # 26-bookworm-slim
+  variables:
+    NPM_CONFIG_CACHE: "$CI_PROJECT_DIR/.npm"
+  cache:
+    key:
+      files: [package-lock.json]
+    paths: [.npm/]
+  before_script:
+    # version.test.ts shells out to git to resolve a build version, and the
+    # slim image ships without it. The clone is done by the runner's helper
+    # image, so nothing else here needs git and its absence is easy to miss.
+    - apt-get update -qq && apt-get install -y -qq --no-install-recommends git
+    # config.test.ts chmods a directory to 0555 and expects the write to be
+    # refused. Root ignores the permission bits, so as root that assertion can
+    # never hold. The tests run as the image's unprivileged `node` user for
+    # that reason; -p keeps the environment.
+    #
+    # imageproxy.test.ts needs IPv6 as well, which is not set here but on the
+    # runner: jobs run on the `ci-net` docker network, created with --ipv6.
+    # Without a non-loopback IPv6 address on the container, getaddrinfo's
+    # AI_ADDRCONFIG drops ::1 from the results entirely, localhost resolves to
+    # IPv4 only, and the test's control case connects to a port nothing is
+    # listening on. That is a runner property, so it cannot be fixed from this
+    # file -- if these tests ever fail again with ECONNREFUSED on 127.0.0.1,
+    # check that the runner still puts jobs on an IPv6-enabled network.
+    - chown -R node:node "$CI_PROJECT_DIR"
+  script:
+    - su node -p -c "npm ci --ignore-scripts"
+    - su node -p -c "npm run typecheck"
+    - su node -p -c "npm test"
+    - su node -p -c "npm run build"
+  artifacts:
+    paths: [dist/]
+    expire_in: 1 week
+  rules:
+    - if: $RELEASE_WEEKLY == "1"
+      when: never
+    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
+    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
+    - if: $CI_COMMIT_TAG
+
+# --------------------------------------------------------------- build ------
+# Proves the Dockerfile still builds on every change, without pushing. The
+# equivalent of ci.yml's final `docker build -t ihasmail:ci .` step.
+#
+# Not called `image`: that is a reserved keyword, and a job by that name is
+# silently read as the global image: setting instead ("image name should be a
+# string"). Same trap for `stages`, `cache`, `services` and `variables`.
+docker-build:
+  stage: build
+  image: docker:28-cli@sha256:625d9431a9f54c5a2bc90f24f0e1c3d55b1349fd857dd85035f98c2c9acbdd4d # 28-cli
+  needs: [node]
+  script:
+    - docker build -t ihasmail:ci-$CI_COMMIT_SHORT_SHA .
+    - docker image rm ihasmail:ci-$CI_COMMIT_SHORT_SHA
+  rules:
+    - if: $RELEASE_WEEKLY == "1"
+      when: never
+    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
+    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
+
+# ------------------------------------------------------------- publish ------
+# Tag-driven, replacing the release -> publish workflow_call chain. GitHub
+# needed that dance because a release cut with GITHUB_TOKEN raises no event;
+# GitLab has no such rule, so a tag pipeline is enough.
+#
+# arm64 is built under QEMU on this amd64 host, not on a native runner as
+# GitHub's free `ubuntu-24.04-arm` did. It is slow -- tens of minutes for the
+# npm install and Vite build through instruction translation -- which is
+# tolerable for a weekly tag and would not be for every push. That is why this
+# job is tag-only. If arm64 ever starts timing out, the fix is an arm64 runner,
+# not dropping the platform: TrueNAS and Unraid users pull it.
+# The version the image is built with, computed the way publish.yml did it:
+# scripts/version.mjs, which needs node and the full history. The build is
+# *told* the real form (IHASMAIL_VERSION, what About and /api/health report);
+# the Docker tag gets the same string with '+' turned into '-', because a tag
+# may not contain '+'. The first port of this job left the build arg out, so
+# a tag would have shipped an image reporting itself unversioned -- which is
+# exactly what version.test.ts calls looking wrong.
+version:
+  stage: build
+  image: node:26-bookworm-slim@sha256:582460f614631b59b824ac6020533b9bf339c7fdf3a6d7db31abb6b4065f0212 # 26-bookworm-slim
+  variables:
+    GIT_DEPTH: "0"
+  before_script:
+    - apt-get update -qq && apt-get install -y -qq --no-install-recommends git >/dev/null
+    # The build directory is reused between jobs, and the node job chowns it to
+    # the unprivileged `node` user so its tests can run. A later job running
+    # git as root then finds the checkout owned by somebody else, and git
+    # refuses with "detected dubious ownership" (exit 128). Whether it happens
+    # depends on which cached directory a job lands on, so it comes and goes.
+    - git config --global --add safe.directory "$CI_PROJECT_DIR"
+  script:
+    - V="$(node scripts/version.mjs)"
+    - echo "VERSION=$V" > version.env
+    - echo "DOCKER_TAG=${V/+/-}" >> version.env
+    - cat version.env
+  artifacts:
+    reports:
+      dotenv: version.env
+  rules:
+    - if: $CI_COMMIT_TAG
+
+publish:
+  stage: publish
+  image: docker:28-cli@sha256:625d9431a9f54c5a2bc90f24f0e1c3d55b1349fd857dd85035f98c2c9acbdd4d # 28-cli
+  needs: [node, version]
+  variables:
+    DOCKER_BUILDKIT: "1"
+  before_script:
+    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"
+    - docker run --privileged --rm tonistiigi/binfmt --install arm64
+    # The registry hands out push tokens from https://git.coffeylabs.org/jwt/auth,
+    # and buildx fetches them here, in the job, not in its builder. On ci-net
+    # that name is the gitlab container itself (172.30.0.2), which serves
+    # plain HTTP to the runner and nothing on 443, so every push failed at the
+    # last step with "connection refused". The login above works because the
+    # host's daemon does it, and the host resolves the name publicly. So, for
+    # this job only, point the name at its public address the same way. Only
+    # the token request uses it; layers go to the registry's own DNS-only name.
+    - |
+      public="$(nslookup "$CI_SERVER_HOST" 1.1.1.1 2>/dev/null | awk '/^Address: / && $2 !~ /:/ { print $2; exit }')"
+      if [ -z "$public" ]; then echo "Could not resolve $CI_SERVER_HOST publicly" >&2; exit 1; fi
+      echo "$public $CI_SERVER_HOST" >> /etc/hosts
+      echo "$CI_SERVER_HOST -> $public for the registry token"
+    - docker buildx create --use --name ci-builder --driver docker-container || docker buildx use ci-builder
+  script:
+    - |
+      docker buildx build \
+        --platform linux/amd64,linux/arm64 \
+        --build-arg IHASMAIL_VERSION="$VERSION" \
+        --provenance=false --sbom=false \
+        --tag "$IMAGE:$DOCKER_TAG" \
+        --tag "$IMAGE:latest" \
+        --push .
+  after_script:
+    - docker logout "$CI_REGISTRY" || true
+  rules:
+    - if: $CI_COMMIT_TAG
+
+# ----------------------------------------------------------- weekly release --
+# Port of .github/workflows/release.yml: cut a release once a week, but only
+# when there is something in it. The decision is the workflow's, unchanged --
+# count the commits on main since the newest published release, and skip the
+# week if there are none or if the tag already exists (the version comes from
+# the commit, so an unchanged commit is an existing tag).
+#
+# It runs from a pipeline schedule (Mondays 09:17 UTC, the same odd minute as
+# before) that sets RELEASE_WEEKLY=1. GitLab keeps schedules on the project,
+# not in this file, so the schedule and this job only work as a pair. Run it by
+# hand with RELEASE_WEEKLY=1, adding DRY_RUN=1 to see the decision and stop.
+#
+# The release -- and with it the tag -- is created with RELEASE_TOKEN, a
+# project access token (protected, masked), not CI_JOB_TOKEN. A tag pushed that
+# way is an ordinary push, so it starts the tag pipeline, and the version and
+# publish jobs above build the image from it. That replaces release.yml's
+# direct call of publish.yml, which only existed because a tag created with
+# GITHUB_TOKEN raises no event. The token expires; when it does this job fails
+# at the API call, loudly, and a new one goes in the same variable.
+weekly-release:
+  stage: release
+  image: node:26-bookworm-slim@sha256:582460f614631b59b824ac6020533b9bf339c7fdf3a6d7db31abb6b4065f0212 # 26-bookworm-slim
+  # One at a time: two overlapping runs would race to create the same tag.
+  resource_group: weekly-release
+  variables:
+    GIT_DEPTH: "0"
+  before_script:
+    - apt-get update -qq && apt-get install -y -qq --no-install-recommends git curl jq >/dev/null
+    # See the version job: same shared directory, same root, same refusal.
+    - git config --global --add safe.directory "$CI_PROJECT_DIR"
+  script:
+    - |
+      set -euo pipefail
+      # Internal address, as for everything else CI does: never through the proxy.
+      API="http://gitlab/api/v4/projects/${CI_PROJECT_ID}"
+      auth=(--header "PRIVATE-TOKEN: ${RELEASE_TOKEN}")
+      # The newest published release, or empty on a project that has never had
+      # one -- in which case everything counts as new.
+      previous="$(curl -fsS "${auth[@]}" "${API}/releases?order_by=released_at&sort=desc&per_page=1" | jq -r '.[0].tag_name // ""')"
+      # A release can outlive its tag. Falling back to the whole history
+      # over-counts, which cuts a release that was due anyway; under-counting
+      # would skip one that was.
+      # Tag lookups use show-ref, which matches an exact ref and nothing else.
+      # `rev-parse --verify refs/tags/<name>` does not: on the git in this image
+      # (2.39) a name ending in -g<hex> falls back to being read as
+      # git-describe output, resolves to that commit, and so "exists" whether
+      # or not the tag does. Every commit not merged through a pull request has
+      # a -g<hex> version, so that check reported every such week as already
+      # released. Newer git (and GitHub's runners) do not fall back, which is
+      # why release.yml never showed it.
+      if [ -n "$previous" ] && git show-ref --verify --quiet "refs/tags/${previous}"; then
+        count="$(git rev-list --count "${previous}..HEAD")"; range="${previous}..HEAD"
+      else
+        count="$(git rev-list --count HEAD)"; range="HEAD"
+      fi
+      version="$(node scripts/version.mjs)"
+      # A Docker tag may not contain '+', and neither should the git tag, so
+      # the two always agree about what to call a build.
+      tag="v${version/+/-}"
+      title="v${version%%+*}"
+      sha="$(git rev-parse HEAD)"
+      if [ "$count" -eq 0 ]; then
+        echo "Nothing to release: no commits since ${previous}."; exit 0
+      fi
+      if git show-ref --verify --quiet "refs/tags/${tag}"; then
+        echo "Nothing to release: tag ${tag} already exists."; exit 0
+      fi
+      echo "Releasing ${tag} -- ${count} commit(s) since ${previous:-the beginning}, at ${sha}."
+      if [ "${DRY_RUN:-0}" = "1" ]; then echo "DRY_RUN=1: stopping here."; exit 0; fi
+      # Notes bounded to what is new, from the first-parent history of main --
+      # one line per merge, which is what GitHub's generated notes listed.
+      notes="$(git log --first-parent --format='- %s' "$range")"
+      jq -n --arg tag "$tag" --arg ref "$sha" --arg name "$title" \
+            --arg desc "$(printf '%s commit(s) since %s.\n\n%s' "$count" "${previous:-the beginning}" "$notes")" \
+            '{tag_name:$tag, ref:$ref, name:$name, description:$desc}' > release.json
+      curl -fsS "${auth[@]}" --header "Content-Type: application/json" \
+           --data @release.json "${API}/releases" | jq -r '"created release " + .tag_name'
+  rules:
+    - if: $RELEASE_WEEKLY == "1" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
@@ -16,7 +16,7 @@ By participating in this project, you agree to treat other contributors with res

 ### Reporting Bugs

-Before opening a new issue, please search [existing issues](https://github.com/Coffey-Labs/ihasmail/issues) to see if it's already been reported. When filing a bug report, include:
+Before opening a new issue, please search [existing issues](https://git.coffeylabs.org/coffey-labs/ihasmail/issues) to see if it's already been reported. When filing a bug report, include:

 - A clear, descriptive title
 - Steps to reproduce the issue
@@ -46,15 +46,15 @@ upgraded on 2026-08-25. They are kept where the finding is about ihasmail
 rather than about 0.15 — a byte cap that still applies, a flow that still
 works the same way — and dropped where 0.15 was the whole subject. Support for
 0.15 was removed on 2026-08-26; the last release that runs on it is tagged
-[`stalwart-0.15-support`](https://github.com/Coffey-Labs/ihasmail/releases/tag/stalwart-0.15-support).
+[`stalwart-0.15-support`](https://git.coffeylabs.org/coffey-labs/ihasmail/releases/tag/stalwart-0.15-support).

 - **`ContactCard/changes` works, and a download honors one byte range but does not say so.** Both **confirmed live (0.16.22, 2026-09-16)**, with objects on a throwaway account that were removed afterwards. `ContactCard/changes` reports a create, an update and a destroy exactly, nets a card created and destroyed since the given state out to nothing, and answers a state it does not recognize with `invalidArguments` rather than `cannotCalculateChanges`; the contacts store syncs from it and falls back to a full reload on any error. The download endpoint answers a single range (`bytes=0-9`, `bytes=-5`, `bytes=995-`) with `206` and a correct `Content-Range`, and anything else (several ranges, or a range past the end) with the whole file and `200`, never `416`. It sends no `Accept-Ranges`, so ihasmail's proxy advertises it: Chrome's PDF viewer reads a file in pieces only when told it can. The mock answers the same way.

- **Push subscriptions are not replaced by a repeated `deviceClientId`, and an account holds fifteen.** ihasmail registered a new subscription on every renewal believing the old one would be replaced, as the mock did. **Confirmed live (0.16.22, 2026-09-16)**: a second create with the same `deviceClientId` leaves both in place, the sixteenth create is refused with `overQuota`, "There are too many subscriptions, please delete some before adding a new one.", and `update` of `expires` is accepted. `PushSubscription/get` does not return `url` (nor `keys`), so a subscription can only be matched by its `deviceClientId`. A `types` of `[]` or `null` is stored as *every* type, not none. Read from the 0.16.22 source: `EmailDelivery` changes only on delivery, a delivery reaches a subscription with an `emailPush` filter as an EmailPush alone, and the payload carries `id` and `threadId` only when they are named in `properties`. Browsers now subscribe to `EmailDelivery` only, extend rather than re-create, clear their own duplicates and make room on `overQuota`; the server removes what its previous process registered. The mock follows all of it ([#375](https://github.com/Coffey-Labs/ihasmail/issues/375)).
+- **Push subscriptions are not replaced by a repeated `deviceClientId`, and an account holds fifteen.** ihasmail registered a new subscription on every renewal believing the old one would be replaced, as the mock did. **Confirmed live (0.16.22, 2026-09-16)**: a second create with the same `deviceClientId` leaves both in place, the sixteenth create is refused with `overQuota`, "There are too many subscriptions, please delete some before adding a new one.", and `update` of `expires` is accepted. `PushSubscription/get` does not return `url` (nor `keys`), so a subscription can only be matched by its `deviceClientId`. A `types` of `[]` or `null` is stored as *every* type, not none. Read from the 0.16.22 source: `EmailDelivery` changes only on delivery, a delivery reaches a subscription with an `emailPush` filter as an EmailPush alone, and the payload carries `id` and `threadId` only when they are named in `properties`. Browsers now subscribe to `EmailDelivery` only, extend rather than re-create, clear their own duplicates and make room on `overQuota`; the server removes what its previous process registered. The mock follows all of it ([#375](https://git.coffeylabs.org/coffey-labs/ihasmail-github-archive/issues/375)).

- **A contact photo has to be a `data:` URI; Stalwart refuses one given as a `blobId`.** RFC 9610 lets JMAP put a `blobId` in a JSContact `Media` object, and ihasmail uploaded the photo and saved it that way, which the mock accepted. Stalwart does not: **confirmed live (0.16.22, 2026-09-16)**, a `ContactCard/set` create with `media.*.blobId` fails with `invalidProperties` on `media`, "blobIds in media is not supported." The RFC 9553 `uri` form with a `data:image/jpeg;base64,…` value is accepted on create and on update, and `ContactCard/get` returns it unchanged; a 134 KB one was accepted. Photos are now saved inline, and the mock refuses a `blobId` the same way ([#376](https://github.com/Coffey-Labs/ihasmail/issues/376)).
+- **A contact photo has to be a `data:` URI; Stalwart refuses one given as a `blobId`.** RFC 9610 lets JMAP put a `blobId` in a JSContact `Media` object, and ihasmail uploaded the photo and saved it that way, which the mock accepted. Stalwart does not: **confirmed live (0.16.22, 2026-09-16)**, a `ContactCard/set` create with `media.*.blobId` fails with `invalidProperties` on `media`, "blobIds in media is not supported." The RFC 9553 `uri` form with a `data:image/jpeg;base64,…` value is accepted on create and on update, and `ContactCard/get` returns it unchanged; a 134 KB one was accepted. Photos are now saved inline, and the mock refuses a `blobId` the same way ([#376](https://git.coffeylabs.org/coffey-labs/ihasmail-github-archive/issues/376)).

- **Administration was built from Stalwart's source, and the first live run found the one thing the source reading got wrong.** Accounts and Domains were written on 2026-09-13 against the 0.16.22 source and a mock reproducing it, deployed the same day, and exercised against the live server from an administrator's session. On that server the Accounts list did not load: `x:Account/query` answered **`unsupportedFilter - type`**. A registry filter is keyed by the property's name *as it appears on the object*, and the discriminator is `@type`, so `{"type": "User"}` names nothing the server knows and fails the whole query; `{"@type": "User"}` is accepted. The research that fed the build had listed the field as `type`, and the mock took it without complaint — which is how it shipped. Fixed in [#336](https://github.com/Coffey-Labs/ihasmail/pull/336), and the mock now refuses any filter name the real server does not index, answering the way Stalwart does. Everything else was **confirmed live (2026-09-13)**, mostly read-only, with the domain writes made on a throwaway domain created for the purpose and removed afterwards:
+- **Administration was built from Stalwart's source, and the first live run found the one thing the source reading got wrong.** Accounts and Domains were written on 2026-09-13 against the 0.16.22 source and a mock reproducing it, deployed the same day, and exercised against the live server from an administrator's session. On that server the Accounts list did not load: `x:Account/query` answered **`unsupportedFilter - type`**. A registry filter is keyed by the property's name *as it appears on the object*, and the discriminator is `@type`, so `{"type": "User"}` names nothing the server knows and fails the whole query; `{"@type": "User"}` is accepted. The research that fed the build had listed the field as `type`, and the mock took it without complaint — which is how it shipped. Fixed in [#336](https://git.coffeylabs.org/coffey-labs/ihasmail-github-archive/issues/336), and the mock now refuses any filter name the real server does not index, answering the way Stalwart does. Everything else was **confirmed live (2026-09-13)**, mostly read-only, with the domain writes made on a throwaway domain created for the purpose and removed afterwards:

  - **Permissions** come from `GET /api/account` in camelCase (`sysAccountGet`); an administrator's list held 641 of them and none were kebab-case, whatever the documentation shows. The menu gates on these.
  - **The Basic credential ihasmail proxies with reaches the admin `x:` methods**, as it already reached the self-service ones. No separate token is involved.
@@ -118,14 +118,14 @@ works the same way — and dropped where 0.15 was the whole subject. Support for

 - **`npm run i18n:coverage` reported 100% while about two hundred strings rendered English in every language.** It reads JSX text, and it was not wrong about what it measured — none of them were JSX text. They were `toast.error(...)` arguments, `confirmDialog({ title, confirmLabel })` props, `title=` and `aria-label=` attributes, and template literals: every one built from an expression a codemod cannot read. The calendar's own view switcher was the clearest case, spelling its labels `v[0].toUpperCase() + v.slice(1)` — correct English, untranslatable anywhere else, and galling because **Day**, **Week**, **Month** and **Agenda** were already in all nine catalogs and the buttons simply never asked for them. Reported from production, where the switcher stayed English in a Japanese interface. All of them are now wrapped, and `npm run i18n:check` grew a second half (`scripts/i18n-literals.mjs`) that accepts a string wrapped where it is written *or* present as a catalog key — the constant-table convention, where `SECTIONS` holds `label: "About"` and the render site calls `t(s.label)` — and refuses one that is neither, because that is a string no catalog can translate however many languages ship. It found twenty more than a hand sweep had. Worth recording as a general lesson rather than an i18n one: a coverage number measures the thing it can see, and the strings it cannot see are exactly the ones nobody is checking. **The check had the same blind spot one level down (2026-09-14).** It looked at `title=`, `aria-label=`, `placeholder=` and `alt=` on elements, but not at props passed to components, so `<MenuItem label={x ? "Collapse all" : "Expand all"}>` passed. It also accepted a JSX literal that was a catalog key, although no component here runs its props through `t()`, so 19 strings with translations in every catalog (Report spam, Mark as read, Add star, Save…) still rendered in English. And the script only exited non-zero with `--check`, which `npm run i18n:check` never passed, so it could print a finding without failing. Component props are checked now, a key no longer excuses a literal in an attribute, and both halves run with `--check`. That turned up 28 strings, all fixed: 19 wrapped, and 9 that needed new keys in all nine catalogs. English built with a template literal inside an attribute, such as ``aria-label={`Remove ${email}`}``, was the last gap. It can't be a catalog key as written. Since 2026-09-14 the check flags any template literal in one of these positions that has words between its values, and the twelve that existed are now keys with placeholders. They were the quota bar, the address menu, a folder's unread count, the recipient chips, the contact editor's title, shared calendars and address books, the date and time fields, the attachment fallback name, and the free/busy bar. That bar showed the raw JMAP value (`confirmed`) in every language.

- **A compressing hop in front of Stalwart truncated every blob download, and nothing said so.** Node decompresses a gzip response before the code ever sees the body, but leaves the `content-length` header describing the *compressed* bytes. The blob proxy copied that header onto the longer body it forwarded, so the browser stopped reading exactly that many bytes in and called the download complete. Reported on [#76](https://github.com/Coffey-Labs/ihasmail/issues/76) against a Coolify deployment, where Traefik's compress middleware only engages above 1 KiB: filter rules one and two were fine and the third pushed the script past the threshold, after which it came back cut off mid-rule — 384 bytes of a 1.3 KB script. The size threshold is what made it look like a race. This is the *second* cause behind that issue, and the first fix did not touch it: a truncated script is neither unknown nor empty, so the "refuse to save from a baseline we could not read" guard never fired — the script parsed, just with rules missing, and the next save wrote the short version back over the real one. Every blob download shared the fault, not just Sieve: message source, vCards, signature HTML, attachments being forwarded, and the `settings.json` sync. Settings degraded honestly by luck rather than design — a truncated file fails `JSON.parse`, which is caught and leaves the local cache in charge — so it stopped syncing between devices instead of being overwritten. The proxy now asks upstream for `identity` and, for a hop that compresses anyway, forwards no length at all rather than one describing different bytes. The image proxy is unaffected: it uses `node:http` directly, sends no `accept-encoding`, and never decompresses. The save path no longer trusts the transport either: a script is now checked for completeness against the shape the generator emits — every `# rule:` comment parses, every enabled rule has an `if` and a closed body below it, every block ends with a blank line — and saving refuses on anything short, as does the rule editor, which reports the script as unreadable rather than showing the rules that happened to parse. The check is structural rather than a re-serialize-and-compare, so a script written by an older version with a different serializer is still editable; refusing over a changed byte would be the worse bug. It catches a cut at every offset except the end of a complete rule block, which is a legitimately shorter script and indistinguishable from one in the bytes alone — that residual is what the proxy fix covers.
+- **A compressing hop in front of Stalwart truncated every blob download, and nothing said so.** Node decompresses a gzip response before the code ever sees the body, but leaves the `content-length` header describing the *compressed* bytes. The blob proxy copied that header onto the longer body it forwarded, so the browser stopped reading exactly that many bytes in and called the download complete. Reported on [#76](https://git.coffeylabs.org/coffey-labs/ihasmail-github-archive/issues/76) against a Coolify deployment, where Traefik's compress middleware only engages above 1 KiB: filter rules one and two were fine and the third pushed the script past the threshold, after which it came back cut off mid-rule — 384 bytes of a 1.3 KB script. The size threshold is what made it look like a race. This is the *second* cause behind that issue, and the first fix did not touch it: a truncated script is neither unknown nor empty, so the "refuse to save from a baseline we could not read" guard never fired — the script parsed, just with rules missing, and the next save wrote the short version back over the real one. Every blob download shared the fault, not just Sieve: message source, vCards, signature HTML, attachments being forwarded, and the `settings.json` sync. Settings degraded honestly by luck rather than design — a truncated file fails `JSON.parse`, which is caught and leaves the local cache in charge — so it stopped syncing between devices instead of being overwritten. The proxy now asks upstream for `identity` and, for a hop that compresses anyway, forwards no length at all rather than one describing different bytes. The image proxy is unaffected: it uses `node:http` directly, sends no `accept-encoding`, and never decompresses. The save path no longer trusts the transport either: a script is now checked for completeness against the shape the generator emits — every `# rule:` comment parses, every enabled rule has an `if` and a closed body below it, every block ends with a blank line — and saving refuses on anything short, as does the rule editor, which reports the script as unreadable rather than showing the rules that happened to parse. The check is structural rather than a re-serialize-and-compare, so a script written by an older version with a different serializer is still editable; refusing over a changed byte would be the worse bug. It catches a cut at every offset except the end of a complete rule block, which is a legitimately shorter script and indistinguishable from one in the bytes alone — that residual is what the proxy fix covers.

 - **Delete all spam destroys, and does not pass through Deleted Items** — this is the point of the feature and the thing worth checking on a real server, since a folder that empties into another folder has solved nothing. `Email/set destroy`, walked a page at a time so it survives `maxObjectsInSet` the way emptying Deleted Items already had to. **Confirmed live on 0.16.19 (2026-08-26)**: Junk Mail emptied and Deleted Items stayed empty afterwards. There is no undo, which is why all three entry points share one dialog that says so. Only Deleted Items and Junk Mail can be emptied this way, enforced in the store rather than only hidden in the menus.
 - **Sharing a mail folder is accepted and does nothing.** `Mailbox/set` with a `shareWith` map is applied, `Mailbox/get` reads it back, and the folder never appears for the account it was shared with — **confirmed live on 0.16.19 (2026-08-27)** with a folder shared read-only to another account on the same server, which never saw it. Stalwart's own sharing documentation lists calendars, address books and file storage; mail folders are not among them. Nothing reports a failure at any point, which is the whole problem: the share is stored, so a client that trusts what it reads back shows it as live for ever. The entry point is withdrawn. A folder that is *already* shared still offers **Stop sharing**, because a share nobody can see is exactly the one you want to be able to clear, and there is no other way to. File sharing is unaffected and works end to end.
 - **Address book sharing works, and was briefly withdrawn by mistake.** It was taken out alongside mail folders on 2026-08-27 on a report that it behaved the same way; the report was mistaken and the feature was put back the same day. Nothing was ever shown to be wrong with it, and Stalwart documents address books as shareable. Recorded because the withdrawal is in the history and would otherwise read as a finding. Shared books now appear in the Contacts pane under "Shared with me" rather than behind an account switch, and their contacts are offered when addressing a message.
 - **Stalwart lets a sharee subscribe to a shared calendar but not a shared address book.** Subscribing is a write to the *owner's* account -- `isSubscribed` lives on the collection, not on the reader -- and 0.16.19 refuses it for a book shared read-only: `AddressBook/set` answers successfully with the id in `notUpdated`, `forbidden`, *"You are not allowed to modify this address book."* The identical `Calendar/set` on a shared calendar is accepted. **Confirmed live on 0.16.19 (2026-08-27)** from a second account holding both shares, which is the only place it shows: from the owner's own account the write succeeds and everything looks fine. So ihasmail asks the server first, because a preference the server holds is one every client agrees about, and keeps the answer in its own synced settings (`addedShares`) when the server will not. Two things this cost, both worth remembering: the refusal arrives as a *successful* response, so the code that ignored `notUpdated` saw nothing wrong and the button simply did nothing; and it is invisible from the owner's account, so it took two browsers signed in as two accounts to find at all. The mock now refuses the same write for the same reason, since one that accepted it agreed with the belief that shipped.
 - **`shareWith` is not returned unless a client asks for it by name.** A `Calendar/get` or `AddressBook/get` with no `properties` comes back without the field at all — not null, not empty, absent — **confirmed live on 0.16.19 (2026-08-27)** against a calendar and an address book that were genuinely shared with another account: omit the list and there is no `shareWith`; name it and the sharee is right there. Every consequence was silent. Nothing was badged as shared, "Stop sharing" never appeared because nothing looked shared, and the share dialog opened on *"not shared with anyone yet"* over a live share — so the one screen that existed to manage sharing was the one most confidently wrong about it. Files never had this, because `fileNodeProps` had always named the property; calendars, address books and mail folders fetched everything and got less. Mail folders mattered in a way of their own: sharing one is withdrawn, and the only way to clear a share already made is a **Stop sharing** entry that appears when a folder looks shared — so without the property the escape hatch for the exact situation it was built for was invisible. The mock omitted it the same way, since one that hands it over unasked lets a client that never asks look correct everywhere except against a real server. **0.16.21 fixed this for calendars and address books**: with `properties` omitted, `Calendar/get` and `AddressBook/get` now return every property, `shareWith` included — **confirmed live on 0.16.21 (2026-09-06)**. `Mailbox/get` on the same server still leaves it out, so the mock now hides it for mail folders alone, and ihasmail keeps naming the property everywhere.
- **Stalwart's `x:PublicKey` registry works, and ihasmail deliberately does not expose it.** A Settings section for it has been built twice — [PR #67](https://github.com/Coffey-Labs/ihasmail/pull/67), closed 2026-08-26, and [PR #285](https://github.com/Coffey-Labs/ihasmail/pull/285) — and withdrawn both times, for a reason that has nothing to do with the server: **nothing in ihasmail signs, encrypts, decrypts or verifies with a key**, so a page for managing them is furniture rather than a feature. It ends up telling the reader, in its own footnote, that adding a key does nothing. The registry is written up here rather than in [ROADMAP.md](ROADMAP.md) because what follows is established fact about Stalwart that cost a live probe, and losing it twice to a closed pull request was how the second attempt came to exist at all. Everything below was **confirmed live on 0.16.20 (2026-09-05)** from a normal account with no administrative rights, and the full round trip — create, read back, rename, patch, destroy — succeeded for both formats.
+- **Stalwart's `x:PublicKey` registry works, and ihasmail deliberately does not expose it.** A Settings section for it has been built twice — [PR #67](https://git.coffeylabs.org/coffey-labs/ihasmail-github-archive/issues/67), closed 2026-08-26, and [PR #285](https://git.coffeylabs.org/coffey-labs/ihasmail-github-archive/issues/285) — and withdrawn both times, for a reason that has nothing to do with the server: **nothing in ihasmail signs, encrypts, decrypts or verifies with a key**, so a page for managing them is furniture rather than a feature. It ends up telling the reader, in its own footnote, that adding a key does nothing. The registry is written up here rather than in [ROADMAP.md](ROADMAP.md) because what follows is established fact about Stalwart that cost a live probe, and losing it twice to a closed pull request was how the second attempt came to exist at all. Everything below was **confirmed live on 0.16.20 (2026-09-05)** from a normal account with no administrative rights, and the full round trip — create, read back, rename, patch, destroy — succeeded for both formats.

  - **An ordinary user may read *and* write their own keys**, whatever the permissions table says: Stalwart documents every `sysPublicKey*` permission as administrative, and the server granted them anyway. A create carrying a malformed key was refused with `invalidProperties` naming `key` rather than `forbidden` — a rejection of the key, not of the person. Had the documentation been right, any such feature would have been useless to everybody but an administrator, which is why this was probed first.
  - **It takes S/MIME certificates as well as OpenPGP keys, and parses both.** A self-signed X.509 certificate carrying `emailProtection` and an `email:` SAN registered, read back and destroyed cleanly, and a malformed one is refused by a decoder of its own: *"Failed to decode X509 certificate: BER decoding error: Expected Tag { class: Universal, value: 16 } tag…"*. Worth checking rather than assuming, because every *other* message the registry returns names OpenPGP — including for input that is not OpenPGP at all — so the server reads as though OpenPGP were the only format it knows. It is not.
@@ -140,11 +140,11 @@ works the same way — and dropped where 0.15 was the whole subject. Support for
 - **Read receipts are built here, not by the server** — JMAP has an extension for them, [RFC 9007](https://www.rfc-editor.org/rfc/rfc9007.html)'s `MDN/send`, and Stalwart does not implement it: `urn:ietf:params:jmap:mdn` is not among its capabilities. So ihasmail assembles the `multipart/report` itself and sends it the long way round — raw MIME uploaded as a blob, `Email/import`, then `EmailSubmission` — which is also why the receipt lands in Sent, where it honestly belongs. Non-ASCII parts are base64 rather than `8bit`, so nothing depends on 8BITMIME surviving every hop. There is deliberately no "always send" setting: a receipt confirms to whoever asked that the address is live and when it was read, to an address of the sender's choosing, so each one is a decision. Verified against the mock end to end (upload, import, submit, `$mdnsent`), and **confirmed live on 0.16.19 (2026-08-26)**: a receipt asked for by a real sender was assembled, uploaded, imported and submitted, landed in Sent, and set `$mdnsent` so a second look does not offer to send another.
 - **Where 0.16 advertises `urn:stalwart:jmap`** — not where a JMAP client would look, and this now decides whether a sign-in is allowed at all. Stalwart builds the session-level `capabilities` from a fixed list (`Session::new`, plus WebSocket) that has never contained this capability, in any 0.16.x from 0.16.0 to 0.16.19. It hands it out per-account instead, so it appears in `primaryAccounts` and in each account's `accountCapabilities`. ihasmail tested for it in `capabilities` alone, which made every real 0.16 server read as older than 0.16 — and that one check drove three things: self-service credentials fell back to `POST /api/account/auth`, which 0.16 removed, so password changes, 2FA and app passwords all failed with "this mail server does not offer self-service credential management"; About reported the wrong generation; and Files took the older code path. It now looks in all three places, and is covered by tests on each. Worth restating plainly, because the stakes went up when 0.15 support was dropped: there is no longer a fallback path for this check to be wrong *into*. Getting it wrong now refuses every sign-in against a perfectly good server — a loud failure rather than a quiet misrouting, which is the trade the removal was making.
 - **HTML signatures** — Stalwart caps a signature at 2047 **bytes** (`value.len() < 2048` on a Rust string, so UTF-8 bytes, not characters). ihasmail compacts pasted HTML, moves images to Files and, if still too large, keeps the full signature in Files behind a short marker; other clients see a text fallback. Confirmed live on 0.15.5 (2026-08-24): oversized, non-ASCII and inline-image signatures all save, and a test message arrived intact at Gmail with the logo inline.
- **Settings live in the account's Files, not the browser** — every preference used to sit in `localStorage`, so none of them followed anyone between devices. The sharpest edge was the default identity: with none set the address that sorts first wins, so someone who set it at work found it unset at home and mail went out from an address the recipient might not recognize ([#54](https://github.com/Coffey-Labs/ihasmail/issues/54)). They are now a `settings.json` in the `ihasmail` folder in JMAP Files, beside the signature images already kept there — which keeps ihasmail itself stateless: no volume, no database, nothing to back up separately, and the settings are covered by whatever backs up the mail store. `x:AccountSettings` was the other candidate and does not fit; its schema is `locale`/`timeZone`/`description` with no free-form field, and writing it needs `sysAccountSettingsSet`, where the built-in user role carries only the `…Get` half. `localStorage` stays on as a *cache* rather than the source of truth, so the first frame paints from it and the file corrects it a moment later; a browser with no cache shows defaults for that one frame, which is the trade for not gating the whole app on a round trip. Settings that describe *this* screen or browser deliberately stay local — list-pane sizes, density, font size, sidebar state, and the notification toggles, which track a permission the browser grants per-device and would be a claim about somewhere else it cannot make. That split is written as a list of exceptions, so a setting added later syncs by default. Writes are coalesced behind a three-second debounce, since `update()` fires on every frame of a splitter drag, and a tab going away or a sign-out flushes first. The `ihasmail` folder is now hidden from the Files view, contents and all: hiding the folder alone would be worse than showing it, because the tree attaches a node whose parent is missing to the root, so the signature images — visible there since signatures shipped — would have spilled into the top level. **Confirmed live on 0.16.19 (2026-08-26)**: settings set in Chrome came back on a fresh login in Firefox and in an incognito session, both of which start with an empty cache, so each read the account's file rather than anything local. Confirmed again on the deployed instance rather than only a pre-deployment build. Requires 0.16, which ihasmail now requires everywhere — `FileNode/query` cannot see directories before that, and sign-in refuses an older server outright. Two limits worth knowing: conflicts are last-write-wins, and a change made on one device does not reach another that already has ihasmail open until it signs in again.
+- **Settings live in the account's Files, not the browser** — every preference used to sit in `localStorage`, so none of them followed anyone between devices. The sharpest edge was the default identity: with none set the address that sorts first wins, so someone who set it at work found it unset at home and mail went out from an address the recipient might not recognize ([#54](https://git.coffeylabs.org/coffey-labs/ihasmail-github-archive/issues/54)). They are now a `settings.json` in the `ihasmail` folder in JMAP Files, beside the signature images already kept there — which keeps ihasmail itself stateless: no volume, no database, nothing to back up separately, and the settings are covered by whatever backs up the mail store. `x:AccountSettings` was the other candidate and does not fit; its schema is `locale`/`timeZone`/`description` with no free-form field, and writing it needs `sysAccountSettingsSet`, where the built-in user role carries only the `…Get` half. `localStorage` stays on as a *cache* rather than the source of truth, so the first frame paints from it and the file corrects it a moment later; a browser with no cache shows defaults for that one frame, which is the trade for not gating the whole app on a round trip. Settings that describe *this* screen or browser deliberately stay local — list-pane sizes, density, font size, sidebar state, and the notification toggles, which track a permission the browser grants per-device and would be a claim about somewhere else it cannot make. That split is written as a list of exceptions, so a setting added later syncs by default. Writes are coalesced behind a three-second debounce, since `update()` fires on every frame of a splitter drag, and a tab going away or a sign-out flushes first. The `ihasmail` folder is now hidden from the Files view, contents and all: hiding the folder alone would be worse than showing it, because the tree attaches a node whose parent is missing to the root, so the signature images — visible there since signatures shipped — would have spilled into the top level. **Confirmed live on 0.16.19 (2026-08-26)**: settings set in Chrome came back on a fresh login in Firefox and in an incognito session, both of which start with an empty cache, so each read the account's file rather than anything local. Confirmed again on the deployed instance rather than only a pre-deployment build. Requires 0.16, which ihasmail now requires everywhere — `FileNode/query` cannot see directories before that, and sign-in refuses an older server outright. Two limits worth knowing: conflicts are last-write-wins, and a change made on one device does not reach another that already has ihasmail open until it signs in again.
 - **Files on 0.16** — the pre-0.16 quirks this entry used to describe are gone with the support for them: `FileNode/query` masking directories out of its own results, `nodeType` not existing, and rights being a single `mayWrite`. What is left is what has actually been exercised on 0.16.19. Finding and creating a folder, creating a node with `nodeType`, uploading and downloading its blob, and pointing an existing node at a new one all ran live on 2026-08-26, as a side effect of the settings file. Rename, move and delete are **confirmed live on 0.16.19 (2026-08-26)** as well, which closes this out: what had been confirmed on 0.15.5 (2026-08-24) was the older code path, and that path no longer exists. Two fallbacks went with the removal and are worth knowing about: `ensureFolder` and `findInFolder` now filter on `parentId`/`isTopLevel` alone and match names client-side, since `name` is not a filter Stalwart is known to implement and one it does not know fails the whole query; and a refused filter or sort no longer drops the view into fetching every node in the account, which would have hidden a real fault behind a performance cliff nobody would notice.
 - **Self-service credentials** — the registry path is **confirmed live** against Stalwart 0.16.19 (2026-08-25): app passwords created and revoked, password changed, 2FA enabled and disabled, with the browser session surviving the switch to an app password. The 0.15 REST path was confirmed live too, on 0.15.5 (2026-08-24), and has since been removed along with the rest of 0.15 support. The mock enforces the same rules the real server does (current password required, password policy, a TOTP code on every request once 2FA is on, app passwords exempt from it). Password changes are refused by Stalwart for accounts backed by an external directory (LDAP/SQL/OIDC); the server's own message is shown when that happens.
 - **Scheduled send needs one setting turned on, and says nothing when it is off.** Stalwart advertises the delay in the account's `urn:ietf:params:jmap:submission` capability — `maxDelayedSend: 2592000` (30 days) and `FUTURERELEASE` among its `submissionExtensions`, and note it is the *account* capability, not the session-level one, which is empty. But the MTA only honors a hold when `futureRelease` is set under the session's MTA extensions, and [that setting defaults to `false`](https://stalw.art/docs/ref/object/mta-extensions/). With it off, Stalwart takes the `HOLDUNTIL` parameter, skips the hold and sends the message immediately **without an error** — the capability still says thirty days. So set `futureRelease` (to the longest hold you want to allow) before relying on this; a value shorter than 30 days is fine, and a request past it is refused honestly, with a `forbiddenMailFrom` naming the limit. `npm run dev:mock:no-future-release` reproduces the silent-drop case. ihasmail asks for the delay the way JMAP requires — a `HOLDUNTIL` parameter on the envelope's `mailFrom`, since RFC 8621 makes `sendAt` read-only and server-derived — and files the held message in a **Scheduled** folder, because `onSuccessUpdateEmail` would otherwise drop it in Sent the moment the submission is created. Nothing moves it out when the hold expires, so ihasmail reconciles the folder on the way in: released messages to Sent, canceled ones back to Drafts. Three fixes this depends on landed in **0.16.17**, below the live instance's 0.16.19: `HOLDUNTIL` taking RFC 3339 date-times again (0.16.16 had it wanting Unix timestamps), `EmailSubmission/query` on `undoStatus` agreeing with `/get` about held submissions, and `EmailSubmission/get` without `ids` iterating the right index. The hold itself is now **confirmed against the live 0.16.19** (2026-08-25), once `futureRelease` was set to `30d` there: a submission carrying a `HOLDUNTIL` ten minutes out came back `pending`, with `sendAt` equal to the time asked for and a `250 2.1.5 Queued` from the MTA, rather than going out at once. Worth repeating that the capability is no evidence either way — it advertised `maxDelayedSend: 2592000` and `FUTURERELEASE` while the setting was still off. Only a submission tells you. The rest of the journey is **confirmed live too (2026-08-26)**: a hold expired and was delivered, and the **Scheduled** folder reconciled on the way in — a released message moved to Sent, a canceled one back to Drafts. Nothing in Stalwart does that moving, so if ihasmail is never opened again the message still goes out; it is only the folder that waits to be tidied.
- **Stalwart 0.16 and RFC 8984 disagree about the calendar vocabulary, and the server only says so half the time.** A participant's address lives in `calendarAddress`, not RFC 8984's `sendTo`/`email`; the organizer is `organizerCalendarAddress`, not `replyTo`; and a recurrence is a single `recurrenceRule`, not a `recurrenceRules` array. Addressed the RFC's way, `CalendarEvent/set` **keeps the event and discards the whole participant map without an error** — guests disappeared on save and no invitation was ever sent, which is what [#26](https://github.com/Coffey-Labs/ihasmail/issues/26) reported. The array form of the rule is refused honestly, with `invalidProperties`, so recurring events could not be created at all and existing ones showed no repeat ([#30](https://github.com/Coffey-Labs/ihasmail/issues/30)). ihasmail now writes Stalwart's names and reads either, and the mock refuses what the real server refuses, since advertising the RFC spelling is precisely how this got as far as a live server. Verified against 0.16.19 on 2026-08-25, end to end: participants, organizer and rule all survive a create, an update and a re-read; an invitation to an external Gmail address arrived as an invite card, and the decline came back and was applied to the event (`needs-action` → `declined`, sequence 1). Canceling the event notified the guest too. Adding guests to an event that had none, and clearing them again with `null`, both work on the update path, as does RSVP — which patches `participants/{key}/participationStatus` (and `participationComment`) rather than sending the whole map. That patch had to be aimed at the base event: through 0.16.19 `CalendarEvent/set` refused a synthetic id with *"Updating synthetic ids is not yet supported"*, which is why RSVP resolves `baseEventId` first. 0.16.20 accepts one, so that resolution is now a choice rather than the only option — an RSVP aimed at an occurrence would answer for that date alone. It still resolves the base, which is the answer people mean. Adding a *new* participant by patch is refused as well (`Patch operation failed`), so a changed guest list is written as the whole `participants` property. One more thing to know when reading this code: an expanded occurrence carries a `recurrenceId` but *no* rule of its own, and `baseEventId` is set on everything an expanded query returns — a one-off included, whose own id differs from its base — so neither is a test for recurrence. Since 0.16.22 the same event read by its *stored* id answers `baseEventId: null` rather than its own id, which changes nothing here: a one-off read through the synthetic id an expanded query gave it still carries a base.
+- **Stalwart 0.16 and RFC 8984 disagree about the calendar vocabulary, and the server only says so half the time.** A participant's address lives in `calendarAddress`, not RFC 8984's `sendTo`/`email`; the organizer is `organizerCalendarAddress`, not `replyTo`; and a recurrence is a single `recurrenceRule`, not a `recurrenceRules` array. Addressed the RFC's way, `CalendarEvent/set` **keeps the event and discards the whole participant map without an error** — guests disappeared on save and no invitation was ever sent, which is what [#26](https://git.coffeylabs.org/coffey-labs/ihasmail-github-archive/issues/26) reported. The array form of the rule is refused honestly, with `invalidProperties`, so recurring events could not be created at all and existing ones showed no repeat ([#30](https://git.coffeylabs.org/coffey-labs/ihasmail-github-archive/issues/30)). ihasmail now writes Stalwart's names and reads either, and the mock refuses what the real server refuses, since advertising the RFC spelling is precisely how this got as far as a live server. Verified against 0.16.19 on 2026-08-25, end to end: participants, organizer and rule all survive a create, an update and a re-read; an invitation to an external Gmail address arrived as an invite card, and the decline came back and was applied to the event (`needs-action` → `declined`, sequence 1). Canceling the event notified the guest too. Adding guests to an event that had none, and clearing them again with `null`, both work on the update path, as does RSVP — which patches `participants/{key}/participationStatus` (and `participationComment`) rather than sending the whole map. That patch had to be aimed at the base event: through 0.16.19 `CalendarEvent/set` refused a synthetic id with *"Updating synthetic ids is not yet supported"*, which is why RSVP resolves `baseEventId` first. 0.16.20 accepts one, so that resolution is now a choice rather than the only option — an RSVP aimed at an occurrence would answer for that date alone. It still resolves the base, which is the answer people mean. Adding a *new* participant by patch is refused as well (`Patch operation failed`), so a changed guest list is written as the whole `participants` property. One more thing to know when reading this code: an expanded occurrence carries a `recurrenceId` but *no* rule of its own, and `baseEventId` is set on everything an expanded query returns — a one-off included, whose own id differs from its base — so neither is a test for recurrence. Since 0.16.22 the same event read by its *stored* id answers `baseEventId: null` rather than its own id, which changes nothing here: a one-off read through the synthetic id an expanded query gave it still carries a base.
 - **Free/busy between accounts needs no sharing, and calendar contents cannot be reached at all.** These are the two halves of the same finding, and the second is what makes the first safe. **Confirmed live on 0.16.20 (2026-09-01)** against the deployed instance: `Principal/getAvailability` was called for all seven principals the directory returns, none of whose calendars are shared with the calling account, and every one was answered — no `forbidden`, no error of any kind, from a server that refuses a malformed call instantly. It returns real data rather than a polite empty list: the caller's own principal reported one busy period against the one event in the next sixty days. And a `Principal` carries only `id`, `type`, `name`, `description` and `email` — **no `accountId`** — so there is no handle with which to ask for anybody's calendars. Free/busy is therefore not the weaker of two permissions, it is the only channel between two accounts, and it is open by default. That is the right posture and worth recording, because a client that assumed sharing was a precondition would hide a working feature behind a setting nobody needs to touch. **One thing this did not settle**: the other six principals reported nothing over a nine-month window, which is equally consistent with "those accounts have empty calendars" — likely, since the session reaches one account — and with "an unreadable principal answers with an empty list rather than an error". Distinguishing them needs a second account with an event in it, and until somebody has one, ihasmail assumes the pessimistic reading everywhere it matters: a participant it cannot read is drawn as unknown rather than as free.

 - **An override can move an occurrence, and then `start` and `recurrenceId` mean two different times.** The slot stays where the rule put it and only the clock time moves. **Confirmed live on 0.16.20 (2026-08-31)**: one occurrence of a weekly 09:00 series moved to 14:00 came back `start: 2027-06-14T14:00:00` with `recurrenceId` still `2027-06-14T09:00:00`. This is the right behavior and it is the reason `recurrenceId` is the handle ihasmail holds: it is the one name for an instance that survives *both* a renumbering and a move, so a mutation can always be re-resolved from it. Worth recording because the mock got it wrong in the other direction — it overwrote an override's `start` with the slot time, so a moved occurrence did not move, and per-occurrence *time* editing looked broken against the mock and correct against the server. Found by asking a real server rather than by reading the mock, which is the only way this kind of disagreement ever surfaces.
@@ -65,8 +65,8 @@ The long version is [FEATURES.md](FEATURES.md) and
 against 0.16.22; what changed in each release is in
 [KNOWN-ISSUES.md](KNOWN-ISSUES.md).

- **No Stalwart yet?** [ihasmail-oneshot](https://github.com/Coffey-Labs/ihasmail-oneshot) deploys a new Stalwart and ihasmail together on one host, in one command.
- **On Stalwart 0.15?** [stalwart-migrator](https://github.com/Coffey-Labs/stalwart-migrator) upgrades it in place, or stay on the [`stalwart-0.15-support`](https://github.com/Coffey-Labs/ihasmail/releases/tag/stalwart-0.15-support) release.
+- **No Stalwart yet?** [ihasmail-oneshot](https://git.coffeylabs.org/coffey-labs/ihasmail-oneshot) deploys a new Stalwart and ihasmail together on one host, in one command.
+- **On Stalwart 0.15?** [stalwart-migrator](https://git.coffeylabs.org/coffey-labs/stalwart-migrator) upgrades it in place, or stay on the [`stalwart-0.15-support`](https://git.coffeylabs.org/coffey-labs/ihasmail/releases/tag/stalwart-0.15-support) release.

 ## Quick start (Docker)

@@ -77,7 +77,7 @@ docker compose up --build -d
 # → http://localhost:8080 — put a reverse proxy in front for TLS
 ```

-Or pull the published image, `ghcr.io/coffey-labs/ihasmail`. Releases are
+Or pull the published image, `registry.coffeylabs.org/coffey-labs/ihasmail`. Releases are
 weekly, so it is usually a few days behind `main`.

 People sign in with their Stalwart mailbox credentials. **An account with
@@ -3,26 +3,26 @@
 Things ihasmail does not do, and why. An issue number here says where the entry
 came from, not that it is tracked elsewhere — a report can be closed because the
 bug in it was fixed while the larger thing it asked for stays on this page. What
-is genuinely open lives in [the issue tracker](https://github.com/Coffey-Labs/ihasmail/issues);
+is genuinely open lives in [the issue tracker](https://git.coffeylabs.org/coffey-labs/ihasmail/issues);
 the rest is here because the answer is "no", not "not yet".

 See [KNOWN-ISSUES.md](KNOWN-ISSUES.md) for what is built but worth knowing about.

 - **More of Stalwart's directory in Administration.** The Administration menu opens on a dashboard and manages accounts, groups, mailing lists, tenants, roles and domains today — see [FEATURES.md](FEATURES.md#administration). DNS and ACME providers are Stalwart registry objects behind the same permission model, and each is a section to add rather than a design to invent; so is switching a domain's DNS, DKIM or certificate management, which is shown but not yet changed from ihasmail. The dashboard reads a handful of numbers and stops there. Managing queues, reading logs and changing server settings are not planned: they are operating the server, which is Stalwart's own interface's job, not managing the people on it.
 - **Sharing a mail folder.** Stalwart stores the share and never delivers it; see [KNOWN-ISSUES.md](KNOWN-ISSUES.md). Withdrawn until the server does something with it. Sharing files, calendars and address books is unaffected and works.
- **A scheduling view of its own**, for asking "when is everyone free next week?" without an event in hand. The grid itself is built and lives in the event editor — a row per participant, steppable, and clickable to place the event — which is where the question gets asked while you are arranging something. What is not built is the same thing as a destination you can visit with nothing in progress. Came out of [#172](https://github.com/Coffey-Labs/ihasmail/issues/172), which asked for a separate view and is closed by the panel: the reasoning for putting it in the editor is that a separate surface can only ever tell you a time you then retype, whereas one beside the event can set it. It stays here rather than in the tracker because nobody has yet said they want to ask the question on its own.
+- **A scheduling view of its own**, for asking "when is everyone free next week?" without an event in hand. The grid itself is built and lives in the event editor — a row per participant, steppable, and clickable to place the event — which is where the question gets asked while you are arranging something. What is not built is the same thing as a destination you can visit with nothing in progress. Came out of [#172](https://git.coffeylabs.org/coffey-labs/ihasmail-github-archive/issues/172), which asked for a separate view and is closed by the panel: the reasoning for putting it in the editor is that a separate surface can only ever tell you a time you then retype, whereas one beside the event can set it. It stays here rather than in the tracker because nobody has yet said they want to ask the question on its own.
 - **Per-message actions from the message list on a touchscreen.** Reply, Forward and compose-as-new are on the list row's context menu, which is a right-click — and holding a row on a phone starts selection instead, so none of them are reachable there. They are all available inside a thread, which is where the actions on a single message belong; what is missing is the shortcut from the list. Fixing it means deciding what a long press should do when it already means something, which is a bigger question than the actions themselves.
 - Snooze (nothing in JMAP or Stalwart supports it, and ihasmail never stores a password, so nothing could act on a mailbox while you are away)
 - **A translation anybody has checked.** The translations themselves shipped on 2026-08-31 and are no longer on this page: nine of them, alongside English, and the extraction that had always been the hard half is done — see [FEATURES.md](FEATURES.md#interface-language). What is *not* done is the other half, and it is the half that cannot be bought or automated. All nine were produced by AI against standard dictionaries and **not one has been read by anybody who speaks the language**, which is exactly where a bad translation does harm rather than merely looking untidy. They ship marked Beta, with that said in Settings and a link for reporting anything wrong, because shipping them quietly would ask people to trust text nobody has checked. A language loses the Beta mark when a speaker reads it and says so — a deliberate act by a person, not something a coverage percentage earns. If you speak one of them and are willing to read a few hundred strings, that is the single most useful thing anyone could contribute right now.
 - **Right-to-left languages.** Arabic, Hebrew and Persian are held back deliberately, and not for want of translators. RTL is bidi and layout work throughout — mirrored panes, gesture directions, icon sides, the message list's own geometry — and a catalog without it produces a page that is translated and unusable. Adding one is not another entry in the picker.
- **Two-factor sign-in.** Today an account with 2FA must use an app password (see [Quick start](README.md#quick-start-docker)), and Settings › Security offers no way to switch 2FA *on* — only off, for an account that already has it. Supporting a TOTP code directly means implementing OAuth: Stalwart offers the authorization-code and device flows and no password grant, so ihasmail would hand sign-in to Stalwart's own login and come back with a token. That is a better security posture than the sealed password it holds now — a refresh token rather than a credential — but it replaces ihasmail's own sign-in page for those users and may need an OAuth client registered. Came out of [#75](https://github.com/Coffey-Labs/ihasmail/issues/75), which is closed: what was reported there was a sign-in refused with nothing but "Invalid credentials", and that was fixed by saying what is actually happening and pointing at app passwords. The OAuth work it uncovered is tracked here rather than as an open issue, so there is no ticket to watch for it.
+- **Two-factor sign-in.** Today an account with 2FA must use an app password (see [Quick start](README.md#quick-start-docker)), and Settings › Security offers no way to switch 2FA *on* — only off, for an account that already has it. Supporting a TOTP code directly means implementing OAuth: Stalwart offers the authorization-code and device flows and no password grant, so ihasmail would hand sign-in to Stalwart's own login and come back with a token. That is a better security posture than the sealed password it holds now — a refresh token rather than a credential — but it replaces ihasmail's own sign-in page for those users and may need an OAuth client registered. Came out of [#75](https://git.coffeylabs.org/coffey-labs/ihasmail-github-archive/issues/75), which is closed: what was reported there was a sign-in refused with nothing but "Invalid credentials", and that was fixed by saying what is actually happening and pointing at app passwords. The OAuth work it uncovered is tracked here rather than as an open issue, so there is no ticket to watch for it.
 - **Signing and encrypting mail.** *Reading* a signature is built: S/MIME signed mail is checked as it is read, and the signer is remembered so a change is called out — see [Checking a signature](FEATURES.md#checking-a-signature). What is not built is anything that produces a signature or touches ciphertext, and the reason is not Stalwart. This is client work over the message body: JMAP hands over the MIME blob and the rest is ours.

  The blocker is a security model, not code, and it is the same one it has always been. Signing and decrypting need a **private** key in a page served by the same host that would handle it, which runs straight into two things ihasmail says about itself: that it never stores a credential, and that it runs immutably with nowhere to keep one. Verifying needed none of that — the certificate travels inside the message — which is exactly why it could be built first and why it went first.

  **OpenPGP signatures are not checked, and this is a harder problem than it looks.** A PGP signature does not carry the key, so verifying one means having the sender's public key already. ihasmail has no source for it: `x:PublicKey` is the account's *own* registry, and fetching from a keyserver or WKD would tell a third party who you correspond with, which is precisely the leak the image proxy exists to close. A local store of correspondents' keys is possible and is not a small feature; nobody has asked for it yet.

-  *Managing* keys — publishing your own to `x:PublicKey` — has been built twice ([PR #67](https://github.com/Coffey-Labs/ihasmail/pull/67), [PR #285](https://github.com/Coffey-Labs/ihasmail/pull/285)) and withdrawn twice, because a Settings page for keys nothing uses is furniture. That reasoning is now partly spent: something does use a key. But what signature checking uses is the certificate inside the message, not anything in the registry, so publishing your own key remains a feature waiting for a consumer.
+  *Managing* keys — publishing your own to `x:PublicKey` — has been built twice ([PR #67](https://git.coffeylabs.org/coffey-labs/ihasmail-github-archive/issues/67), [PR #285](https://git.coffeylabs.org/coffey-labs/ihasmail-github-archive/issues/285)) and withdrawn twice, because a Settings page for keys nothing uses is furniture. That reasoning is now partly spent: something does use a key. But what signature checking uses is the certificate inside the message, not anything in the registry, so publishing your own key remains a feature waiting for a consumer.

  **Encryption at rest is refused rather than deferred.** Stalwart offers it as `encryptionAtRest`, a field on `x:AccountSettings` beside `description`, `locale` and `timeZone` — there is no `x:EncryptionAtRest` object whatever the docs suggest, and its value is a typed object (`{"@type": "Disabled"}`) rather than a bare string. It is self-service, needs no administrator, and would be easy to offer. It will not be: turning it *off does not decrypt what is already there*. Every message delivered while it was on stays encrypted on disk, readable only by a client holding the private key, so switching it on is a one-way door — and a toggle that reads as "make my mail safer" while quietly being irreversible is the wrong thing to hand an ordinary user.

@@ -29,7 +29,7 @@ services:
      APP_SECRET: ${APP_SECRET:?set APP_SECRET in .env (openssl rand -base64 48)}
      APP_NAME: ${APP_NAME:-ihasmail}
      BASE_PATH: ${BASE_PATH:-}
-      SOURCE_URL: ${SOURCE_URL:-https://github.com/Coffey-Labs/ihasmail}
+      SOURCE_URL: ${SOURCE_URL:-https://git.coffeylabs.org/coffey-labs/ihasmail}
      TRUST_PROXY: "1"
      IMAGE_PROXY: "1"
    volumes:
@@ -280,7 +280,7 @@ export const config = {
   * source, not the one it was forked from -- so anyone deploying a patched
   * ihasmail should point this at their own tree.
   */
-  sourceUrl: env("SOURCE_URL", "https://github.com/Coffey-Labs/ihasmail"),
+  sourceUrl: env("SOURCE_URL", "https://git.coffeylabs.org/coffey-labs/ihasmail"),
  host: env("HOST", "0.0.0.0"),
  port: int("PORT", 8080),
  /**
@@ -49,7 +49,7 @@ export const UI_LANGUAGES: readonly UiLanguage[] = [
 ];

 /** Where to report a bad translation. Beta languages depend on it. */
-export const TRANSLATION_ISSUE_URL = "https://github.com/Coffey-Labs/ihasmail/issues/new?title=Translation%3A%20";
+export const TRANSLATION_ISSUE_URL = "https://git.coffeylabs.org/coffey-labs/ihasmail/issues/new?title=Translation%3A%20";

 export const DEFAULT_UI_LANGUAGE = "en";

@@ -1,5 +1,5 @@
 import { describe, expect, it } from "vitest";
-import { canPlaceFolder, compareFolders, neighbour, placeFolder, siblingsOf } from "../folderOrder";
+import { canPlaceFolder, compareFolders, neighbour, placeFolder, siblingsOf, treeOrder } from "../folderOrder";
 import type { Id, Mailbox } from "@/jmap/types";

 const RIGHTS = { mayRename: true, mayCreateChild: true } as Mailbox["myRights"];
@@ -119,3 +119,23 @@ describe("neighbour", () => {
    expect(neighbour(hidden, "alpha", "up", (m) => m.isSubscribed)).toEqual({ targetId: "junk", placement: "before" });
  });
 });
+
+describe("treeOrder", () => {
+  const ids = (all: Record<Id, Mailbox>) => treeOrder(all).map((m) => m.id);
+
+  it("lists the tree the way the sidebar does, each folder followed by its subfolders", () => {
+    expect(ids(fresh)).toEqual(["inbox", "drafts", "sent", "junk", "trash", "alpha", "work", "clients", "zeta"]);
+  });
+
+  it("follows a saved order rather than A–Z", () => {
+    // #1 on GitLab: the move-to picker kept the old order after the sidebar changed.
+    const ordered = apply(fresh, { zeta: { sortOrder: 10 }, sent: { sortOrder: 20 }, alpha: { sortOrder: 30 }, drafts: { sortOrder: 40 }, junk: { sortOrder: 50 }, trash: { sortOrder: 60 }, work: { sortOrder: 70 } });
+    expect(ids(ordered)).toEqual(["inbox", "zeta", "sent", "alpha", "drafts", "junk", "trash", "work", "clients"]);
+  });
+
+  it("still lists a folder the walk from the top can't reach", () => {
+    const looped = apply(fresh, { work: { parentId: "clients" } });
+    expect(ids(looped)).toHaveLength(Object.keys(looped).length);
+    expect(ids(looped)).toEqual(expect.arrayContaining(["work", "clients"]));
+  });
+});
@@ -25,6 +25,37 @@ function roleRank(m: Mailbox): number {
  return m.role && m.role in ROLE_ORDER ? ROLE_ORDER[m.role]! : Number.MAX_SAFE_INTEGER;
 }

+/**
+ * Every folder, parents before their children and siblings in
+ * `compareFolders` order: the sidebar's order with every folder expanded.
+ * Lists that show all folders at once, like the move-to picker, use this so a
+ * folder sits where the user dragged it rather than where A–Z would put it.
+ *
+ * A folder the walk from the top never reaches (a parent loop the server
+ * should not allow) is appended rather than dropped, so it can still be
+ * picked.
+ */
+export function treeOrder(mailboxes: Record<Id, Mailbox>): Mailbox[] {
+  const byParent = new Map<Id | null, Mailbox[]>();
+  for (const m of Object.values(mailboxes)) {
+    const p = m.parentId && mailboxes[m.parentId] ? m.parentId : null;
+    byParent.set(p, [...(byParent.get(p) ?? []), m]);
+  }
+  for (const list of byParent.values()) list.sort(compareFolders);
+  const out: Mailbox[] = [];
+  const seen = new Set<Id>();
+  const walk = (parent: Id | null) => {
+    for (const m of byParent.get(parent) ?? []) {
+      if (seen.has(m.id)) continue;
+      seen.add(m.id);
+      out.push(m);
+      walk(m.id);
+    }
+  };
+  walk(null);
+  return out.concat(Object.values(mailboxes).filter((m) => !seen.has(m.id)).sort(compareFolders));
+}
+
 /** Every folder under `parentId` (null: the top level), in list order. */
 export function siblingsOf(mailboxes: Record<Id, Mailbox>, parentId: Id | null): Mailbox[] {
  return Object.values(mailboxes)
@@ -5,4 +5,4 @@
 * source. The server says where its own lives, via SOURCE_URL; this is only the
 * fallback for when it has not been asked yet, or has nothing to say.
 */
-export const DEFAULT_SOURCE_URL = "https://github.com/Coffey-Labs/ihasmail";
+export const DEFAULT_SOURCE_URL = "https://git.coffeylabs.org/coffey-labs/ihasmail";
@@ -153,6 +153,30 @@ describe("a message of mine with nobody obvious to reply to", () => {
    const d = await draftFor({ ...MINE, to: [ME], cc: [] } as Email, "reply");
    expect(addrs(d.to)).toEqual([ME.email]);
  });
+
+  it("answers the Reply-To rather than my own desk when nobody else is on it", async () => {
+    /*
+     * A contact form: the site mails itself, From and To both its own address,
+     * and the person who filled the form in is in Reply-To. From alone makes
+     * this look like mine, and the fallback used to reply to me (#415).
+     */
+    const form = { ...MINE, to: [ME], cc: [], replyTo: [{ name: "Michael", email: "[email protected]" }] } as Email;
+    const d = await draftFor(form, "reply");
+    expect(addrs(d.to)).toEqual(["[email protected]"]);
+  });
+
+  it("does the same on a reply all, without cc-ing myself", async () => {
+    const form = { ...MINE, to: [ME], cc: [], replyTo: [{ name: "Michael", email: "[email protected]" }] } as Email;
+    const d = await draftFor(form, "replyAll");
+    expect(addrs(d.to)).toEqual(["[email protected]"]);
+    expect(d.cc).toEqual([]);
+  });
+
+  it("still prefers somebody I actually wrote to over my own Reply-To", async () => {
+    // The Cc is a person; the Reply-To is where answers to me belong.
+    const d = await draftFor({ ...MINE, to: [ME], replyTo: [{ name: null, email: "[email protected]" }] } as Email, "reply");
+    expect(addrs(d.to)).toEqual([BOB.email]);
+  });
 });

 describe("forwarding", () => {
@@ -108,7 +108,7 @@ export function isOccurrence(event: CalendarEvent): boolean {
 * before it is sent — rejected properties throw, inherited ones are reported to
 * the caller — rather than being posted hopefully and believed.
 *
- * [#26]: https://github.com/Coffey-Labs/ihasmail/issues/26
+ * [#26]: https://git.coffeylabs.org/coffey-labs/ihasmail-github-archive/issues/26
 */
 const OCCURRENCE_REJECTED = new Set([
  "baseEventId", "calendarIds", "isDraft", "isOrigin", "utcStart", "utcEnd",
@@ -410,6 +410,19 @@ export const useCompose = create<ComposeState>((set, get) => ({
        // Addressed only to myself, or only in Cc: there is still somebody this
        // is a reply to, and an empty To is not it.
        if (!to.length) { to = cc.length ? cc : withoutOwn(full.cc ?? []); cc = []; }
+        /*
+         * Nobody but me on the message, and a Reply-To pointing somewhere that
+         * is not mine: that address is who this is really from.
+         *
+         * A contact form is the shape of it -- From and To are both the site's
+         * own mailbox, and the person who filled the form in is in Reply-To.
+         * The address test above calls that mine, correctly as far as it goes,
+         * and the fallback then addressed the reply to my own desk (#415).
+         *
+         * After the Cc, not before it: a message I really did send carries my
+         * own Reply-To, and somebody I actually wrote to beats it.
+         */
+        if (!to.length) to = withoutOwn(full.replyTo ?? []);
        if (!to.length) to = uniqueAddresses([...(full.to ?? []), ...(full.cc ?? [])]);
      } else {
        to = uniqueAddresses(full.replyTo?.length ? full.replyTo : (full.from ?? []));
@@ -26,7 +26,7 @@ import { useMail } from "./mail";
 * `ContactCard/set` down they are the same" was always claiming and is now
 * true of.
 *
- * [#173]: https://github.com/Coffey-Labs/ihasmail/issues/173
+ * [#173]: https://git.coffeylabs.org/coffey-labs/ihasmail-github-archive/issues/173
 */
 /**
 * The UIDs an address book already holds.
@@ -101,7 +101,7 @@ export interface DialogChoice {
   * which is what "Discard changes" was, on a guard whose whole purpose is to
   * stop you losing work ([#175]).
   *
-   * [#175]: https://github.com/Coffey-Labs/ihasmail/issues/175
+   * [#175]: https://git.coffeylabs.org/coffey-labs/ihasmail-github-archive/issues/175
   */
  primary?: boolean;
 }
@@ -5,6 +5,7 @@ import { Dialog } from "@/ui/dialog";
 import type { Id, Mailbox } from "@/jmap/types";
 import { t } from "@/lib/i18n";
 import { mailboxDisplayPath } from "@/lib/mailbox/mailboxName";
+import { treeOrder } from "@/lib/mailbox/folderOrder";

 /**
 * @param need which right a folder has to grant to be worth offering.
@@ -24,10 +25,11 @@ export function MailboxPicker({ title, onClose, onPick, exclude, need = "mayAddI
  const [q, setQ] = useState("");
  const [active, setActive] = useState(0);
  const list = useMemo(() => {
-    const all = Object.values(mailboxes)
+    // The sidebar's order, not A–Z by path: a folder dragged into place has to
+    // be found in the same place here.
+    const all = treeOrder(mailboxes)
      .filter((m) => !exclude?.includes(m.id) && m.myRights[need] && (!allow || allow(m.id)))
-      .map((m) => ({ m, path: mailboxDisplayPath(m, mailboxes), pick: () => onPick(m.id) }))
-      .sort((a, b) => (a.m.role === "inbox" ? -1 : b.m.role === "inbox" ? 1 : a.path.localeCompare(b.path)));
+      .map((m) => ({ m, path: mailboxDisplayPath(m, mailboxes), pick: () => onPick(m.id) }));
    const rows: { m: Mailbox | null; path: string; pick: () => void }[] = root ? [{ m: null, path: root.label, pick: root.onPick }, ...all] : all;
    const ql = q.trim().toLowerCase();
    return ql ? rows.filter((x) => x.path.toLowerCase().includes(ql)) : rows;
@@ -224,7 +224,23 @@ export function ThreadView({ threadId, mailboxId, onBack, actions, onNavigate, h
  }, [messages, reply]);

  const subject = messages[0]?.subject || emails[thread?.emailIds[0] ?? ""]?.subject || "(no subject)";
-  const rowIds = thread ? thread.emailIds.filter((id) => emails[id]) : [];
+  /*
+   * What the toolbar acts on: the messages the pane is showing, not the thread
+   * they belong to.
+   *
+   * With conversation view off, opening a message opens that message -- the
+   * list shows it alone, the pane renders it alone, and the buttons above it
+   * said so, because `anyUnread` and the rest already read `messages`. Only the
+   * ids handed to the action still named the whole thread, so Mark as unread,
+   * Move to, Report spam and Delete quietly took every message in it (#414).
+   *
+   * Same fallback as the pane's: an id naming nothing in this thread means the
+   * whole conversation, so the buttons keep matching what is on screen.
+   */
+  const rowIds = useMemo(() => {
+    const loaded = thread ? thread.emailIds.filter((id) => emails[id]).map((id) => ({ id })) : [];
+    return visibleMessages(loaded, messageId).map((m) => m.id);
+  }, [thread, emails, messageId]);
  const anyUnread = messages.some((e) => !e.keywords.$seen);
  const anyStarred = messages.some((e) => e.keywords.$flagged);
  const inJunk = Boolean(mailboxId && mailboxes[mailboxId]?.role === "junk");
@@ -0,0 +1,62 @@
+import { act } from "react";
+import { createRoot, type Root } from "react-dom/client";
+import { afterEach, beforeEach, describe, expect, it } from "vitest";
+import { MailboxPicker } from "../MailboxPicker";
+import { useMail } from "@/store/mail";
+import type { Mailbox, MailboxRole } from "@/jmap/types";
+
+(globalThis as { IS_REACT_ACT_ENVIRONMENT?: boolean }).IS_REACT_ACT_ENVIRONMENT = true;
+
+/**
+ * The move-to picker (v) lists folders in the sidebar's order (#1 on GitLab).
+ *
+ * It used to sort A–Z by path, so a folder dragged into place in the sidebar
+ * turned up somewhere else here. The ordering has its own tests in
+ * lib/mailbox; these check what the dialog actually shows.
+ */
+
+window.matchMedia = ((q: string) => ({ matches: false, media: q, addEventListener() {}, removeEventListener() {} })) as unknown as typeof window.matchMedia;
+
+const rights = { mayReadItems: true, mayAddItems: true, mayRemoveItems: true, maySetSeen: true, maySetKeywords: true, mayCreateChild: true, mayRename: true, mayDelete: true, maySubmit: true };
+const box = (id: string, name: string, parentId: string | null, role: MailboxRole = null, sortOrder = 0): Mailbox => ({
+  id, name, parentId, role, sortOrder, totalEmails: 0, unreadEmails: 0, totalThreads: 0, unreadThreads: 0, myRights: rights, isSubscribed: true,
+});
+
+/** Ordered by hand in the sidebar: Zeta dragged to the top, Alpha to the bottom. */
+const MAILBOXES = {
+  inbox: box("inbox", "Inbox", null, "inbox", 10),
+  zeta: box("zeta", "Zeta", null, null, 20),
+  sent: box("sent", "Sent", null, "sent", 30),
+  work: box("work", "Work", null, null, 40),
+  clients: box("clients", "Clients", "work"),
+  trash: box("trash", "Deleted Items", null, "trash", 50),
+  alpha: box("alpha", "Alpha", null, null, 60),
+};
+
+describe("the move-to picker", () => {
+  let host: HTMLDivElement;
+  let root: Root;
+  const rows = () => Array.from(document.querySelectorAll('[role="option"]')).map((r) => r.querySelector(".grow")?.textContent);
+
+  function open(props: Partial<Parameters<typeof MailboxPicker>[0]> = {}) {
+    act(() => root.render(<MailboxPicker title="Move to…" onClose={() => {}} onPick={() => {}} {...props} />));
+  }
+
+  beforeEach(() => {
+    useMail.setState({ mailboxes: MAILBOXES, mailboxesLoaded: true });
+    host = document.createElement("div");
+    document.body.appendChild(host);
+    root = createRoot(host);
+  });
+  afterEach(() => { act(() => root.unmount()); host.remove(); });
+
+  it("lists folders in the order they were dragged into, not A–Z", () => {
+    open();
+    expect(rows()).toEqual(["Inbox", "Zeta", "Sent", "Work", "Work / Clients", "Deleted Items", "Alpha"]);
+  });
+
+  it("keeps that order for the folders left after excluding one", () => {
+    open({ exclude: ["work"] });
+    expect(rows()).toEqual(["Inbox", "Zeta", "Sent", "Work / Clients", "Deleted Items", "Alpha"]);
+  });
+});
@@ -0,0 +1,128 @@
+import { act } from "react";
+import { createRoot, type Root } from "react-dom/client";
+import { afterEach, beforeEach, describe, expect, it, vi } from "vitest";
+import { ThreadView } from "../ThreadView";
+import { useMail } from "@/store/mail";
+import type { ListActions } from "../MessageList";
+import type { Email, Id } from "@/jmap/types";
+
+(globalThis as { IS_REACT_ACT_ENVIRONMENT?: boolean }).IS_REACT_ACT_ENVIRONMENT = true;
+
+/* jsdom has neither of these, and the opening scroll uses both. */
+Element.prototype.scrollIntoView = () => {};
+globalThis.ResizeObserver ??= class { observe() {} unobserve() {} disconnect() {} } as unknown as typeof ResizeObserver;
+
+/* jsdom has no matchMedia, and the toolbar asks whether this is a phone. */
+window.matchMedia = ((q: string) => ({ matches: false, media: q, addEventListener() {}, removeEventListener() {} })) as unknown as typeof window.matchMedia;
+
+/*
+ * Reported from the inbox with conversation view off: marking a message unread
+ * from the list -- hover button, right-click menu -- touched that message, but
+ * the same action from the toolbar above the *opened* message marked every
+ * message in its thread. Move to, Report spam and Delete did it too (#414).
+ *
+ * The toolbar's labels were already right: "Mark as unread" read the messages
+ * on screen. Only the ids it handed the action named the whole thread.
+ */
+
+const msg = (id: Id, subject: string): Email =>
+  ({
+    id, threadId: "t1", subject, mailboxIds: { inbox: true }, keywords: { $seen: true },
+    from: [{ name: "Ann", email: "[email protected]" }], to: [{ name: "Me", email: "[email protected]" }],
+    receivedAt: "2026-09-20T10:00:00Z", size: 10, blobId: "b1", preview: "hi",
+    htmlBody: [], textBody: [{ partId: "1", type: "text/plain" }],
+    bodyValues: { "1": { value: "hi", isEncodingProblem: false, isTruncated: false } },
+    attachments: [],
+  }) as unknown as Email;
+
+const FIRST = msg("m1", "The question");
+const SECOND = msg("m2", "Re: The question");
+
+function stubStore() {
+  useMail.setState({
+    accountId: "a1",
+    threads: { t1: { id: "t1", emailIds: ["m1", "m2"] } } as never,
+    emails: { m1: FIRST, m2: SECOND } as never,
+    fullIds: { m1: true, m2: true } as never,
+    loadingThreads: {} as never,
+    mailboxes: { inbox: { id: "inbox", name: "Inbox", role: "inbox" } } as never,
+    loadThread: (async () => undefined) as never,
+    setOpenThread: (() => undefined) as never,
+    markRead: (async () => undefined) as never,
+    roleId: (() => null) as never,
+  });
+}
+
+describe("what the toolbar above an opened message acts on", () => {
+  let host: HTMLDivElement;
+  let root: Root;
+  let actions: ListActions;
+
+  const show = async (messageId: Id | null) => {
+    await act(async () => {
+      root.render(
+        <ThreadView
+          threadId="t1" mailboxId="inbox" messageId={messageId} actions={actions}
+          onBack={() => undefined} onNavigate={() => undefined} hasPrev={false} hasNext={false}
+        />,
+      );
+    });
+  };
+
+  /** The toolbar buttons carry their shortcut in the title, as the tooltips show. */
+  const press = async (title: string) => {
+    const btn = [...host.querySelectorAll("button")].find((b) => b.title === title);
+    expect(btn, `no toolbar button titled ${title}`).toBeTruthy();
+    await act(async () => btn!.click());
+  };
+
+  beforeEach(() => {
+    stubStore();
+    actions = {
+      archive: vi.fn(async () => undefined), trash: vi.fn(async () => undefined),
+      spam: vi.fn(async () => undefined), read: vi.fn(async () => undefined),
+      star: vi.fn(async () => undefined), move: vi.fn(async () => undefined),
+      label: vi.fn(async () => undefined),
+    } as unknown as ListActions;
+    host = document.createElement("div");
+    document.body.appendChild(host);
+    root = createRoot(host);
+  });
+
+  afterEach(async () => {
+    await act(async () => root.unmount());
+    host.remove();
+  });
+
+  it("marks only the message that is open, not its thread", async () => {
+    await show("m1");
+    await press("Mark as unread");
+    expect(actions.read).toHaveBeenCalledWith(false, ["m1"]);
+  });
+
+  it("moves, reports and deletes only that message too", async () => {
+    await show("m1");
+    await press("Move to (v)");
+    await press("Report spam (!)");
+    await press("Delete (#)");
+    expect(actions.move).toHaveBeenCalledWith(["m1"]);
+    expect(actions.spam).toHaveBeenCalledWith(["m1"]);
+    expect(actions.trash).toHaveBeenCalledWith(["m1"]);
+  });
+
+  it("takes the whole thread when the pane is showing the whole thread", async () => {
+    // Conversation view on: no message singled out, and the toolbar is the
+    // conversation's toolbar. That is the behaviour this must not disturb.
+    await show(null);
+    await press("Mark as unread");
+    expect(actions.read).toHaveBeenCalledWith(false, ["m1", "m2"]);
+  });
+
+  it("falls back to the thread when the open id names nothing in it", async () => {
+    // A link from somebody with conversation view on, or a stale `m` in the
+    // URL. The pane shows the conversation, so the toolbar acts on it.
+    await show("gone");
+    await press("Mark as unread");
+    expect(actions.read).toHaveBeenCalledWith(false, ["m1", "m2"]);
+  });
+});
Author	SHA1	Message	Date
jcoffey-dev	31f5e0627b	Merge pull request 'Point links at the new git host' (#13 ) from fix/links-after-move into main ci / version (push) Skipped Details ci / node (push) Successful in 2m40s Details ci / publish (push) Skipped Details ci / docker-build (push) Successful in 43s Details	2026-09-22 16:09:55 +00:00
jcoffey-dev	76cc2dee56	Point links at the new git host ci / node (pull_request) Successful in 4m42s Details ci / publish (pull_request) Skipped Details ci / version (pull_request) Skipped Details ci / docker-build (pull_request) Successful in 1m13s Details GitHub went dark with the account suspension on 2026-09-20 and GitLab was retired on 2026-09-22, so links to either no longer resolve. Repository, file, release and download links now point at git.coffeylabs.org, images at registry.coffeylabs.org, and old GitHub issue and pull request links at coffey-labs/ihasmail-github-archive, whose numbers match GitHub's.	2026-09-22 09:02:57 -07:00
jcoffey-dev	5ef874e0a6	Merge pull request 'ci: run socket-free jobs on the light label' (#12 ) from ci/light-runner into main ci / publish (push) Skipped Details ci / docker-build (push) Successful in 34s Details ci / version (push) Skipped Details ci / node (push) Successful in 2m28s Details	2026-09-22 13:58:09 +00:00
jcoffey-dev	d215d4e258	ci: run socket-free jobs on the light label ci / version (pull_request) Skipped Details ci / docker-build (pull_request) Successful in 1m32s Details ci / node (pull_request) Successful in 2m35s Details ci / publish (pull_request) Skipped Details Both runners carry `light` (host1, and host2 over the wg-hosts link), so these jobs run on whichever host is free. Jobs that mount the docker socket keep `runs-on: docker`, which only host1 has.	2026-09-22 06:45:35 -07:00
jcoffey-dev	4a032ceed7	Merge branch 'ci/gitea-actions' into 'main' ci / version (push) Skipped Details ci / node (push) Successful in 5m38s Details ci / publish (push) Skipped Details ci / docker-build (push) Successful in 3m3s Details ci: add Gitea Actions workflow See merge request coffey-labs/ihasmail!10	2026-09-22 00:52:10 -07:00
jcoffey-dev	d7be002c19	ci: fail clearly when PACKAGE_TOKEN is missing ci / version (pull_request) Skipped Details ci / node (pull_request) Successful in 6m12s Details ci / publish (pull_request) Skipped Details ci / docker-build (pull_request) Successful in 2m51s Details ci / version (push) Successful in 2m31s Details ci / node (push) Successful in 2m59s Details ci / docker-build (push) Skipped Details ci / publish (push) Successful in 8m0s Details	2026-09-21 23:20:47 -07:00
jcoffey-dev	67aab8015a	ci: add Gitea Actions workflows ported from .gitlab-ci.yml ci / version (pull_request) Skipped Details ci / node (pull_request) Successful in 4m46s Details ci / publish (pull_request) Skipped Details ci / docker-build (pull_request) Successful in 3m19s Details ci / version (push) Successful in 2m23s Details ci / node (push) Successful in 2m51s Details ci / docker-build (push) Skipped Details ci / publish (push) Failing after 32s Details	2026-09-21 22:48:55 -07:00
jcoffey-dev	6484645a04	Merge branch 'ci/registry-token-host' into 'main' Fetch the registry token from the public address, not the runner's See merge request coffey-labs/ihasmail!9	2026-09-21 18:20:47 -07:00
jcoffey-dev	795fe43cec	Fetch the registry token from the public address, not the runner's The builder on the host's network (the last change here) didn't help: the next publish failed exactly as before. Looking on the host showed why. Both builders resolve git.coffeylabs.org publicly; the token isn't fetched by the builder at all. buildx fetches registry tokens on the client side, in the job container, and on ci-net the name git.coffeylabs.org belongs to the gitlab container itself (172.30.0.2) -- which is how the runner clones over plain HTTP, and which has nothing on 443. So every push asked https://git.coffeylabs.org/jwt/auth for a token and was refused. The login before it worked because the host's daemon does the login, and the host resolves the name publicly. For the publish job only, the name now points at its public address in the job's /etc/hosts, looked up from a public resolver, as the host sees it. /etc/hosts wins over Docker's DNS, and nothing else in the job is affected: the checkout is done, and image layers go to the registry's own DNS-only name, not this one. The builder goes back to the shared ci-builder; its network was never the problem. The lookup and the /etc/hosts write were tried in the job's own image (docker:28-cli, same digest): it picks the first public IPv4 address and getent then returns it.	2026-09-21 16:48:47 -07:00
jcoffey-dev	31ab2284ed	Merge branch 'ci/buildx-host-network' into 'main' Publish with a builder on the host's network See merge request coffey-labs/ihasmail!8	2026-09-21 16:34:14 -07:00
jcoffey-dev	8acb1b66ad	Publish with a builder on the host's network The v2026.9.20 publish (job 513) built both platforms, then failed to push: failed to fetch oauth token: Post "https://git.coffeylabs.org/jwt/auth": dial tcp 172.30.0.2:443: connect: connection refused buildx's docker-container builder is a container of its own on the host's daemon, and it does the push, token and all. On the network it was created on, git.coffeylabs.org resolves to an internal address with nothing listening on 443. The job's own `docker login` worked because it goes through the host daemon. inbuxa-admin's first release failed the same way. The builder now runs on the host's network, so it resolves the name as the login does. Only the token request goes to git.coffeylabs.org; image layers still go to registry.coffeylabs.org, the registry's DNS-only name. It gets a new name, ci-builder-host: `ci-builder` is a long-lived container shared between jobs, and `create \|\| use` would keep reusing it on its old network.	2026-09-21 16:31:15 -07:00
jcoffey-dev	e9ff2a1e9c	Merge branch 'fix/move-picker-folder-order' into 'main' List folders in sidebar order in the move-to picker Closes #1 See merge request coffey-labs/ihasmail!7	2026-09-21 09:07:13 -07:00
jcoffey-dev	ea03406646	List folders in sidebar order in the move-to picker The picker sorted folders A-Z by path, with Inbox first, so a folder dragged into place in the sidebar turned up somewhere else when moving mail. It now walks the tree in compareFolders order, the sidebar's order with every folder expanded: Inbox, then the saved order, then the special folders, then A-Z, with subfolders under their parent. treeOrder lives beside compareFolders. A folder the walk from the top cannot reach is appended rather than dropped, so it stays pickable as it was before. Closes #1	2026-09-21 08:25:58 -07:00
jcoffey-dev	5b353d1e54	Merge branch 'ci/safe-directory' into 'main' Let root jobs use a checkout the node job chowned See merge request coffey-labs/ihasmail!6	2026-09-20 23:31:59 -07:00
jcoffey-dev	bb133b88e1	Let root jobs use a checkout the node job chowned The build directory is reused between jobs, and the node job chowns it to the unprivileged node user for its tests. A later job running git as root then finds the checkout owned by someone else and git refuses with "detected dubious ownership" (exit 128). Which cached directory a job lands on decides whether it happens, so it is intermittent: the first weekly release dry run passed and the second failed. The version job in the tag pipeline runs git as root too, so the same refusal would have stopped a release from ever publishing its image. Both jobs now mark the project directory safe before touching git.	2026-09-20 23:29:19 -07:00
jcoffey-dev	5fc63068b0	Merge branch 'ci/weekly-release-tagcheck' into 'main' Look tags up by exact ref in the weekly release See merge request coffey-labs/ihasmail!5	2026-09-20 23:23:42 -07:00
jcoffey-dev	874d25a40c	Look tags up by exact ref in the weekly release The dry run reported tag v2026.9.20-gc927c69 as existing when it did not. On the git in the job image (2.39), rev-parse --verify refs/tags/<name> falls back to reading a name ending in -g<hex> as git-describe output, and resolves it to that commit. Every commit not merged through a pull request gets a -g<hex> version, so every such week would have been skipped as already released -- silently, since skipping is a normal outcome. show-ref --verify matches an exact ref and nothing else. Both tag checks use it now. release.yml has the same code; it only worked because GitHub's runners carry a newer git that does not fall back.	2026-09-20 23:20:59 -07:00
jcoffey-dev	c927c69fe2	Merge branch 'ci/weekly-release' into 'main' Cut the weekly release on GitLab See merge request coffey-labs/ihasmail!4	2026-09-20 23:16:36 -07:00
jcoffey-dev	0e63c5d9c9	Cut the weekly release on GitLab release.yml stopped running with the GitHub account, and nothing replaced it: no tag has been cut since, so the publish job had nothing to build. This ports its decision unchanged -- release only when main has commits since the newest published release, and only if the tag does not already exist -- to a job run by a Monday 09:17 UTC pipeline schedule. The schedule lives on the project and sets RELEASE_WEEKLY=1; DRY_RUN=1 stops after the decision. The release, and so the tag, is created with a project access token rather than the job token. That makes the tag an ordinary push, which starts the tag pipeline and its publish job, replacing release.yml's direct call of publish.yml. The checks are skipped in the release pipeline, as they were on GitHub: main has already passed them.	2026-09-20 23:14:17 -07:00
jcoffey-dev	b6f73624b1	Merge branch 'images/registry' into 'main' Point image references at the new registry See merge request coffey-labs/ihasmail!3	2026-09-20 22:55:24 -07:00
jcoffey-dev	2c6df11e4b	Point image references at the new registry ghcr.io went dark with the GitHub account, so every `docker pull` and template that named it has been failing. The images are republished, multi-arch as before, at registry.coffeylabs.org under the same names, and pull anonymously -- nothing needs a login. Where a link pointed at an issue list, it now goes to /-/work_items: in GitLab 19 that is the public list, and /-/issues returns 404 to anyone not signed in. Issues themselves did not come across from GitHub, so a link to a specific old issue is replaced with a note saying where it was.	2026-09-20 22:49:00 -07:00
jcoffey-dev	171b399e01	Merge branch 'ci/image-version' into 'main' Build published images with the version they report See merge request coffey-labs/ihasmail!2	2026-09-20 22:27:14 -07:00
jcoffey-dev	540554c111	Build published images with the version they report publish.yml passed the computed version into the image build, and the first port of it to GitLab CI did not. A tag pushed with that port would have shipped an image reporting itself unversioned (or, for ihasvpn, with a stray leading "v" no earlier build had), and tagged it with the git tag rather than the version string. The version is now computed the way publish.yml computed it and passed as the build arg, and the image is tagged with it, '+' turned into '-' where a Docker tag needs that.	2026-09-20 22:19:17 -07:00
jcoffey-dev	7453484280	Merge branch 'ci/gitlab-pipeline' into 'main' Run CI on the self-hosted GitLab See merge request coffey-labs/ihasmail!1	2026-09-20 20:04:16 -07:00
jcoffey-dev	2441e47390	Give CI jobs IPv6 rather than a Node flag that did not help The proxy test failed with ECONNREFUSED on 127.0.0.1 for a server bound to ::1. That is not resolution order, so --dns-result-order was treating the wrong cause and is removed: with no non-loopback IPv6 address on the container, getaddrinfo's AI_ADDRCONFIG drops ::1 from the results altogether and localhost can only ever come back IPv4. The runner now puts jobs on a docker network created with --ipv6, which is where the fix belongs. Verified by reproducing the failure on the old network and watching it pass on the new one.	2026-09-20 20:00:31 -07:00
jcoffey-dev	6e23c14132	Make the CI job environment match what the tests assume Three tests failed on the runner and pass locally, all because the job container differs from a workstation rather than because anything regressed: config.test.ts chmods a directory and expects the write to be refused, which root ignores; imageproxy.test.ts binds to ::1 and asks for localhost, which resolves to IPv4 first here; and version.test.ts shells out to git, which the slim image does not ship. So the job installs git, runs the suite as the image's unprivileged node user, and asks Node for the address order the proxy test was written against. No test changed.	2026-09-20 19:55:43 -07:00
jcoffey-dev	6bfd105ad2	Run CI on the self-hosted GitLab GitHub Actions stopped being reachable when the account was suspended, so this ports ci.yml and publish.yml to a .gitlab-ci.yml running on a group runner on Web_Host. The Actions workflows stay in the tree: they are the reference this was written from, and they work again unchanged if the appeal succeeds. Two differences worth knowing. Images are pinned by digest rather than the workflows' SHA-pinned actions, because GitLab has no action allowlist to back a tag with. And arm64 is built under QEMU instead of on a native runner, which is slow enough that publish is tag-only.	2026-09-20 19:37:18 -07:00
jcoffey	f627bfc123	The toolbar above an open message acts on that message (#414 ) (#417 ) With conversation view off, marking a message unread from the list -- the hover button, the right-click menu -- marked that message. Opening it and pressing Mark as unread in the toolbar above it marked every message in its thread, and so did Move to, Report spam and Delete. The setting already reaches all the way into the reading pane: the list draws one row per message, and `visibleMessages` narrows the pane to the one opened. The toolbar was half converted. Its labels were right -- Mark as unread against Mark as read, the star, the labels shown -- all of those read `messages`, which is the narrowed set. Only `rowIds`, the one thing actually handed to the action, still read `thread.emailIds`. So the button said one message and did the whole conversation. `rowIds` is now the same question `visibleMessages` answers for the pane, asked of the same ids, with the same fallback: an id that names nothing in the thread -- a link from somebody with conversation view on, a stale `m` in the URL -- shows the conversation, so the toolbar takes the conversation. Conversation view on is unchanged: nothing is singled out, so the whole thread comes back as before. No new strings.	2026-09-20 14:53:45 -07:00
jcoffey	01dc322aeb	A reply to a self-addressed message follows its Reply-To (#415 ) (#416 ) A website contact form mails the site's own address: From and To are both info@thesite, and the person who filled the form in is in Reply-To. Replying addressed the draft to info@thesite -- the site's own desk -- instead of to them. The reply already knows two shapes. A message somebody sent me is answered to its Reply-To, which is what that header is for. A message I sent is answered to the people I wrote to, and deliberately not to my own Reply-To, which is where answers to me belong and would send my reply to myself. A contact form passes the test for the second: every address in From is mine. So it fell down the chain the second shape keeps for a message with nobody obvious to answer -- To without me, then Cc, then, having run out, every address on the message, which here was mine alone. The Reply-To now goes in that chain, one step before the last: when no recipient but me is left and the message names a Reply-To that is not mine either, that address is who it is really from. Keeping it after the Cc is what leaves a message I did send alone -- somebody I actually wrote to still beats my own Reply-To, which is the case the existing guard was built for and its test still holds. No new strings.	2026-09-20 14:50:48 -07:00