This isn't worth doing. Also, the diff you had to merge with the original mail seems to have nothing to do with transfer-encoding changes anyway. You had to change the mime structure altogether
Jeff On Wed, 2004-11-03 at 20:22 +0100, Enrique Perez-Terron wrote: > Hello, > > I just received a mail that I could not display properly because the > sender had pasted a mail verbatim, headers and all, into his composer > window. The original mail had: > > MIME-Version: 1.0 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > while the mail I received had just > > Mime-Version: 1.0 > Content-Transfer-Encoding: 8bit > > (Thinking about it a bit, it looks more like the mailing list I got the > mail from has goofed somehow, treating the mail headers of its incoming > mail as if it were body text.) > > I do receive mails from time to time that have incorrect or missing > content-type, and I can turn such mails readable by clicking > View->Character Encoding->UTF-8 (or whatever applies), but in the > present case I also need to set a transfer-encoding. > > I know that having this possibility would not solve all problems, e.g. > what if the mail my friend (or mailing list) sent me had been sent with > transfer-encoding quoted-printable, then the '=' signs of the pasted-in > quoted-printable codes would themselves have been encoded, and I would > have needed a double round of decoding to display that properly. Yet, > just having the possibility to pretend the mail had an added or modified > header would solve the majority of the cases. Evolution has all the > functions built in to do the various forms of decoding, it only lacks > some wrapper code and a gui element or two to make it all work. Am I > asking for too much? (Yes, I know that in practice things are almost > never that simple. Sigh.) > > Perhaps the need arises too seldom to make the effort worth it. Or > perhaps it would be more useful to design something more general, an > ability to apply a more general class of transformations to the text > being displayed. On the other hand, perhaps Evolution should remember > the chosen transformations the next time it has to render the same mail > - and automatically turn such things off when you move on to the next > mail. > > Perhaps one such more general class of transformations would be to look > in the body of the text for something that looks like an mbox file or a > plain smtp data command contents (but probably missing the terminating > dot). This should then pick up mime multipart processing, etc. > > Or, perhaps turning a non-multipart mail into a multipart one, the user > selecting a region to become one such part. And also, in a multipart > message, splitting a part further into smaller parts. Evolution could > scan the first lines of the selected region for lines looking like > content-type and content-transfer-encoding specification, and offer to > use them in a part header, and otherwise offer the user to set the > content-type, charset, transfer-encoding, and contents-disposition of > the new parts. > > What do you think? > > What about a chance to "fix" the headers in a composer window, for those > who know that black magic art? (I know I can save the mail to a file and > import it after editing. It is just a bit cumbersome. I just did this to > the mail I received, adding three lines as shown by the following diff: > > diff -u /tmp/saved-mail.orig /tmp/saved-mail > --- /tmp/saved-mail.orig 2004-11-03 20:12:11.740596242 +0100 > +++ /tmp/saved-mail 2004-11-03 20:00:09.615993628 +0100 > @@ -34,8 +34,10 @@ > DRUGS_MUSCLE 0.01, NO_REAL_NAME 0.28) > X-Evolution-Source: pop://[EMAIL PROTECTED] > Mime-Version: 1.0 > +Content-Type: multipart/mixed; boundary="=-p4ZKeD6jFQt+DoMSozvJ" > Content-Transfer-Encoding: 8bit > > +--=-p4ZKeD6jFQt+DoMSozvJ > From: [EMAIL PROTECTED] (Robert Sund) > Date: Tue, 2 Nov 2004 17:54:28 +0200 > Message-ID: <[EMAIL PROTECTED]> > @@ -333,3 +335,4 @@ > Robert Sund > > > +--=-p4ZKeD6jFQt+DoMSozvJ-- > > > Then the imported mail behaved perfectly.) > > Regards, > Enrique > > _______________________________________________ > evolution maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/evolution > -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. [EMAIL PROTECTED] - www.novell.com
smime.p7s
Description: S/MIME cryptographic signature
