email_read can return a text attachment instead of the actual message body

[Calmingstorm]

Confirmed bug

Reviewed master at 886c36d8ebe861aa987059a1744d45b78797baae (v4.7.0). Suggested priority: P2.

Email body extraction compares the entire Content-Disposition header with the literal string attachment. Normal MIME attachments include parameters, for example attachment; filename="notes.txt". Such a part passes the filter and can be returned as the message body, hiding the actual message.

Source and reachability

• Plain-text and HTML selection predicates
• read_email assigns the result to body

Isolated reproduction

Parse a multipart/mixed message containing, in order:

1. A text/plain part with Content-Disposition: attachment; filename="notes.txt" and payload ATTACHMENT CONTENT.
2. A non-attachment text/plain part with payload REAL BODY.

Call _extract_body(message, 1000).

Actual:   'ATTACHMENT CONTENT'
Expected: 'REAL BODY'

The standard library parsed a real MIME fixture; no IMAP server or credentials were involved. Independently reproduced. Existing email tests: 39 passed, demonstrating the missing regression case.

Acceptance criteria

• Use parsed, normalized disposition tokens rather than full-header equality for both text/plain and text/html selection.
• Ensure attachment subtrees cannot masquerade as body parts.
• Add fixtures with parameterized attachments before the body and with an HTML body plus a text attachment.
• Keep attachment metadata available separately.

Impact: the agent can summarize or act on the wrong email text. This is a content-correctness bug, not an asserted authorization bypass.

Behavior change: previously misclassified attachment text no longer replaces the message body. No code was changed during this review.

[Calmingstorm]

Fixed in v4.8.0 (PR #405): https://github.com/Calmingstorm/Odin/releases/tag/v4.8.0 — see the release notes for details.