On Thu, Jan 29, 2026 at 11:40:47AM +0800, Kevin J. McCarthy wrote:
On Wed, Jan 28, 2026 at 01:13:19PM +0100, Vincent Lefevre wrote:
On 2026-01-28 11:30:47 +0800, Kevin J. McCarthy wrote:
Maybe this brings us full circle, to either leaving things as they are, or
trying out the reverse line scanner to compensate for verbose return paths,
and not worrying about the crazier example given. Thoughts, everyone?
Perhaps accept only the strict format by default and have an option
to accept any line starting with "From " as a separator?
How about: with the option set, as long as it's preceded by an empty
line which isn't a header separator, and (of course) isn't inside a
content-length delimited message, the option will accept any "From ".
The only danger is the Emacs Lisp reader that Kurt mentioned. But
since the option won't be set by default, the user can always just turn
it back off.
Moreover, I think that in the cases where a "From " line is required
during parsing (e.g. at the start of a mbox file or at a position
obtained from the Content-Length of the previous message), it is
always safe to accept any "From " line format (instead of giving
an error saying that the mailbox is corrupted).
Okay.
expect_from_line is turned on at the beginning of the parse, and after
a content-length delimited message.
has_mbox_sep is set in non-content-length delimited messages when an
empty line is in the body (the headers and header separator are read in
by mutt_read_rfc822_header, so won't be checked as such).
So we could turn on "From " only mode:
if expect_from_line || (lax_option_set && has_mbox_sep)
turn on "From " only mode
else
is_from_reverse_scan() required to be considered a "From " line.
Did I understand you correctly? Kurt what do you think?
Don't know yet. Couple things though.
I'm leery of making reading mbox configurable. This stuff is low-level,
arcane, and dangerous -- could silently lose messages. Also, making it
configurable at least doubles the amount of testing needed.
Does has_mbox_sep mean it found an empty line after the message? If so,
I'd like a different name, maybe found_mbox_msg_terminator or
something, to make it clear it's not the From_ line. (Also, there's an
empty line after every message in the file, including the last, so it's
technically not a separator.)
I've found Content-Length: (and Lines:) to be somewhat unreliable. When
it's wrong, often it's just off by one line, but sometimes it's worse.
(I have some statistics around here somewhere.) I suspect some of it is
bugs, and some is when a message is modified but the lengths are not
updated, because they're non-standard and not known by all software.
I've seen them apparently not get updated by mailing list software that
adds a footer to every message.
Is Mutt a little skeptical about those lengths?
