Mikhail wrote:
Simple way to reproduce the warning (just need to fix Attach: header
to proper path):
edge:~ cat live.letter EOF
From: Mikhail
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
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
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
On Apr 13, 2014, at 5:46 PM, David Levine levin...@acm.org 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
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
On Apr 13, 2014, at 6:29 PM, Earl Hood e...@earlhood.com 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
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 ...
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.
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
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
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
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
13 matches
Mail list logo
