Ciphertext attachment silently dropped for 5-10 MB encrypted mail

[dobby-coder]

What happens

runBeforeSendEncryption only attaches the ciphertext when it is at or below a local 5 MB cap:

https://github.com/encryption4all/postguard-tb-addon/blob/main/src/background/encryption-flow.ts#L279-L288

if (
  result.attachmentBase64 != null &&
  result.attachmentSize <= MAX_ATTACHMENT_SIZE
) { ... addAttachment ... }

By that point the user's original attachments have already been removed from the compose window (encryption-flow.ts:275-277), and the function returns details — so the send proceeds. If the ciphertext is over the cap, the message goes out with no ciphertext attachment, and the originals are gone from the compose window.

Why the cap is reachable

The comment above MAX_ATTACHMENT_SIZE (src/background/encryption-flow.ts:40-42) says it is "a local cap above pg-js's tier-3 cutoff". That is not true for the pinned @e4a/pg-js (^2.1.0):

• pg-js pickTier: tier2 when encryptedBytes <= 10485760, tier3 above that (node_modules/@e4a/pg-js/dist/index.mjs, PG_MAX_ATTACHMENT_SIZE = 10 * 1024 * 1024).
• envelope.attachment is null only for tier3.

So the add-on's cap (5 MB) sits below pg-js's tier-2/3 boundary (10 MB). Any ciphertext in the 5–10 MB band arrives as a tier-2 envelope with a non-null attachment, and the add-on silently drops it.

Consequences

• Tier 2 with a successful Cryptify upload: the body carries a download link, so the recipient can still decrypt — degraded but survivable.
• Tier 2 where the Cryptify upload failed: pg-js logs a warning and falls back to manual upload instructions in the body (createEnvelope, dist/index.mjs around the uploadUuid branch). Combined with the dropped attachment, the recipient gets an encrypted-looking mail containing neither the ciphertext nor a working link, and the sender's originals were already detached. Unrecoverable from the recipient's side.

Suggested fix (small)

In runBeforeSendEncryption, when the attachment exceeds MAX_ATTACHMENT_SIZE:

• If the popup result carries an uploadUuid (the body has a real Cryptify link), dropping the attachment is fine — keep current behaviour.
• Otherwise, do not send: notifyError(...) with a dedicated message key and return { cancel: true } before removing the originals, matching the failure discipline established in User attachments are lost if encryption popup fails or is cancelled postguard-tb-addon#129.

Also correct the stale comment on MAX_ATTACHMENT_SIZE — state that it is below pg-js's 10 MB tier-2/3 boundary and why (SMTP servers that refuse >5 MB), rather than claiming it is above it.

Add unit tests in tests/encryption-flow.test.ts covering both branches (over-cap with uploadUuid, over-cap without). The existing tests around line 68-93 only assert the arithmetic of the comparison, not the send/cancel decision.

[dobby-coder]

/dobby fix — In src/background/encryption-flow.ts, stop silently dropping the ciphertext attachment when it exceeds MAX_ATTACHMENT_SIZE: only skip the attach step when the popup result carries an uploadUuid (the body then has a real Cryptify link); otherwise notify the user and return { cancel: true } before the originals are removed. Also correct the stale comment on MAX_ATTACHMENT_SIZE (5 MB is below pg-js's 10 MB tier-2/3 boundary, not above it), add the i18n message key in public/_locales/en|nl/messages.json, and cover both over-cap branches in tests/encryption-flow.test.ts. Run npm test and npm run typecheck; open a draft PR.

[dobby-coder]

On it! I'm fixing the ciphertext attachment handling in encryption-flow.ts so oversized attachments only get skipped when there's a real uploadUuid/Cryptify link, otherwise the flow notifies the user and cancels before originals are deleted. I'll also fix the stale MAX_ATTACHMENT_SIZE comment, add the new i18n message key in the en/nl locale files, extend the tests for both over-cap branches, and run npm test + npm run typecheck before opening a draft PR.

[dobby-coder]

Parked: this is dobby-initiated work coupled to @rubenhensen, who already has 3 dobby PRs waiting for review (budget: 3). I'm not opening another one until some of those merge or close — comment here to re-trigger dobby once there's room.