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

List:       kde-devel
Subject:    Re: Regarding the recent thread on the kmail bug
From:       Karl-Heinz Zimmer <khz () kde ! org>
Date:       2004-07-03 8:13:54
Message-ID: 200407031014.02123 () postmaster ! bugcops ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Am Samstag, 3. Juli 2004 01:02 schrieb Thiago Macieira:
> Luciano Montanaro wrote:
> >I have read the empty kmail bug thread, and since I too have received
> >an odd message, maybe I can help.
> >
> >The message I received, when opened from kmail, it shows the header
> > only. Maybe it has MIME encoding problems?
> >Using the "Show source" menu entry reveals a lot of hidden text.
> >
> >Check the message in the attachment (gzipped, so it should not be
> > mangled)
(...)
> the message is invalid. Why? Because it has a content-type of:
>
> Content-Type: Multipart/Mixed
> but it fails to say what the boundary is. KMail cannot, therefore,
> find a boundary to separate the parts.
>
> Maybe it could detect the boundary. Let's see what the RFC says...
(...)
>
> Therefore, the message you sent me is not valid and KMail is correct
> in showing whatever it wishes.
>
> In addition, the RFCs say a MIME-compliant user agent must ignore
> everything before the first boundary and after the last. Since there
> is no boundary, everything is to be ignored.

You are right, that what the RfC is saying and therefor KMail is right
to not show the body parts.
However I am not absolutely sure that it is wise to do this: we still
had a small chance to auto-detect the boundary:

*  If there is no extra text before the first boundary, e.g. no
   "This is a MIME message." then we can assume that the first
   body text line is the boundary: IF it starts with "--",
   so that would be "--SOMETHING"

*  Another additional chance to make sure that /is/ the boundary
   would be checking if the very /last/ body text line is containing
   exactly the following: "--SOMETHING--"

If these two conditions are met we could assume that this is the
boundary.

The question of course is: Do we want to do this?

pro:
  If we see a mail with Multipart/Mixed but no boundary parameter
  then we know this parameter was 'forgotten' by a buggy composer.
  We therefor could use these two checks to see if we can detect
  the boundary.

con:
  If the boundary parameter is missing we say that's a bad mail
  and we only want to display good, RfC-compliant mails.

To decide upon this is not my job.  My humble opinion is that we
should try to autodetect the boundary, but I see that con-arguments
are valid as well...

Karl-Heinz
-- 
Karl-Heinz Zimmer, Senior Software Engineer, Klarälvdalens Datakonsult AB
<mailto:khz@klaralvdalens-datakonsult.se>            <mailto:khz@kde.org>

For every complex problem there is an answer that is clear, simple, and 
wrong.

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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