CVE-2026-67447

## Summary Mailpit's SMTP DATA reader enforces the configured `MaxMessageSize` only after `bufio.Reader.ReadBytes('\n')` has already buffered a complete DATA line. A remote unauthenticated SMTP client can send one line larger than the configured message-size cap and force memory allocation before Mailpit returns the expected `552 5.3.4` rejection, leaving patched versions still exposed to a single-line incomplete-fix variant of the earlier SMTP DATA body-size issue. ## Technical Details Mailpit enables SMTP by default. The SMTP server now wires `config.MaxMessageSize` into `srv.MaxSize`: ```go if config.MaxMessageSize > 0 { srv.MaxSize = config.MaxMessageSize * 1024 * 1024 } ``` The DATA reader then checks that cap, but only after reading a full newline-terminated line into memory: ```go line, err := s.br.ReadBytes('\n') if err != nil { return nil, err } if bytes.Equal(line, []byte(".\r\n")) { break } if line[0] == '.' { line = line[1:] } if s.srv.MaxSize > 0 { if len(data)+len(line) > s.srv.MaxSize { _, _ = s.br.Discard(s.br.Buffered()) return nil, maxSizeExceeded(s.srv.MaxSize) } } ``` This ordering violates the size-limit invariant. The configured cap can reject the message only after the attacker has supplied the line terminator and `ReadBytes('\n')` has allocated the over-limit line. With the default 50 MiB cap, a 64 MiB single DATA line is still buffered before Mailpit returns `552 5.3.4 Requested mail action aborted: exceeded storage allocation (52428800)`. This is related to the older SMTP DATA body-size advisory, but it is a post-fix gap: `srv.MaxSize` is now assigned, and normal multi-line DATA accumulation is bounded. The remaining issue is that one individual DATA line is not bounded before buffering. ## PoV The following reduced proof starts a local Mailpit release binary, sends a small DATA message as a negative control, then sends one 64 MiB DATA line without an intermediate newline. It samples proce