[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mime decoding in rmail

From: twurgl
Subject: Re: Mime decoding in rmail
Date: Wed, 28 Mar 2007 18:05:59 -0400

Shouldn't the resulting mail be able to be saved into a file and displayed via 
emacs or other gif
viewer program?  Does the base-64 decode not do the right thing with this kind 
of file?
And I am not sure what a multipart message is (or even base-64 for that 
matter), sorry.

What would be best , IMO, is have rmail decode things and display them as the 
image or
whatever it is right there in rmail.  Maybe a prompt to ask if you want it 
decoded and displayed?

The 21.x behavior would solve my problem, I had code to detect such a message 
from the subject line (pretty weak, I know)
write the rmail to a file, do a shell command to decode it with uudeview, then 
insert the resulting gif file back into the
rmail and delete the original mime part.

thanks for all your efforts!

             Eli Zaretskii <address@hidden>                                     
             03/28/2007 05:44 PM                                                
                         Please respond to                     address@hidden   
                   Eli Zaretskii <address@hidden>                               
                                                               Re: Mime 
decoding in rmail                                             

> From: address@hidden
> Date: Wed, 28 Mar 2007 07:54:27 -0400
> I asked my admin if he could send you a sample mail mime encoded the same way 
> I'd get one.  He will send one with the subject
"Today's Dilbert".

Thanks, I see the problem now: this message sends an inline GIF image,
without using a multipart MIME email message format.  Emacs 22 always
decodes base-64 and QP encoded messages, if they are not multipart.  I
somehow got the impression that you were talking about a multipart

The problem here is that Rmail is too naive: it assumes that such
single-part messages are text, but it doesn't make sure that by
looking at the Content-type header.

I will try to at least make this decoding optional, so you could turn
it off, and get the old v21.x behavior.  If I find a safe way to
decode only text messages, and leave non-text Content-type alone, I
will; otherwise this will have to wait until after the release.

Thanks for bringing this to our attention.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]