Hello. I just stumbled over the fact that mutt turns
From MAILER-DAEMON-nono-0 Wed Oct 2 01:50:07 1996 This is a body, but not a valid message (multiply .. or so .. to create a mulit-member mbox) into a "valid" message. I wonder where this comes from (realizing though that for example git-mailsplit does it likewise). 'Thing is that RFC 4155 is lala, but for example qmail-mbox from ~1996 [curl -I http://qmail.org./man/man5/mbox.html ... Last-Modified: Fri, 28 Jan 2011 21:07:07 GMT ...] says Between the From_ line and the blank line is a message in RFC 822 format, as described in qmail-header(5), subject to >From quoting as described below. where already RFC 822 requires at least Date: and From: (aka "two header fields"), and POSIX states for mailx, OUTPUT FILES, line beginning with From<space> [one or more header fields; see Commands in mailx (on page 3112)] empty line [zero or more body lines empty line] [line beginning with From<space>...] the weaker "one or more header fields". I have to rewrite "my thing" after bailing for a message seen on the 9front list (for which public-inbox and others completely failed; mutt only suppresses several lines because of "faulty header detection", among others (trailing WSP of lots of lines)), and whereas an existing unit test Leading text, what to do with it? From MAILER-DAEMON-nono-0 Wed Oct 2 01:50:07 1996 This is a body, but not a valid message From MAILER-DAEMON-2 Wed Oct 2 01:50:07 1996 ToMakeItHappen: header From MAILER-DAEMON-nono-1 Wed Oct 2 01:50:07 1996 This is a body, but not a valid message, 2 From MAILER-DAEMON-4 Wed Oct 2 01:50:07 1996 One: header From MAILER-DAEMON-nono-2 Wed Oct 2 01:50:07 1996 From MAILER-DAEMON-nono-3 Wed Oct 2 01:50:07 1996 From MAILER-DAEMON-nono-4 Wed Oct 2 01:50:07 1996 And do foolish things From MAILER-DAEMON-6 Wed Oct 2 01:50:07 1996 One: two three is not recognized by mutt, yet after removing leading text we see 1 N Oct 01 MAILER-DAEMON-n ( 1) 2 N Oct 01 MAILER-DAEMON-2 ( 0K) 3 N Oct 01 MAILER-DAEMON-n ( 1) 4 N Oct 01 MAILER-DAEMON-4 ( 0K) 5 N Oct 01 MAILER-DAEMON-n ( 0K) 6 N Oct 01 MAILER-DAEMON-n ( 0K) 7 N Oct 01 MAILER-DAEMON-n ( 1) 8 N Oct 01 MAILER-DAEMON-6 (0.1K) my one sofar gives ▸N 1 MAILER-DAEMON-nono-0 Wed Oct 2 01:50 4/ 93 N 2 MAILER-DAEMON-2 Wed Oct 2 01:50 7/ 166 N 3 MAILER-DAEMON-4 Wed Oct 2 01:50 11/ 238 N 4 MAILER-DAEMON-6 Wed Oct 2 01:50 4/ 62 (I am about to add MIME boundary search mode instead of From_ search if we have a MIME message, as a protection measure of false From_ quoting. Long on my TODO list, and that email beat me to it; though the actual problem was a different one, yet i did not realize that until having a long and deep look.) It is also that, if i fake that very bad email, and change it to (cat -vet): ... Content-Transfer-Encoding: 8bit $ $ From .. a From_ line then mutt splits that into two messages, whereas my own until now says (it gives a lot of complaints, also to the above, btw) Not a header line, skipping: 'From ...' Malformed message: headers and body not separated (with empty line) which is no good since of course it can be "0 or more" body lines, so we should possibly / likely re-enable From_ check even if we are in header follow-up mode. (This would not hurt if MIME boundary check would be used, one reason i want to have that... what i thought at first; note the software is still in bad shape, with two distinct program flows, and that here cannot MIME re-encode a message to what would be necessary according to RFC 4155, but maximally MBOXO quote stuff.) So dunno, but i thought maybe someone is interested of hearing that. Ciao, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
