ohmail 0.9.8

If you are on 0.9.7, download and install this by hand

0.9.7 quits a few seconds after you open it, on every platform, every launch. This release fixes
that. The crash happens before the app reaches its own update check, so a copy of 0.9.7 can never
fetch this release for itself — there is no version of waiting that works. Download the installer
for your platform below and install it over what you have. Your mail, your account and your settings
live in your data directory, not in the app, and reinstalling does not touch them.

On 0.9.6 or earlier, nothing is required of you. Those builds reach their update check normally
and will offer this release the way they always have. Only 0.9.7 is stranded, and only because it
cannot stay running long enough to ask.

The launch crash

• The app no longer quits at launch over the window's link and attachment permissions. 0.9.7
  granted the window two commands — "open this link in your browser" and "open this attachment" —
  without declaring either of them in the build's own manifest of what the app is allowed to do. The
  framework resolves a window's permissions against that manifest while the window is being created,
  and a permission it cannot find there is a failure it does not return from: these builds abort the
  process instead. So the failure was total and immediate rather than partial and quiet, the same on
  macOS, Windows and Linux, and unaffected by anything in your mailbox or your settings.
• Both commands are now declared, and the grant is checked before the framework is asked for
  anything: a permission the compiled manifest cannot resolve is dropped and named in the engine log
  rather than handed over to be aborted on. A failed grant is also no longer treated as fatal — a
  window short one command still draws, still has its menus, and still reaches the update feed. That
  last property is what decides whether a release like this one can be delivered at all, so it is now
  a behaviour with a test on it rather than a hope.

Mail on your own server

• A folder is no longer reported as fully downloaded when the server quietly held a message back.
  A mail server may answer a request for a batch of messages with fewer messages than were asked for,
  with no error and nothing marking which are missing. The download pass did not check: it compared
  what came back against its own size limits, found neither reached, and concluded the folder had
  drained — so a withheld message produced nothing at all, and the folder marker moved past it as
  though it had arrived. A folder in that state looks finished to everything downstream, including
  the mark that says a mailbox's first import is done.
• What triggers it is a header the sender chose. A message identifier may legally be written as a
  quoted string, and at least one large provider cannot assemble its summary reply for such a message,
  so it omits the row rather than failing the command. Checked against a live account one command at
  a time: search, flags, size, date and the full body all return the message. Only the summary does
  not.
• Because the body is available, the message is recovered rather than lost. Both download paths now
  compare what came back against what they asked for and re-issue the shortfall without the summary,
  reading the message identifier out of the raw headers instead. Anything still unanswered gets a
  durable record written before any folder marker moves, and the marker is held where it is if that
  record cannot be written. The targeted retry path had the same fault with a worse ending — it
  treated a skipped message as deleted from the server — and is fixed with it.

---

Full detail in the changelog.