Skip to content

Bound memory use when reading messages and attachments #26

Description

@bscott

Messages and attachments are read fully into memory with no size limit.

Sites:

  • internal/imap/client.goGetMessage fetches the entire raw body; DownloadAttachment reads the whole part via io.ReadAll
  • internal/cli/mail.goparseAttachments parses every attachment out of the raw body at once; DraftCreateCmd reads stdin unbounded
  • internal/smtp/client.go — outgoing attachments are read whole, base64-encoded into a second buffer, then accumulated in a bytes.Buffer for the multipart message

A large message or attachment is therefore bounded by available RAM rather than by anything configurable, and the SMTP send path holds roughly three copies at peak.

Only mail batch input is capped today (10 MB, in internal/cli/batch.go).

Low severity: exploiting it requires someone to send a very large message, and the impact is a failed command rather than compromise. Recorded as an accepted risk in docs/security-review.md for 0.2.6 rather than fixed, since a proper fix means streaming rather than a constant.

Streaming the SMTP attachment path would be the highest-value part, since it is the one that multiplies the data.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions