[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] mhfixmsg on a pathological mail

From: Ken Hornstein
Subject: Re: [Nmh-workers] mhfixmsg on a pathological mail
Date: Fri, 18 Aug 2017 13:19:22 -0400

>> 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

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]