Re: OK, so how do I *use* MIME?

[wmperry@aventail.com (William M. Perry)]

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.