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

[Håkon Alstadheim]

Den 18. aug. 2017 19:19, skrev Ken Hornstein:
>>> 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?

Confirmed, they all have ^M. Note that I'm probably abusing mhfixmsg, as
I am trying to run it on my server at reception time, before storing the
mail in IMAP. I'll just keep it to my own account for now, removing \r
before and adding \r after processing. :/



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