[Kde-pim] Bug in KMime with ContentType::category() and Content::attachments()

[Gregory Schlomoff]

Hi,

I have a mime message with the following structure:

1 -> multipart/related
1.1 -> multipart/alternative
1.1.1 -> text/plain;
1.1.2 -> text/html
1.2 -> image/gif
2 -> image/jpeg

If I call KMime::Content::attachments(false), (where "false" means do
not include alternative parts), I get the following parts:

1.1.2 -> text/html
1.2 -> image/gif
2 -> image/jped

So clearly, part 1.1.2 shouldn't be here, since it's an alternative
part and we specifically asked not to get it.

It turns out that attachments() uses ContentType::category() to
determine whether a part is alternative or not. The content category
can take one of the following values, defined in kmime_headers.h

enum contentCategory {
  CCsingle,
  CCcontainer,
  CCmixedPart,
  CCalternativePart
};

The content category of my part 1.1.2 is set to CCcontainer, which is
why attachments() is failing to recognize it as an alternative part.

Now the thing is, this content category is set in two different code paths :

* In kmime_headers.cpp, ContentType::setMimeType sets it to either
CCcontainer or CCsingle,
* In kmime_content.cpp, ContentPrivate::parseMultipart() sets it to
either CCalternativePart or CCmixedPart.

Now, aside from the fact that we have two points in the code setting
the value of category, a bigger problem is that the values of the enum
are overlapping.

We have the following table of truth for category:

CCcontainer IFF content-type starts with "multipart"
CCsingle IFF not CCcontainer
CCalternativePart IFF content-type contains "alternative"
CCmixedPart IFF not CCalternativePart

So clearly, for a part whose content type is
"multipart/alternative"... we have a problem, which makes sense from a
semantical point of view, since both alternative and mixed parts are
container parts.

I ran a quick text search on the whole kdepimlibs repository, and I've
found that only kmime_content.cpp uses CCalternativePart and
CCmixedPart, but I haven't check anything external to kdepimlibs.

So, I would like to suggest the following:

1. Mark CCalternativePart and CCmixedPart as deprecated, document the
fact that they are not being used, and remove them in KDE5
2. In kmime_content.cpp, use isSubtype("alternative") ) to determine
whether a part is alternative or not (which is how the
CCalternativePart value was set)

What do you think ?

Thanks

Greg
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/