Re: unreadable message

[asjo@koldfront.dk (Adam Sjøgren)]

On Sat, 08 Nov 2008 16:05:02 +1000, Alexey wrote:

>> What, exactly, seems to be the problem?

> Once the post command (C-c C-c) typed, it may produce garbage.

base64 encoding is part of the MIME specification¹. It can hardly be
classsified as "garbage".

> People, who receive the mail, cannot read it. For instance, a friend
> of mine, who is an ordinary windows user, tried to read it on
> different machines but with no luck. Frequently, when that happens, I
> cannot read it either.    

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.

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

> 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?

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

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.


  Best regards,

     Adam


¹ <http://tools.ietf.org/html/rfc2045>

-- 
 "you will enjoy the video."                                  Adam Sjøgren
                                                         asjo@koldfront.dk