Re: unreadable message

[nospam@dev.null (Alexey Pustyntsev)]

Hello Adam!


Thanks for your attention to my problem.

info-gnus-english-request@gnu.org writes:
> ------------------------------
>
> Message: 7
> Date: Sat, 08 Nov 2008 13:24:53 +0100
> From: asjo@koldfront.dk (Adam Sj?gren )
> Subject: Re: unreadable message
> To: info-gnus-english@gnu.org
> Message-ID: <87od0qbe22.fsf@topper.koldfront.dk>
> Content-Type: text/plain; charset=iso-8859-1
>
> Which programmes did he try? I find it quite hard to believe that any
> modern mail-programme does not decode Content-Transfer-Encoding: base64
> automatically.

He used web mail (yandex) and I think the browser was IE. 

>
>> While you managed to decode that bit, which was actually readable in
>> my outgoing mail box but unreadable at my friend's machine, there is
>> no guarantee it's always possible to do that easily.
>
> Well, base64 encoding is in the MIME standard, so all mail programmes
> that understand MIME _ought_ to be able to decode it.

Well, I understand all that and just tell you what happened. 

>
>> Usually, what you get after decoding is a set of numbers with
>> backslashes in front of them, which are the unicode character codes,
>> as I understand it.
>
> How did you come to this understanding?

Of course, I may be wrong about unicode, but I tried to decode some of
such messages. The result was a message composed of characters like
\320\264\275, etc. This is unreadable too.

>> I don't think that manually running base64 decoding is an acceptable
>> alternative for a decent MUA.
>
> Of course not. A decent MUA automatically does base64 decoding when
> encountering a base64-encode email. Just as it automatically decodes
> quoted-printable and handles charsets.
>
>> Unfortunately, the bug is of occasional nature, which means not every
>> text causes that to happen. It seems that Gnus/Emacs functions dealing
>> with unicode may have this bug.
>
> I am not sure this is a bug in Gnus - from what you have presented so
> far, it sounds like lack of MIME support in your friends' programmes.

This is very unlikely. Usually, famous web mail services (e.g. google,
yahoo, yandex, hotmail) have proper MIME support. However, my Gnus
produces these unreadable messages, some of which I cannot read myself
even after decoding, as I already said. 

> Gnus chooses the encoding based on what the most efficient encoding is -
> this may be why you think it the behaviour is occational, it depends on
> t he content:
>
> ,----[ C-h v mm-content-transfer-encoding-defaults RET ]
> | `mm-content-transfer-encoding-defaults' is a variable declared in Lisp.
> |   -- loaded from "mm-encode"
> | 
> | Value: (("text/x-patch" 8bit) ("text/.*" qp-or-base64)
> | ("message/rfc822" 8bit) ("application/emacs-lisp" qp-or-base64)
> | ("application/x-emacs-lisp" qp-or-base64) ("application/x-patch"
> | qp-or-base64) (".*" base64)) 
> | 
> | Documentation:
> | Alist of regexps that match MIME types and their encodings.
> | If the encoding is `qp-or-base64', then either quoted-printable
> | or base64 will be used, depending on what is more efficient.
> | 
> | `qp-or-base64' has another effect.  It will fold long lines so that
> | MIME parts may not be broken by MTA.  So do `quoted-printable' and
> | `base64'.
> | 
> | Note: It affects body encoding only when a part is a raw forwarded
> | message (which will be made by `gnus-summary-mail-forward' with the
> | arg 2 for example) or is neither the text/* type nor the message/*
> | type.  Even though in those cases, you can use the `encoding' MML tag
> | to specify encoding of non-ASCII MIME parts.
> `----
>
> You can change the value of this variable if you don't want Gnus to
> choose between quoted-printable and base64 automatically.

Well, that's all fine, but what's really happening is that users
may type cyrillic (utf8), hit (C-c C-c) and the result may be either
readable or unreadable or readable after decoding. We don't know that
beforehand and I think we need not because the MUA is expected to do
that consistently. If it doesn't, I presume that to be a bug.

What do you think? 

-- 
Rgds
Alexey

Today is Pungenday, the 21st day of The Aftermath in the YOLD 3174