[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Release Engineering
From: |
Ralph Corderoy |
Subject: |
Re: [Nmh-workers] Release Engineering |
Date: |
Mon, 23 Dec 2013 11:37:17 +0000 |
Hi,
So C-T-E 8bit is nice because it means I can comp(1) UTF-8 in vim and
the dcc-copy is still 8bit UTF-8 in ~/mail/inbox so great for grep(1),
etc. Unlike QP or base64. Yes, this does assume the MTAs involved
don't translate it to non-8bit C-T-E along the way.
> > > And another possible issue: I'm not sure that our MIME parser can
> > > handle 8-bit input. I don't have evidence at hand, but I tried
> > > quickly a while back and ran into trouble.
> >
> > I know Ralph sends out 8bit all of the time, and AFAIK we never have
> > a problem with it. We don't convert stuff from non-local native
> > character sets; is that maybe the issue?
>
> Could be. And UTF-8 might avoid the issue.
>
> It wouldn't affect outgoing mail. mhlist, mhstore, etc., do use the
> MIME parser.
I've just submitted 8bit UTF-8 to whatnow's "mime" and the dcc-copy
looks fine. I arranged for the first part to have
Content-Type: text/plain; charset="UTF-8"
Content-ID: <address@hidden>
Content-Transfer-Encoding: 8bit
and show(1) and mhshow(1) are happy.
$ mhlist last
msg part type/subtype size description
13181 multipart/mixed 4359
1 text/plain 1819
2 text/plain 2243
$
It could be that non-UTF-8 8bit is less friendly for the reasons that
make UTF-8 such a win. :-)
Cheers, Ralph.
- [Nmh-workers] Release Engineering, Lyndon Nerenberg, 2013/12/22
- Re: [Nmh-workers] Release Engineering, David Levine, 2013/12/22
- Re: [Nmh-workers] Release Engineering, David Levine, 2013/12/22
- Re: [Nmh-workers] Release Engineering, David Levine, 2013/12/22
- Re: [Nmh-workers] Release Engineering, David Levine, 2013/12/23
- Re: [Nmh-workers] Release Engineering,
Ralph Corderoy <=
- Re: [Nmh-workers] Release Engineering, David Levine, 2013/12/23