Mikhail wrote:
> Simple way to reproduce the warning (just need to fix "Attach:" header
> to proper path):
>
> edge:~> cat > live.letter << EOF
>
>
> From: M
>> 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-stre
>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. I
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
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 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
>> 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 b
>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
https://list
13 matches
Mail list logo
