On Apr 13, 2014, at 8:00 PM, Ken Hornstein wrote:
> So if people have some
> additional stuff you want in there, speak up soon!
I'm done!
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Nmh-workers mailing list
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
> 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
>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
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
>> 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.
-
>> 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
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
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 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
> 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
>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
I wrote:
> It turns out that the failure was not due to long lines, but to
> non-ASCII characters in what was supposed to be an ASCII html page.
Removing the -textcharset switch will allow the text/plain
part insertion to succeed.
David
___
Nmh-worker
Jerrad wrote:
> It recreates text/plain alternative parts for me, and sometimes
> creates new ones, but it fails to create them for HTML parts
> with long lines, as Ken recapped above.
It turns out that the failure was not due to long lines, but to
non-ASCII characters in what was supposed to be
>If the issue is that we need to un-qp some HTML content that results in
>a line length > 998, but then that HTML will be converted to plain text that
>presumably won't have long line, then that would be fine
Precisely.
>It does. At this point, I don't understand your problem.
>mhfixmsg adds tex
>> 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
Mikhail wrote:
> Simple way to reproduce the warning (just need to fix "Attach:" header
> to proper path):
>
> edge:~> cat > live.letter << EOF
>
>
> From: M
Ken wrote:
> So ... other than some mhfixmsg changes that David and Jerrad are working
> on, is there anything else people want to bring up before 1.6 is branched?
There's the one the Mikhail brought up about not being able
to attach an 8-bit RFC 822 message. I wonder if the issue
has always bee
david wrote:
> part text/plain 431
> > Just to make it a bit cleaner, I'm going with "%%lcat", since we
> > will be sure to avoid any shell quoting problems with the filename.
>
> If there's an advantage to including the %%F, its quoting should be
> robust. At least it
> Just to make it a bit cleaner, I'm going with "%%lcat", since we
> will be sure to avoid any shell quoting problems with the filename.
If there's an advantage to including the %%F, its quoting should be
robust. At least it's been poked at several times over the years.
David
__
>+ if (concatsw) {
>+ if (ct->c_termproc)
>+ snprintf(buffer, sizeof(buffer), "%%lcat %%F");
Just to make it a bit cleaner, I'm going with "%%lcat", since we will be
sure to avoid any shell quoting problems with the filename.
I took a look at the change you requested ab
Jerrad wrote:
> I've not had a chance to dig through the code yet, but it
> just occurred to me hat it doesn't really matter whether
> or not nmh would like lines greater than 998 characters.
It does matter because the output from mhfixmsg can be a
message in an MH folder. (You could use mhstore
>I've not had a chance to dig through the code yet,
>but it just occurred to me hat it doesn't really
>matter whether or not nmh would like lines greater
>than 998 characters. If does, then mhfixmsg could
>replace the HTML part with an un-transfer-encoded
>version, but the issue at hand is creating
I've not had a chance to dig through the code yet,
but it just occurred to me hat it doesn't really
matter whether or not nmh would like lines greater
than 998 characters. If does, then mhfixmsg could
replace the HTML part with an un-transfer-encoded
version, but the issue at hand is creating a pla
24 matches
Mail list logo
