Re: [Nmh-workers] warning when attaching rfc822 message
>> Anything else before we branch 1.6? > >Nope, go for it. It's late, I'm tired ... I'm thinking tomorrow. So if people have some additional stuff you want in there, speak up soon! --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] warning when attaching rfc822 message
> Anything else before we branch 1.6? Nope, go for it. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] warning when attaching rfc822 message
>It looks like nothing had been called to set c_encoding before >InitMessage() is called. I suspect that we're seeing this now >because attach used to use text/plain or application/octet-stream >in the past, but now it's using message/rfc822. Okay, looks like this has been fixed (the problem with the lack of filename in mhbuild errors, the error message when attaching a message/rfc822, and the encoding CTE is now correct if the inner MIME content has 8bit characters). Anything else before we branch 1.6? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] warning when attaching rfc822 message
Apropros to nothing, when fixing this up I found the following code in mhbuildsbr.c: case CE_8BIT: if (ct->c_type == CT_MESSAGE) adios (NULL, "internal error, invalid encoding"); Which actually seems mega-bogus to me. This was not in the original MH code, so it seems to be by Richard Coleman. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] warning when attaching rfc822 message
>> Is there any harm nowadays >> in saying that a 7bit message is 8bit? You could be forcing a transport or message store into extra work, causing it to perform an un-necessary encoding pass. This really just sounds like laziness. It's easy to get it right to begin with. Just do it right. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] warning when attaching rfc822 message
>> Okay, so I looked at this. It looks like the simplest thing to do >> is make init_decoded_content() set a default CTE (probably 7bit is >> appropriate). > >But 8bit would be safe more often. Is there any harm nowadays >in saying that a 7bit message is 8bit? I do not believe so. But it feels ... inelegant to me. The closest the RFCs get to saying anything about it from section 6.2: The proper Content-Transfer-Encoding label must always be used. Labelling unencoded data containing 8bit characters as "7bit" is not allowed, nor is labelling unencoded non-line-oriented data as anything other than "binary" allowed. But the definition of "8bit" encompasses 7bit, and I cannot find anything that recommends against always using 8bit (unlike, say, labelling US-ASCII characters always as UTF-8). But there is already a framework in scan_content() to check for that, so it's easy to fix it. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] warning when attaching rfc822 message
On Apr 13, 2014, at 6:29 PM, Earl Hood wrote: > 7bit, 8bit, and binary are allowed for message/rfc822. No other > encoding is allowed: This could be an old IMAP nightmare coming back to haunt me. 3501 didn't allow a fully-transparent data path, so binary encoded messages are a bit of a pain to deal with. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] warning when attaching rfc822 message
On Sun, Apr 13, 2014 at 7:55 PM, Lyndon Nerenberg wrote: > Either you upgrade the top-level encoding, or you downgrade the > encoding of the encapsulated message/rfc822. Correct, with the former likely the preferred method unless you know that the transport/delivery systems has problems with 8bit encoding. > But something is nagging > me that says the message/rfc822 cannot be binary, regardless. I will > have to slog my way through the relevant RFCs again to satisfy my > doubts. 7bit, 8bit, and binary are allowed for message/rfc822. No other encoding is allowed: No encoding other than "7bit", "8bit", or "binary" is permitted for the body of a "message/rfc822" entity. The message header fields are always US-ASCII in any case, and data within the body can still be encoded, in which case the Content-Transfer-Encoding header field in the encapsulated message will reflect this. Non-US-ASCII text in the headers of an encapsulated message can be specified using the mechanisms described in RFC 2047. --- RFC2046, Section 5.2.1 --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] warning when attaching rfc822 message
On Apr 13, 2014, at 5:46 PM, David Levine wrote: >> But as always ... there's a wrinkle. It looks like we always set a >> CTE of 7bit for message/rfc822 parts. But as I read it, that's not >> correct if the message/rfc822 contains 8-bit characters; in that >> case it should be 8bit (or perhaps binary, but we don't really >> handle encoding anything in binary). Do other people agree with my >> reading of RFC 2046? If so, that change should be simple. > > I'd say go for it if it's simple. It certainly seems like > an improvement. Either you upgrade the top-level encoding, or you downgrade the encoding of the encapsulated message/rfc822. But something is nagging me that says the message/rfc822 cannot be binary, regardless. I will have to slog my way through the relevant RFCs again to satisfy my doubts. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] warning when attaching rfc822 message
> Okay, so I looked at this. It looks like the simplest thing to do > is make init_decoded_content() set a default CTE (probably 7bit is > appropriate). But 8bit would be safe more often. Is there any harm nowadays in saying that a 7bit message is 8bit? > But as always ... there's a wrinkle. It looks like we always set a > CTE of 7bit for message/rfc822 parts. But as I read it, that's not > correct if the message/rfc822 contains 8-bit characters; in that > case it should be 8bit (or perhaps binary, but we don't really > handle encoding anything in binary). Do other people agree with my > reading of RFC 2046? If so, that change should be simple. I'd say go for it if it's simple. It certainly seems like an improvement. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] warning when attaching rfc822 message
>It looks like nothing had been called to set c_encoding before >InitMessage() is called. I suspect that we're seeing this now >because attach used to use text/plain or application/octet-stream >in the past, but now it's using message/rfc822. Okay, so I looked at this. It looks like the simplest thing to do is make init_decoded_content() set a default CTE (probably 7bit is appropriate). The actual CTE is set in scan_content(), so having a default here would make the various parts the code in mhparse.c happy (an example of how bad the API is here; various parts of programs call into routines in mhparse.c with wildly differing expectations). But as always ... there's a wrinkle. It looks like we always set a CTE of 7bit for message/rfc822 parts. But as I read it, that's not correct if the message/rfc822 contains 8-bit characters; in that case it should be 8bit (or perhaps binary, but we don't really handle encoding anything in binary). Do other people agree with my reading of RFC 2046? If so, that change should be simple. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] warning when attaching rfc822 message
>> mhbuild: "message/rfc822" type in message (null) should be encoded in 7bit or >> 8bit, continuing... > >It looks like nothing had been called to set c_encoding before >InitMessage() is called. I suspect that we're seeing this now >because attach used to use text/plain or application/octet-stream >in the past, but now it's using message/rfc822. Yeah, that's the same thing I discovered just now. This also reminds me that I wanted to track this down because it's also the cause of the (null) in the above message. Sigh. I recall when I looked at this earlier it was a bit of a mess; give me some time to work on it. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] warning when attaching rfc822 message
Mikhail wrote: > Simple way to reproduce the warning (just need to fix "Attach:" header > to proper path): > > edge:~> cat > live.letter << EOF > > > From: Mikhail > To: t...@test.com > cc: > Fcc: +outbox > Subject: test > Attach: /home/misha/19 > > test > > EOF > edge:~> mhbuild live.letter > mhbuild: "message/rfc822" type in message (null) should be encoded in 7bit or > 8bit, continuing... It looks like nothing had been called to set c_encoding before InitMessage() is called. I suspect that we're seeing this now because attach used to use text/plain or application/octet-stream in the past, but now it's using message/rfc822. I'm not sure how to fix it and won't be able to look at it for a while. Ken? David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
