[Users] Mailing patches and utf-8

[Michael Gmelin]

On Tue, 2 Oct 2012 14:00:07 +0200
Ricardo Mones <ricardo at mones.org> wrote:

>   Hi Michael,
> 
> On Sat, Sep 29, 2012 at 11:41:50PM +0200, Michael Gmelin wrote:
> > Hi,
> > 
> > I mailed a patch containing utf-8 characters recently and at the
> > receiving side the characters got garbled. Claws itself shows the
> > patch correctly.
> > 
> > The mime structure is:
> > 
> > ...
> > Mime-Version: 1.0
> > Content-Type: multipart/mixed;
> > boundary="MP_/l2SRWsGWoVAuwHaSxfL=MMK"
> > 
> > --MP_/l2SRWsGWoVAuwHaSxfL=MMK
> > Content-Type: text/plain; charset=US-ASCII
> 
>   This is not really necessary, as default charset for text/plain is
> alredy US-ASCII (See:
> http://tools.ietf.org/html/rfc2046#section-4.1.2 and newer
> http://tools.ietf.org/html/rfc6657#section-4)

That's true, but this is what Claws is actually doing right now (it's
not harmful though).

> 
> > Content-Transfer-Encoding: 7bit
> > Content-Disposition: inline
> > 
> > Blablablablabla
> > 
> > --MP_/l2SRWsGWoVAuwHaSxfL=MMK
> > Content-Type: text/x-patch
> 
>   IMO, the problem is here, which doesn't specify a charset, and
> being an x- subtype doesn't have any specification written [0].

Agreed, I should have noted that sending the same file using text/plain
(triggered by a .txt file extension) does exactly the same. IMHO
text/plain; charset=UTF-8 might make sense for text files (e.g. for
displaying them inline).

> 
> > So the attachment has no charset whatsoever (which I think is
> > correct, since quote printable itself is 7bit ASCII and in the
> > absence of any further charset specification the receiving end
> > should either assume ASCII or UTF-8 (which both - when applied
> > transparently - shouldn't yield the results I've seen). Based on
> > the results it seems that the receiving side converts it to a
> > different default charset.
> > 
> > So, am I correct to assume that Claws handled this correctly and
> > that I should contact the maintainer of the receiving side to
> > figure out what went wrong?
> 
>   As said, AFAIK there's no specification for x-patch subtype, so I
> guess that lacking charset parameter the receiver should at most
> assume ASCII (the default for text/plain). If you say applying ASCII
> the results are not what they see, then, yes, they're converting with
> the wrong charset.
> 
>   Requesting UTF-8 display without charset=UTF-8 parameter is a bit
> strong IMO. It would conform to RFC 6657 3: «Thus, new subtypes of the
> "text" media type SHOULD NOT define a default "charset" value.  If
> there is a strong reason to do so despite this advice, they SHOULD
> use the "UTF-8" [RFC3629] charset as the default.», but this is not a
> must, this is from 2 months ago, and again the x-patch is not a
> defined subtype.

This was the reference I was looking for, but as you pointed out the
default for text/plain is US-ASCII and Claws is not specifying it in
case of attaching a UTF-8 encoded text/plain file.

> 
>   If receiver has some fallback encoding or fallbacks to an
> environment encoding which matches attachment encoding this could be
> handled correctly. 
>   Unfortunately there's no way to set the attachment charset in Claws
> Mail attachment properties dialog, so you can assign the proper
> encoding for them.

Actually there is, you can just modify the MIME-Type text entry field,
e.g.

text/x-patch; charset=UTF-8
text/plain; charset=UTF-8

just tested this and it works ok. It would be great if this could
be done automatically for certain kinds of attachments, but at least
there's a workaround.

> 
>   regards,
> 
> [0] http://www.iana.org/assignments/media-types/text/index.html

Thanks for your detailed response.

Cheers,

-- 
Michael Gmelin