Rethink messagestructure for mimetreeparser
Closed, ResolvedPublic

Description

From kube side:

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:

Message

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.

knauss created this task.EditedJul 8 2016, 12:26 PM

(also kube side)

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.
In T3208#44332, @knauss wrote:

(also kube side)

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.

yepp I think these are the ideas behind libmimetreeparser.

From the Kube side we require:

  • A list of parts to display, flat if possible, nested if necessary.

that is quite difficult, because if we flatten the tree we can't create the tree anymore, so I think, if the tree anyhow gives us information we need anywhere, than we should not flatten it at libmimetreeparser. The flatten has than to be done at kube side.

  • A list of attachments that we can deal with as appropriate:

I now have introduced a AttachmentMessagePart to make the detection of Attachments damm simple, just go through the tree and search for AttachmentMessagePart.

  • Invitations and other iTip messages would probably get an inline event viewer.

There are several thinkable solutions for that, either you can create a bodypartformatter for vCards that returns a own VCardMessagePart ( the code for it can live at kube side). Or you do it afterwards and search through all Attachments to detect the correct mimetype.

  • 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

embeded messages are already been part of the tree and have the type (EncapsulatedRfc822MessagePart), so you can detect them and display how you want.

  • Images might be displayed inline, or made available as attachments only.

Therefor we have the AttachmentStrategies, that actually work on the Messageparts+ Mimeparts and return the infomation how this Part should been shown (hidden, IconExternal, IconInline, Inlined,...)

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.

These "internal mimeparts" are already filtered out.

  • Attached signatures or certificates or vcards are not part of the regular message structure and should be made available as properties/attachments.

Currently only certificates and encryption parts are filtered out. for vCards we have no bodypartformatter so it is handled as simple attachment.

knauss added a comment.Jul 8 2016, 1:02 PM

But maybe it is easier if we look at some examples, to make it easier to understand where we can improve and how:

an encrypted message with one attachment that is encrypted+signed too and one without encryption:

  • MimeTreeParser::MessagePartList
    • MimeTreeParser::MimeMessagePart
      • MimeTreeParser::CryptoMessagePart -- encrepted
        • MimeTreeParser::CryptoMessagePart -- signed part
          • MimeTreeParser::MimeMessagePart
            • MimeTreeParser::TextMessagePart -- TextMessagePart always search for GPG Inline in the textpart
              • MimeTreeParser::MessagePart -- no GPG Inline - raw text
            • MimeTreeParser::AttachmentMessagePart -- the sign+enc attachment - search for gpg inline too
              • MimeTreeParser::MessagePart -- no gpg inline - raw text
      • MimeTreeParser::AttachmentMessagePart -- the non signed/enced attachment
        • MimeTreeParser::MessagePart -- no gpg inline - raw text

-> we should split CryptoMessagePart into too parts Signed and Encrypted messagepart, that makes more value for everybody :D
->no real need for MimeMessagePart

GPG Inline with appendix

  • MimeTreeParser::MessagePartList
    • MimeTreeParser::TextMessagePart -- the mimepart
      • MimeTreeParser::CryptoMessagePart -- one gpg encrypted textpart
      • MimeTreeParser::MessagePart -- an non encrypted textpart

-> nothing to improve here

SMIME Opaque (enc+signed)

  • MimeTreeParser::MessagePartList
    • MimeTreeParser::CryptoMessagePart -- enc
      • MimeTreeParser::CryptoMessagePart -- sign
        • MimeTreeParser::TextMessagePart -- textpart
          • MimeTreeParser::MessagePart -- no GPG Inline

--> nothing to improve here

SMIME (enc+signed)

  • MimeTreeParser::MessagePartList
    • MimeTreeParser::CryptoMessagePart -- enc
      • MimeTreeParser::CryptoMessagePart --sign
        • MimeTreeParser::TextMessagePart -- textpart
          • MimeTreeParser::MessagePart -- no GPG Inline

--> nothing to improve here

In T3208#44345, @knauss wrote:
In T3208#44332, @knauss wrote:

(also kube side)

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.

yepp I think these are the ideas behind libmimetreeparser.

Cool =)

From the Kube side we require:

  • A list of parts to display, flat if possible, nested if necessary.

that is quite difficult, because if we flatten the tree we can't create the tree anymore, so I think, if the tree anyhow gives us information we need anywhere, than we should not flatten it at libmimetreeparser. The flatten has than to be done at kube side.

Let me put it differently then; libmessagetreeparser should give use a more useful interface than a single tree. In the end we should be able to query for the parts to display, the parts to show as attachments, and be able to access parts that simply transported further information in some way (such as an attached vcard, key, ...).

  • A list of attachments that we can deal with as appropriate:

I now have introduced a AttachmentMessagePart to make the detection of Attachments damm simple, just go through the tree and search for AttachmentMessagePart.

That certainly helps. How are attachments identified?

  • Invitations and other iTip messages would probably get an inline event viewer.

There are several thinkable solutions for that, either you can create a bodypartformatter for vCards that returns a own VCardMessagePart ( the code for it can live at kube side). Or you do it afterwards and search through all Attachments to detect the correct mimetype.

Why wouldn't libmessagetreeparser just give me the information that this is an iTip attachment? I suppose if AttachmentMessagePart provides a mime-type that could server for that purpose.

  • 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

embeded messages are already been part of the tree and have the type (EncapsulatedRfc822MessagePart), so you can detect them and display how you want.

Doable, yes.

  • Images might be displayed inline, or made available as attachments only.

Therefor we have the AttachmentStrategies, that actually work on the Messageparts+ Mimeparts and return the infomation how this Part should been shown (hidden, IconExternal, IconInline, Inlined,...)

Meaning I should inject an attachment strategy to select which parts are attachments and which aren't?

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.

These "internal mimeparts" are already filtered out.

They are in the tree, so how are they filtered out? Is this depending on the attachment strategy?

  • Attached signatures or certificates or vcards are not part of the regular message structure and should be made available as properties/attachments.

Currently only certificates and encryption parts are filtered out. for vCards we have no bodypartformatter so it is handled as simple attachment.

In T3208#44346, @knauss wrote:

But maybe it is easier if we look at some examples, to make it easier to understand where we can improve and how:

##an encrypted message with one attachment that is encrypted+signed too and one without encryption:

  • MimeTreeParser::MessagePartList
    • MimeTreeParser::MimeMessagePart
      • MimeTreeParser::CryptoMessagePart -- encrepted
        • MimeTreeParser::CryptoMessagePart -- signed part
          • MimeTreeParser::MimeMessagePart
            • MimeTreeParser::TextMessagePart -- TextMessagePart always search for GPG Inline in the textpart
              • MimeTreeParser::MessagePart -- no GPG Inline - raw text
            • MimeTreeParser::AttachmentMessagePart -- the sign+enc attachment - search for gpg inline too
              • MimeTreeParser::MessagePart -- no gpg inline - raw text
      • MimeTreeParser::AttachmentMessagePart -- the non signed/enced attachment
        • MimeTreeParser::MessagePart -- no gpg inline - raw text

-> we should split CryptoMessagePart into too parts Signed and Encrypted messagepart, that makes more value for everybody :D
->no real need for MimeMessagePart

Why do we need any CryptoMessageParts?

What I want from this tree is this:

  • MimeTreeParser::TextMessagePart -- TextMessagePart always search for GPG Inline in the textpart
  • MimeTreeParser::AttachmentMessagePart -- the sign+enc attachment - search for gpg inline too
  • MimeTreeParser::AttachmentMessagePart -- the non signed/enced attachment
  • The text message part should indicate that it has been encrypted with key X and signed with key Y.
  • The first attachment should indicate that it has been encrypted with key X and signed with key Y.
  • The second attachment should indicate that it has not been signed or encrypted.

##GPG Inline with appendix

  • MimeTreeParser::MessagePartList
    • MimeTreeParser::TextMessagePart -- the mimepart
      • MimeTreeParser::CryptoMessagePart -- one gpg encrypted textpart
      • MimeTreeParser::MessagePart -- an non encrypted textpart

        -> nothing to improve here

This should be a single part.

##SMIME Opaque (enc+signed)

  • MimeTreeParser::MessagePartList
    • MimeTreeParser::CryptoMessagePart -- enc
      • MimeTreeParser::CryptoMessagePart -- sign
        • MimeTreeParser::TextMessagePart -- textpart
          • MimeTreeParser::MessagePart -- no GPG Inline

            --> nothing to improve here

This should be a single part.

##SMIME (enc+signed)

  • MimeTreeParser::MessagePartList
    • MimeTreeParser::CryptoMessagePart -- enc
      • MimeTreeParser::CryptoMessagePart --sign
        • MimeTreeParser::TextMessagePart -- textpart
          • MimeTreeParser::MessagePart -- no GPG Inline

            --> nothing to improve here

This should be a single part.

Here are a couple of questions that I currently face looking at the interface:

  • If I want to find all parts I have to display, let's assume I want to ignore any attachments or embedded messages, what do I look for?
    • I would assume I'd look for HtmlMessagePart, AlternativeMessagePart and TextMessagePart, but all attachments are also TextMessageParts, so I'm not sure that makes any sense.
    • It doesn't seem like simply getting the htmlContent of all parts (assuming I want to always show html if available), is not enough.
    • Can I ignore any subparts of those parts?
  • If I want to find all attachments, is it sufficient to look for all AttachmentParts and all EncapsulatedRFC822Messages (assuming I want to treat both the same?)
  • How can I get from a part to a parent part to find the corresponding encryption/signature?
  • How to I find out for a signature/encryption who signed and to whom this message is encrypted? How can I access the corresponding key/certificate?
  • What do I do with AttachmentParts that are images (isImage?) if I want to show images inline? Where is the inline image included if I ignore image parts?
knauss added a comment.Jul 8 2016, 2:21 PM

Let me put it differently then; libmessagetreeparser should give use a more useful interface than a single tree. In the end we should be able to query for the parts to display, the parts to show as attachments, and be able to access parts that simply transported further information in some way (such as an attached vcard, key, ...).

How you want to query? Why you need more than the tree? I don't get the usecase.

  • A list of attachments that we can deal with as appropriate:

That certainly helps. How are attachments identified?

It is a subclass of MessagePart like TextMessagePart/EncapsulatedRfc822MessagePart

  • Invitations and other iTip messages would probably get an inline event viewer.

There are several thinkable solutions for that, either you can create a bodypartformatter for vCards that returns a own VCardMessagePart ( the code for it can live at kube side). Or you do it afterwards and search through all Attachments to detect the correct mimetype.

I suppose if AttachmentMessagePart provides a mime-type that could server for that purpose.

Well the idea of libmimetreeparser is that a client should not care anymore about the mime-type. The key to connect a mime-type with a specific handling is the bodypartformatter, that is activated by a specific mime-type.

Why wouldn't libmessagetreeparser just give me the information that this is an iTip attachment?

Currently the iTip handling and vCard handling is done via plugins (kdepim-addons), cause they interact a lot with other kdepim parts. That's why the bodypartformatter is insertsted by messageviewer.
But we could also deside, that AttachmentMessagePart should have a mime-type property, than the client can act on mime-type. For me this doesn't sound as very good solution, because you than would need a switch in the logic afterwards to devide vCards/iTips from the rest of attachments.

embeded messages are already been part of the tree and have the type (EncapsulatedRfc822MessagePart), so you can detect them and display how you want.

Doable, yes.

what other solution you have in mind?

  • Images might be displayed inline, or made available as attachments only.

Therefor we have the AttachmentStrategies, that actually work on the Messageparts+ Mimeparts and return the infomation how this Part should been shown (hidden, IconExternal, IconInline, Inlined,...)

Meaning I should inject an attachment strategy to select which parts are attachments and which aren't?

no the detection what are attachments and what not is done before. The AttachmentStrategy give you control, if you want to view the attachment and how. But you can also ignore the properites of AttachmentMessagePart&AttachmentStrategy and create your own way of controling the view.

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.

These "internal mimeparts" are already filtered out.

They are in the tree, so how are they filtered out? Is this depending on the attachment strategy?

no they are filtered out already - there is no part for the attached signature or the pgp version mimepart in the messageparttree.

In T3208#44396, @knauss wrote:

Let me put it differently then; libmessagetreeparser should give use a more useful interface than a single tree. In the end we should be able to query for the parts to display, the parts to show as attachments, and be able to access parts that simply transported further information in some way (such as an attached vcard, key, ...).

How you want to query? Why you need more than the tree? I don't get the usecase.

I have to build one model that represents the parts that we want to display, one model for attachments and possible another model for embedded parts (or we mix that with the attachments).

  • A list of attachments that we can deal with as appropriate:

That certainly helps. How are attachments identified?

It is a subclass of MessagePart like TextMessagePart/EncapsulatedRfc822MessagePart

I mean, how do you distinguish between something that is an attachment, such as a pdf file, and something that isn't an attachment, such as text part?
By mime-type?

  • Invitations and other iTip messages would probably get an inline event viewer.

There are several thinkable solutions for that, either you can create a bodypartformatter for vCards that returns a own VCardMessagePart ( the code for it can live at kube side). Or you do it afterwards and search through all Attachments to detect the correct mimetype.

I suppose if AttachmentMessagePart provides a mime-type that could server for that purpose.

Well the idea of libmimetreeparser is that a client should not care anymore about the mime-type. The key to connect a mime-type with a specific handling is the bodypartformatter, that is activated by a specific mime-type.

I would always care about the mime-type of the attachment, otherwise how can I render or open it?
And how can I distinguish between a vcard and a pdf so I can either show the vcard inline or i.e. attach the information to the avatar of the sender?

Why wouldn't libmessagetreeparser just give me the information that this is an iTip attachment?

Currently the iTip handling and vCard handling is done via plugins (kdepim-addons), cause they interact a lot with other kdepim parts. That's why the bodypartformatter is insertsted by messageviewer.

I don't really understand the purpose of the bodypartformatter in the context of kube. We don't generate any html, so why would we use a bodypartformatter?

But we could also deside, that AttachmentMessagePart should have a mime-type property, than the client can act on mime-type. For me this doesn't sound as very good solution, because you than would need a switch in the logic afterwards to devide vCards/iTips from the rest of attachments.

I'm afraid I don't understand how this is currently supposed to work. Please explain.

embeded messages are already been part of the tree and have the type (EncapsulatedRfc822MessagePart), so you can detect them and display how you want.

Doable, yes.

what other solution you have in mind?

MessageTreeParser parser;
parser.setMessage();
auto embeddedMessage = parser.getEmbeddedMessages();

  • Images might be displayed inline, or made available as attachments only.

Therefor we have the AttachmentStrategies, that actually work on the Messageparts+ Mimeparts and return the infomation how this Part should been shown (hidden, IconExternal, IconInline, Inlined,...)

Meaning I should inject an attachment strategy to select which parts are attachments and which aren't?

no the detection what are attachments and what not is done before. The AttachmentStrategy give you control, if you want to view the attachment and how.

How does it do that? We're not generating html.

But you can also ignore the properites of AttachmentMessagePart&AttachmentStrategy and create your own way of controling the view.

So it only sets the hidden property etc? In other words, I could also just ignore the attachment strategy?

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.

These "internal mimeparts" are already filtered out.

They are in the tree, so how are they filtered out? Is this depending on the attachment strategy?

no they are filtered out already - there is no part for the attached signature or the pgp version mimepart in the messageparttree.

ok

knauss added a comment.Jul 8 2016, 2:43 PM

Here are a couple of questions that I currently face looking at the interface:

  • If I want to find all parts I have to display, let's assume I want to ignore any attachments or embedded messages, what do I look for?
    • I would assume I'd look for HtmlMessagePart, AlternativeMessagePart and TextMessagePart, but all attachments are also TextMessageParts, so I'm not sure that makes any sense.

Jepp - The detection of AttachmentMessagePart works as you do it for TextMessagePart.

  • It doesn't seem like simply getting the htmlContent of all parts (assuming I want to always show html if available), is not enough.

For what the htmlContent is missing?

  • Can I ignore any subparts of those parts?

Well that dependeds on parts, HTML and Alternative don't have children, TextMessagePart has children, because of the detection of GPInline. Crypto, Mime, List are parts that actually can have childs.

  • If I want to find all attachments, is it sufficient to look for all AttachmentParts and all EncapsulatedRFC822Messages (assuming I want to treat both the same?)

yes

  • How can I get from a part to a parent part to find the corresponding encryption/signature?
mp->parentPart()->getProperty("isSigned")
  • How to I find out for a signature/encryption who signed and to whom this message is encrypted? How can I access the corresponding key/certificate?

Currently the CryptoMessagePart::mSignatures, CryptoMessagePart::mDecryptRecipients, CryptoMessagePart::mMetaData - here we need to create the actual interface for these informations. I solved it for now with a friend to the Renderer.

  • What do I do with AttachmentParts that are images (isImage)?

isImage is true in that case.

if I want to show images inline?

than show them inline - where is you problem here either you use a AttachmentStrategy that return Inlined for images and use mp.asIcon or you do it with ignoring the asIcon property and use the isImage property and show them inline.

Where is the inline image included if I ignore image parts?

nowhere - if you don't display them they are hidden.

knauss added a comment.Jul 8 2016, 3:28 PM
In T3208#44396, @knauss wrote:

Let me put it differently then; libmessagetreeparser should give use a more useful interface than a single tree. In the end we should be able to query for the parts to display, the parts to show as attachments, and be able to access parts that simply transported further information in some way (such as an attached vcard, key, ...).

How you want to query? Why you need more than the tree? I don't get the usecase.

I have to build one model that represents the parts that we want to display, one model for attachments and possible another model for embedded parts (or we mix that with the attachments).

  • A list of attachments that we can deal with as appropriate:

That certainly helps. How are attachments identified?

It is a subclass of MessagePart like TextMessagePart/EncapsulatedRfc822MessagePart

I mean, how do you distinguish between something that is an attachment, such as a pdf file, and something that isn't an attachment, such as text part?
By mime-type?

  • Invitations and other iTip messages would probably get an inline event viewer.

There are several thinkable solutions for that, either you can create a bodypartformatter for vCards that returns a own VCardMessagePart ( the code for it can live at kube side). Or you do it afterwards and search through all Attachments to detect the correct mimetype.

I suppose if AttachmentMessagePart provides a mime-type that could server for that purpose.

Well the idea of libmimetreeparser is that a client should not care anymore about the mime-type. The key to connect a mime-type with a specific handling is the bodypartformatter, that is activated by a specific mime-type.

I would always care about the mime-type of the attachment, otherwise how can I render or open it?
And how can I distinguish between a vcard and a pdf so I can either show the vcard inline or i.e. attach the information to the avatar of the sender?

To distinguish between if you wanna show somthing inline or not, that's the usecase of AttachmentStrategies. But the AttachmentStrategy only adds properties to the MessagePart. A client can ignore these properties, but then you end up mixing mime-type handling into your client application.

But yes for opening it you may need the mime-type, so we will add this as property.

Why wouldn't libmessagetreeparser just give me the information that this is an iTip attachment?

Currently the iTip handling and vCard handling is done via plugins (kdepim-addons), cause they interact a lot with other kdepim parts. That's why the bodypartformatter is insertsted by messageviewer.

I don't really understand the purpose of the bodypartformatter in the context of kube. We don't generate any html, so why would we use a bodypartformatter?

But we could also deside, that AttachmentMessagePart should have a mime-type property, than the client can act on mime-type. For me this doesn't sound as very good solution, because you than would need a switch in the logic afterwards to devide vCards/iTips from the rest of attachments.

I'm afraid I don't understand how this is currently supposed to work. Please explain.

The BodyPartFormatter are the Transformer from Mimetree to MessageParts. F.ex. we have one for "pgp/encrypted" there it starts to search for the specific submimeparts to create a CrypeMessageParts and adds the additional properties, so the viewer can get everything it needs ( and hide the submimeparts away, so they are not visible in the messageparttree).

For the iTip it would be the same - the bodypartformatter would react on the calender mime-type and creates a own MessagePart instance with the needed propieries like calender/recipients/... what you need in your viewing process. So this is the ideal place to add specific mime-type handling to prepare this part for the viewing process. As you already said before you don't want to care anymore in the viewprocess what the actual mime-type of the Messagepart is created from.

embeded messages are already been part of the tree and have the type (EncapsulatedRfc822MessagePart), so you can detect them and display how you want.

Doable, yes.

what other solution you have in mind?

MessageTreeParser parser;
parser.setMessage();
auto embeddedMessage = parser.getEmbeddedMessages();

mmh where you add a new class, well if we go this way, than maybe we can merge that with the MessagePartRender, that also works on top of the messageparttree.

no the detection what are attachments and what not is done before. The AttachmentStrategy give you control, if you want to view the attachment and how.

How does it do that? We're not generating html.

By the properties isImage, asIcon, isHidden and I think it also makes sense to add isEmbeded.

But you can also ignore the properites of AttachmentMessagePart&AttachmentStrategy and create your own way of controling the view.

So it only sets the hidden property etc? In other words, I could also just ignore the attachment strategy?

For sure you can always ignore the properties of the MessageParts. But I think libmimetreeparser has already the one you want Iconic or Inlined are the one you are thinking of. As far as I understood.

In T3208#44398, @knauss wrote:

Here are a couple of questions that I currently face looking at the interface:

  • If I want to find all parts I have to display, let's assume I want to ignore any attachments or embedded messages, what do I look for?
    • I would assume I'd look for HtmlMessagePart, AlternativeMessagePart and TextMessagePart, but all attachments are also TextMessageParts, so I'm not sure that makes any sense.

Jepp - The detection of AttachmentMessagePart works as you do it for TextMessagePart.

My point is, if an attachment is a textmessagepart that interface is broken. Public inheritance means in almost all cases that the $DERIVED is a $BASE, so in this case AttachmentMessagePart is a TextMessagePart, which is not true. Or I just don't understand what a TextMessagePart is supposed to be.

  • It doesn't seem like simply getting the htmlContent of all parts (assuming I want to always show html if available), is not enough.

For what the htmlContent is missing?

Some testmails, I'll figure it out. As long as I know that it *should* be enough to only look at the htmlContent for all parts I want to display that is good enough for the time being.

  • Can I ignore any subparts of those parts?

Well that dependeds on parts, HTML and Alternative don't have children, TextMessagePart has children, because of the detection of GPInline. Crypto, Mime, List are parts that actually can have childs.

How can I possibly build a sane mail viewer from that? Why would I care about any of the implementation details of GPGInline or whatever?

  • If I want to find all attachments, is it sufficient to look for all AttachmentParts and all EncapsulatedRFC822Messages (assuming I want to treat both the same?)

yes

ok

  • How can I get from a part to a parent part to find the corresponding encryption/signature?
mp->parentPart()->getProperty("isSigned")

I hope you agree that this is fairly far from an easy to understand interface.

  • How to I find out for a signature/encryption who signed and to whom this message is encrypted? How can I access the corresponding key/certificate?

Currently the CryptoMessagePart::mSignatures, CryptoMessagePart::mDecryptRecipients, CryptoMessagePart::mMetaData - here we need to create the actual interface for these informations. I solved it for now with a friend to the Renderer.

We really need to start drafting actual interfaces and stop doing workarounds.

  • What do I do with AttachmentParts that are images (isImage)?

isImage is true in that case.

Would it perhaps make sense to have an "AttachmentType" enum that is set for some known types, and for the rest to have the mimeType of the attachment available?
Instead of having a variety of booleans?

if I want to show images inline?

than show them inline - where is you problem here either you use a AttachmentStrategy that return Inlined for images and use mp.asIcon or you do it with ignoring the asIcon property and use the isImage property and show them inline.

So you're saying a need to use the AttachmentStrategy just to set the asIcon boolean, which is then used to somehow exclude the image? Why would we not simply have logic in a function of the attachment part that determines based on available information what the part is?

Where is the inline image included if I ignore image parts?

nowhere - if you don't display them they are hidden.

One very hard email to parse are invitations mails. the suggest structure for all clients is:

multipart/mixed
  multipart/alternative
    text/plain
    text/calendar; method=REQUEST
  text/calendar (with a content-disposition:attachment)

(http://stackoverflow.com/questions/19523861/multipart-email-with-text-and-calendar-outlook-doesnt-recognize-ics)

Without understanding the calendar object it is not possible to stop the messageviewer to show the calender two times.

In T3208#46002, @knauss wrote:

One very hard email to parse are invitations mails. the suggest structure for all clients is:

....

Without understanding the calendar object it is not possible to stop the messageviewer to show the calender two times.

You mean because one would have to ensure that this is indeed twice the same invitation and not two different ones?

knauss moved this task from Backlog to In Progress on the Kube board.Nov 1 2016, 4:02 PM
mbohlender moved this task from In Progress to Backlog on the Kube board.Nov 8 2016, 5:56 PM
cmollekopf moved this task from Backlog to 0.1 on the Kube board.Nov 14 2016, 7:58 PM
cmollekopf edited projects, added Kube (0.1); removed Kube.
cmollekopf closed this task as Resolved.Feb 10 2017, 1:30 PM

We have a messageparser that works for the time being.