Page MenuHomePhorge

Simplify mimetree parts as we get them from the mimetreeparser
Closed, ResolvedPublic8 Story Points


It's currently rather difficult to display the mime-part tree as it is presented because what's exported doesn't reflect what needs to be displayed.
For instance:

MimeMesssgePart isAttachment
  CryptoMessagePart isAttachment
    CryptoMessagePart isAttachment
      TextMessagePart isAttachment
        MessagePart (main body)
      TextMessagePart isAttachment
        MessagePart (signed encrypted attachment)
  CryptoMessagePart isAttachment
      TextMessagePart isAttachment
        MessagePart (unsigned encrypted attachment)

This results in a ridiculous amount of nested views that do absolutely nothing.
Also, we can't filter out attachments, because everything that isn't directly a text part is an attachment it seems.
What we need is this:

  Text (main body, encrypted, signed)
  Attachment (encrypted, signed)
  Attachment (encrypted)

So rather a fairly flat tree, with properties to figure out what is now signed or encrypted.
In most cases a list should be good enough, in some cases some hierarchical information may be useful to be able to display some thing inline.


Ticket Type

Event Timeline

mollekopf created this task.

Sandro, please add your thoughts and comments on the issue.

The example comes from the "OpenPGP encrypted one signed and one unsigned attachment"

@machniak nope - here we are talking about kube and the display of mails

T1139 is current kmail and is in sending part not in viewing part

A attachment is marked as:

  • is must be a TextMessagePart
  • and if mIconType != NoIcon
  • and via mNode you get the contentType

(at the moment mIconType & mNode are marked as private

Here's where I see the purpose in libmessageparser:

It's supposed to make is easy for email clients to interpret and visualize the content of a mail. Whatever that entails.
It's not supposed to enforce a specific way of displaying it.

This involves dealing with decryption, making embedded mails available, making it possible to access a signature of a signed part, making attached keys to a message available etc.

From the Kube side we require:

  • A list of parts to display, flat if possible, nested if necessary.
  • A list of attachments that we can deal with as appropriate:
    • Invitations and other iTip messages would probably get an inline event viewer.
    • Embedded messages might be displayed inline (so we need to know where), or the might be offered as a list that you can click on to view the message
    • Images might be displayed inline, or made available as attachments only.
    • Other attachments are probably usually listed as separate list.

What we see from that is:

  • Some parts are not interesting to have in this tree. Encryption parts and signatures are properties of the embedded parts, and how that exactly looks MIME-Parts wise is an implementation detail.
  • Attached signatures or certificates or vcards are not part of the regular message structure and should be made available as properties/attachments.
  • We want a simple and straightforward API. The point of this library is that I don't have to read the S/MIME rfc to render an S/MIME message, if the library simply replicates the parts it becomes fairly pointless.
mollekopf changed the point value for this task from 5 to 8.Jul 4 2016, 10:36 AM
petersen moved this task from Doing to Backlog on the Sprint 201639 board.
petersen moved this task from Doing to Backlog on the Sprint 201640 board.