>I agree RFC 5322 lines are CRLF, but RFC 4155's application/mbox are >just LF, and Unix mbox files from Postfix, etc., are just LF. I don't >think the code should allow /\r?\n/ for all inputs, but I don't think >you're saying it does?
AFAIK, it doesn't. >Is retrieving POP3 emails the only time we should see the CR and it gets >stripped off before the non-POP3 code sees it? When nmh creates a >message/rfc822 it doesn't tack CRs on so presumably they're not meant to >be there on non-nmh incoming ones? If we are just doing a straight message/rfc822, then no, we don't tack a CR on, because we're doing Unix line endings locally. AFAIK, it's only in our interactions with network protocols like SMTP and POP3 that we see CRs because that's the definition. text/* that is encoded as base64 should technically include a CRLF. I BELIEVE I added the code that will convert that Unix line endings upon decode, and reencode it with CRLF (did I? I did! How about that!). >We don't insist on CRLF when receiving RFC 5322, right. Right ... I was just musing that maybe we should. Some people have been recoiling in horror at my attempts to write an RFC-822 address parser in Yacc/Bison. I don't know if that's going to be successful or not; we'll see! But I was thinking of ditching m_getfld() completely and switching it to flex tokenizer. I think that makes a lot of sense, and should be straightforward. If we did that, a regular expression to handle a line ending with \r\n would be trivial. I welcome thoughts about that idea as well. --Ken _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
