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
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers