nmh-workers
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]