[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: kmail: bugreport+bugfix (nested multipart messages)
From:       Daniel F Moisset <dmoisset () grulic ! org ! ar>
Date:       2000-09-29 22:49:52
[Download RAW message or body]

On Wed, 27 Sep 2000, Michael Haeckel wrote:
> 
> It is intended to not render any HTML code in a mail when "Prefer HTML" is 
> disabled for security reasons.
> But with your patch I saw this happen with an example mail sent some days ago 
> the KMail list, I attached it again.
> 

It doesn't; the code that determines whether HTML is rendered is inside
kmreaderwin.cpp (and i didn't modify it)

> Your patch now display as far as I can see all body parts. That is an 
> improvement, but it still does not show them as it should.

That's right; I wanted it to do that as a quick solution (preferring that 
to undecoded multiparts)

> For example if 
> there is a text and a html part then only one of both should be displayed. I 
> think pine does that in a similar way as your patch does.

No; pine shows only one. Actually, pine presents the correct behavior
according to RFC-204[56789], i.e. : showing only one of the parts of
multipart/alternative messages:

<RFC2046>
    (1)   multipart -- data consisting of multiple entities of
          independent data types.  Four subtypes are initially
          defined, including the basic "mixed" subtype specifying
          a generic mixed set of parts, "alternative" for
          representing the same data in multiple formats,
          "parallel" for parts intended to be viewed
          simultaneously, and "digest" for multipart entities in
          which each part has a default type of "message/rfc822".
(...)
5.1.4.  Alternative Subtype
   
   The "multipart/alternative" type is syntactically identical to
   "multipart/mixed", but the semantics are different.  In particular,
   each of the body parts is an "alternative" version of the same
   information.
          
   Systems should recognize that the content of the various parts are
   interchangeable.  Systems should choose the "best" type based on the
   local environment and references, in some cases even through user
   interaction.  As with "multipart/mixed", the order of body parts is
   significant.  In this case, the alternatives appear in an order of
   increasing faithfulness to the original content.  In general, the
   best choice is the LAST part of a type supported by the recipient
   system's local environment.
</RFC2046>

I think kmail should work according to this. I can see if I can implement
the changes for that.

Actually, it should be nice to have a "preferred text subtype", ith
options like "plain", "html", "default". (default meaning "the
last one") According to that, the behavior should be:

1) When finding a multipart/alternative part, look for a part with the
preferred subtype. If found, show only that
2) If not, look for the last part that kmail can render
3) If no part can be rendered, show the last part as an attachment.

That could work with multipart/alternative with text, images, etc. I think
it's not hard to implement, I'll try to do it some day next week. That
would need modifying kmmessage for reading the "Prefer HTML" option.

I think that would be clean enough.
>
> But no HTML code from the mail must be rendered when "Prefer HTML" is 
> disabled. This has to be fixed before we include your patch.
> 
This is not happenning (if it does, it was happening before my
patch; the code for stopping HTML rendering is elsewhere).

	Daniel

-- 
Syntactic sugar causes cancer of the semicolon --Alan Perlis

_______________________________________________
Kmail Developers mailing list
Kmail@master.kde.org
http://master.kde.org/mailman/listinfo/kmail

[prev in list] [next in list] [prev in thread] [next in thread]