From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/20283
Path: main.gmane.org!not-for-mail
From: wmperry@aventail.com (William M. Perry)
Newsgroups: gmane.emacs.gnus.general
Subject: Re: OK, so how do I *use* MIME?
Date: 13 Jan 1999 19:36:58 -0500
Sender: owner-ding@hpc.uh.edu
Message-ID: <86ww2qadw5.fsf@kramer.bp.aventail.com>
References: <kigzp7oh2m7.fsf@jagor.srce.hr> <m3pv8jvx9b.fsf@quimbies.gnus.org> <kiglnj6dchn.fsf@jagor.srce.hr>
Reply-To: wmperry@aventail.com
NNTP-Posting-Host: coloc-standby.netfonds.no
Mime-Version: 1.0
X-Trace: main.gmane.org 1035158601 16912 80.91.224.250 (21 Oct 2002 00:03:21 GMT)
X-Complaints-To: usenet@main.gmane.org
NNTP-Posting-Date: Mon, 21 Oct 2002 00:03:21 +0000 (UTC)
Cc: ding@gnus.org
Return-Path: <owner-ding@hpc.uh.edu>
Original-Received: from karazm.math.uh.edu (karazm.math.uh.edu [129.7.128.1])
	by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id TAA16008
	for <jason@mailhost.sclp.com>; Wed, 13 Jan 1999 19:36:32 -0500 (EST)
Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5])
	by karazm.math.uh.edu (8.9.1/8.9.1) with ESMTP id SAB28040;
	Wed, 13 Jan 1999 18:35:49 -0600 (CST)
Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 13 Jan 1999 18:35:59 -0600 (CST)
Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.7.3/8.7.3) with ESMTP id SAA05901 for <ding@hpc.uh.edu>; Wed, 13 Jan 1999 18:35:49 -0600 (CST)
Original-Received: from slow.bp.aventail.com (usrpri2-12.kiva.net [206.97.75.77])
	by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id TAA15982
	for <ding@gnus.org>; Wed, 13 Jan 1999 19:35:41 -0500 (EST)
Original-Received: from kramer.bp.aventail.com (kramer.bp.aventail.com [192.168.2.2])
	by slow.bp.aventail.com (8.8.5/8.8.5) with ESMTP id TAA20604;
	Wed, 13 Jan 1999 19:35:21 -0800
Original-Received: (from wmperry@localhost)
	by kramer.bp.aventail.com (8.8.5/8.8.5) id TAA00622;
	Wed, 13 Jan 1999 19:36:58 -0500
Original-To: Hrvoje Niksic <hniksic@srce.hr>
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;
In-Reply-To: Hrvoje Niksic's message of "13 Jan 1999 23:39:00 +0100"
Original-Lines: 39
User-Agent: Gnus/5.070069 (Pterodactyl Gnus v0.69) XEmacs/21.2(beta8) (Artemis)
Precedence: list
X-Majordomo: 1.94.jlt7
Xref: main.gmane.org gmane.emacs.gnus.general:20283
X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:20283

Hrvoje Niksic <hniksic@srce.hr> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Hrvoje Niksic <hniksic@srce.hr> writes:
> > 
> > > 1) It does allow me to view the article in the buffer, but saving it
> > >    or piping it to a command still saves the original junk, instead of 
> > >    the decoded stuff.  Is there a way to hook into the way *contents*
> > >    are handled, in order to allow easy saving of the junk?
> > 
> > I don't think so.  The CTE is decoded before saving/piping, but
> > other than that, you deal with the untampered-with contents.  Which
> > seems logical to me -- when saving a GIF, one doesn't want it
> > fiddled with before saving, for instance.
> 
> For GIF, I agree with you.  But in this case, I would *like* to have a
> hook to tamper with the contents at an early stage, similar to what CTE
> processing does.

The problem here is that whoever is sending you such heinous attachments
with a CONTENT-TYPE of application/x-gzip64 should really be sending it as
application/octet-stream (or text/plain or whatever) with a
CONTENT-TRANSFER-ENCODING of x-gzip64

Then you could define just one new handler for the CTE x-gzip64 and all
would be well.  I assume such a beasty would have to base64 decode and then 
gunzip it.  I have no idea if this is easy to do with the mm stuff in pGnus 
or not though.

I think Gnus is doing the right thing by giving you the raw data, since
that is what the content-type displayers _should_ get.  The fact that
application/x-gzip64 is an abomination is a totally different problem. :)

Perhaps there is a way to hook into the article parsing before mimification 
begins and change the CTE header if the CT is application/x-gzip64?  That
might work...

-Bill P.