[prev in list] [next in list] [prev in thread] [next in thread]
List: kmail-devel
Subject: Re: new "kmail with PGP" error
From: Sven Radej <sven () lisa ! exp ! univie ! ac ! at>
Date: 2000-03-27 10:23:40
[Download RAW message or body]
On Mon, 27 Mar 2000, Andreas Gungl wrote:
>Hi,
>
>I want to rise this topic again, also because Stefan wrote about
>problems with the font size for html mails and thougth about multipart
>mails. We should definitly improve the mechanism which is resposible for
>handling/displaying the message parts.
>
>Below is my first approach (as I have already sent it). Although I
>couldnīt invest much time in it in the pevious days, I will continue
>working on it. But at the moment my kmail (cvs from last 25.03.) crashes
>when opening a mail in the
>described format. I tried to debug it, but I haven't completed the job
>yet. It's something wrong with launching a process - I'll see. (At first
>I need some more RAM. When debugging, my swap space is almost completely
>filled - 64 MB RAM and 128 MB swap.)
>
>Sven, since most code in KMReaderWin::parseMsg(KMMessage* aMsg) is
>written by you, would you prefer to continue yourself at this point? Of
>course I will assist as much as possible, but I primary focus on pgp
>support (as written below).
>
(...)
>> >> >just I got a message, which was encrypted by pgp. It was a multipart
>> >> >message, containing the info as plain text and html formatted.
>> >> >
>> >> >I guess, the default to display the message in kmail is to use the
>> >> >html formatted part. So kmail doesnīt realize, that the message is
>> >> >encrypted, since the "--- BEGIN PGP MESSAGE ---" is between html
>> >> >tags.
How is this possible? I thought that PGP messages encrypt only body, and not
attachments? Unless we are using "application/pgp" approach? Which we should.
The multipart/alternative code is really a hack - it fails to display further
attachments because they are (Outlook and netscape do so) in part2. KMMessage
cannot handle attachments in attachments. There was some talk about using new
message lib from kdenonbeta written by S. Taferner, but itīs not even ported to
Qt2 (right?). In any case, parsing code must be redone - present situation is
just bunch of (my) hacks.
(...)
>> Here is just a hack which worked for me. (No complete and perfect
>> yet, but a first proposal.) The idea is, to look through all parts,
>> if there is a plain text part with a pgp encrypted message. If so,
>> this is the prefered part for displaying. Otherwise the prefered part
>> is the html one. (I personally would like a settings option about
>> which type of part to prefer.)
>>
>> // ---sven: handle multipart/alternative start ---
>> // This is for multipart/alternative messages WITHOUT attachments
>> // main header has type=multipart/alternative and one attachment is
>> // text/html
>> if (type.find("multipart/alternative") != -1 && numParts == 2)
>> {
>> debug("Alternative message, type: %s",type.data());
>> //Now: Only two attachments one of them is html
>> int part_to_use = 0;
>> for (i=0; i<2; i++) // count parts...
>> {
>> aMsg->bodyPart(i, &msgPart); // set part...
>> subtype = msgPart.subtypeStr(); // get subtype...
>> if (stricmp(subtype, "html")==0) // is it html?
>> { // yes...
>> if (part_to_use) // use html, if no ppg
>> part_to_use = i; // part found before
>> }
>> else // no html part...
>> {
>> str = QCString(msgPart.bodyDecoded()); // decode it...
>> if (str.find("BEGIN PGP MESSAGE") != -1) // is pgp message?
>> part_to_use = i; // use this part
>> }
>> } // end for.
>> if (part_to_use)
>> {
>> aMsg->bodyPart(part_to_use, &msgPart);
>> subtype = msgPart.subtypeStr();
>> if (stricmp(subtype, "html")==0) // is it html?
>> mViewer->write(str); // write it...
>> else
>> writeBodyStr(QCString(msgPart.bodyDecoded()));
>> return;
>> }
>> // if we are here we didnt find any html part. Handle it normaly then
>> }
>> // This works only for alternative msgs without attachments. Alternative
>> // messages with attachments are broken with or without this. No need
>> // to bother with strib </body> or </html> here, because if any part
>> // follows this will not be shown correctly. You'll still be able to read the
>> // main message and deal with attachments. Nothing I can do now :-(
>> // ---sven: handle multipart/alternative end ---
>>
>> Please feel free to comment this idea. Sven, perhaps you could
>> continue this, if it isnīt complete nonsense. I think, you still have
>> some more ideas on how to improve the handling of the parts. As I
>> said, itīs my first look at this code and you are the more
>> experienced one.
Unfortunately I am not much more experienced in this - as I said whole code
from me was a hack to get it working for KDE-1.1.2. Your proposal looks ok to me
- but again it is just another hack (sorry :-). Iīd say to commit it untill we
figure out how to do this properly.
parsing should be done like this (big IMHO):
We should have object KMparsedMessage reader gets KMMessage *msg, does
parsedMessage = new KMParsedMessage(msg);
KMParsedMessage does this:
- turn everything into parts, even if there is only body. body is part 0.
- pull out attachments in attachments (for multipart/alternative) so instead of
part0 (text/plain)
part1 (text/html)
part0-in-part1 (something/anything)
part1-in-part1 (something/anything)
you get "flat" structure:
part0 (text/plain)
part1 (text/html)
part2 (something/anything)
part2 (something/anything)... etc (see remark 1 below)
- now check if parts are encrypted and decrypt them (check for "---BEGIN..."
in every part, and pass it to pgp)
- if this is multipart/alternative, skip part0
- writes all parts except part0 or (in case of multipart/alternative) part1 to
disk so we can drag them or reference them with valid url (see remark [2]
below)
- if multipart/alternative:
fix internal references in other parts ( see [2] )
else:
htmlize part0 (add from, to, fancy pixmap, links to attachments, etc)
so reader does (more or less) this with itīs KMMessasge *msg:
parsedMessage pmsg = new KMParsedMessage(msg); //does everything from above
mViewer->write(pmsg->text());
That is all - all parsing code is in other class, separated from gui stuff. This
would everything cleaner and make debugging much easier.
Whem KMParsedMessage is deleted - to display new message, or when closing -
itīs destructor cleans all written attachments.
What do you think?
remarks:
[1] - how? For that we need new message lib :-(
[2] - Try to send html mail with embeded images (or background image) with
outlook or netscape: You will see that message references them with an url
of "cid:part1.38DF4537.26E2CEC6". and each such attachment has
"Content-ID: <part1.38DF4537.26E2CEC6>" We must write down that attachment
to /tmp/kmail/xy/attachment1.jpg and change all references to it in html text
from "cid:" to "file:/tmp/kmail/xy/attachment1.jpg".
>> BTW, itīs possible to send the whole contents of an encrypted
>> multipart mail to pgp 6.x because this version can handle mime
>> parts. It will decypt the plain text part and return that contents.
>> But I doubt, if the elder versions are able to handle this. (Canīt
>> test at the moment.) So I think, the way mentioned above is better.
What confuses me about PGP is this:
You write a message with attachments and click on encrypt. Result - only body is
encrypted and attachments are not. All unix mailers - AFAIK - do so (if they are
not using application/pgp). Which mailer encrypt attachment (HTML in this case)?
And what is the right thing to do, not only for pgp6? To encrypt whole message
from top to bottom? Or to encrypt every part?
>>
>> Andreas
--
Sven Radej radej@kde.org
KDE developer Visit http://www.kde.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic