M6.5 [P2]: Filter size field is wrong for HTML-only mail #256

New Issue

2026-07-31T14:42:51Z

KofTwentyTwo commented

2026-07-31 14:42:51 +00:00

(Migrated from github.com)

engine.rs:118-124: the size filter field is computed from body_plain.len() only, ignoring body_html and attachments, so it is always 0 for HTML-only messages and silently mis-evaluates any size-based rule. Goal: compute a real message size (plain + html + attachments, or the stored raw size); if a faithful size is not available, scope/document the field meaning precisely rather than leaving it silently wrong. Test HTML-only and attachment cases.

Source: full-tree audit 2026-07-30 (scratchpad/audit/AUDIT-SUMMARY.md). Follow docs/STORY-WORKFLOW.md: engine+proto(if surface)+CLI+offline E2E, mock-only tests, no fabricated data, comment convention, PR to dev, PO reviews before close.

engine.rs:118-124: the size filter field is computed from body_plain.len() only, ignoring body_html and attachments, so it is always 0 for HTML-only messages and silently mis-evaluates any size-based rule. Goal: compute a real message size (plain + html + attachments, or the stored raw size); if a faithful size is not available, scope/document the field meaning precisely rather than leaving it silently wrong. Test HTML-only and attachment cases. Source: full-tree audit 2026-07-30 (scratchpad/audit/AUDIT-SUMMARY.md). Follow docs/STORY-WORKFLOW.md: engine+proto(if surface)+CLI+offline E2E, mock-only tests, no fabricated data, comment convention, PR to dev, PO reviews before close.

KofTwentyTwo commented

2026-08-15 01:33:31 +00:00

(Migrated from github.com)

Fixed in #425 (98b59b8), merged to dev.

size is now defined as the total bytes of stored content — all body parts plus all attachment payloads — and that definition is documented on FilterField::Size. Both body parts are summed because a multipart/alternative message genuinely carries both on the wire, which is exactly the HTML-only case this issue reported.

Full RFC822 octets would be the purist answer but needs a persisted size column, i.e. a schema change; excluding headers and MIME framing makes this a consistent lower bound rather than a guess. There was no prior test coverage for the size field at all, so nothing was weakened to accommodate the change.

Fixed in #425 (`98b59b8`), merged to `dev`. `size` is now defined as the total bytes of stored content — all body parts plus all attachment payloads — and that definition is documented on `FilterField::Size`. Both body parts are summed because a `multipart/alternative` message genuinely carries both on the wire, which is exactly the HTML-only case this issue reported. Full RFC822 octets would be the purist answer but needs a persisted size column, i.e. a schema change; excluding headers and MIME framing makes this a consistent lower bound rather than a guess. There was no prior test coverage for the `size` field at all, so nothing was weakened to accommodate the change.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: KofTwentyTwo/nuncio#256