From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.user/11611 Path: news.gmane.org!not-for-mail From: asjo@koldfront.dk (Adam =?iso-8859-1?Q?Sj=F8gren?=) Newsgroups: gmane.emacs.gnus.user Subject: Re: unreadable message Date: Sat, 08 Nov 2008 13:24:53 +0100 Organization: koldfront - analysis & revolution, Copenhagen, Denmark Message-ID: <87od0qbe22.fsf@topper.koldfront.dk> References: <20081030170648.D58A5A7629@sycore.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1226148031 10186 80.91.229.12 (8 Nov 2008 12:40:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Nov 2008 12:40:31 +0000 (UTC) To: info-gnus-english@gnu.org Original-X-From: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Sat Nov 08 13:41:34 2008 connect(): Connection refused Return-path: Envelope-to: gegu-info-gnus-english@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Kyn87-0001Vq-7c for gegu-info-gnus-english@m.gmane.org; Sat, 08 Nov 2008 13:41:31 +0100 Original-Received: from localhost ([127.0.0.1]:55628 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kyn6z-00074R-Dd for gegu-info-gnus-english@m.gmane.org; Sat, 08 Nov 2008 07:40:21 -0500 Original-Path: news.stanford.edu!headwall.stanford.edu!news.glorb.com!news2!proxad.net!feeder1-2.proxad.net!62.111.101.3.MISMATCH!news.germany.com!nuzba.szn.dk!news.koldfront.dk!pnx.dk!not-for-mail Original-Newsgroups: gnu.emacs.gnus Original-Lines: 85 Original-NNTP-Posting-Host: topper.koldfront.dk Original-X-Trace: virgil.koldfront.dk 1226147095 7075 192.168.1.160 (8 Nov 2008 12:24:55 GMT) Original-X-Complaints-To: abuse@koldfront.dk Original-NNTP-Posting-Date: Sat, 8 Nov 2008 12:24:55 +0000 (UTC) X-Face: )qY&CseJ?.:=8F#^~GcSA?F=9eu'{KAFfL1C3/A&:nE?PW\i65"ba0NS)97, Q(^@xk}n4Ou rPuR#V8I(J_@~H($[ym:`K_+]*kjvW>xH5jbgLBVFGXY:(#4P>zVBklLbdL&XxL\M)%T}3S/IS9lMJ ^St'=VZBR List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Errors-To: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.gnus.user:11611 Archived-At: 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 ¹ -- "you will enjoy the video." Adam Sjøgren asjo@koldfront.dk