[Evolution] Wishlist: override content-transfer-encoding

[Enrique Perez-Terron <enrio online no>]

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://enrio pop online no
 Mime-Version: 1.0
+Content-Type: multipart/mixed; boundary="=-p4ZKeD6jFQt+DoMSozvJ"
 Content-Transfer-Encoding: 8bit
 
+--=-p4ZKeD6jFQt+DoMSozvJ
 From: xyz xyz xy (Robert Sund)
 Date: Tue, 2 Nov 2004 17:54:28 +0200
 Message-ID: <1gml6c0 apiuti7uo11dM%xyz xyz xy>
@@ -333,3 +335,4 @@
 Robert Sund
 
 
+--=-p4ZKeD6jFQt+DoMSozvJ--


Then the imported mail behaved perfectly.)

Regards, 
Enrique