>> 1) What is happening to that email when you run mhfixmsg on it? > >The mail in question (i.e. with ^M at end of every line, both headers >and body) ends up with nothing but a single instance of the mime >boundary in the body of the mail. i.e >---- >HEAD > >MIME-BOUNDARY
Huh, the HEADERS have ^M on them? To expand a bit ... there is a bit of subtlty here when it comes to RFC 5322 messages and nmh, specifically when it comes to line endings. Officially, the line ending characters for RFC 5322 messages is \r\n. But the line ending for Unix text files is \n. How this actually ends up working in practice is that the Unix MUA converts \r\n to \n and ends up writing a file with \n where nmh can grab it. In the specific case of POP, we know that the lines end in \r\n and do the conversion ourselves. For SMTP, the reverse happens; we convert from \n to \r\n when talking to the SMTP server, or if we are just opening a pipe to sendmail we just send \n and the sendmail program takes care of that for us. Where life gets interesting is that text parts that are base64 encoded should have line endings of \r\n. We didn't use to deal with that, but AFAIK we should be okay with that. But having _headers_ that have line endings of \r\n is wrong, at least according to what nmh is expecting and I could see how that might cause a problem. How did that email end up getting incorporated into the nmh mail store? --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
