Embedded attachments in multipart message are not detected correctly and cannot accessed

[csb0730]

Embedded attachments (jpg pictures in my case, base64 encoded) in message from type "Content-Type: multipart/related" are not detected correctly and cannot be accessed.

If shown links in message are typed DC asks to start a new chat with link target! This is in this case the pictures link name!

Awaited behaviour: should be to present the pictures in separate messages directly in chat or to save images like attachments and show picture if link is typed.

@r10s has some example .eml file.

But additionally here some screen shots:

1) how message is displayed:

2) when link is typed:

[csb0730]

Some more informations:

Now I got a multipart message in MIME format again (sent from MS Outlook) and here I'm able to see the following mail structure:

1 - multipart/related (main part) 1.1 - multipart/alternative __a) - text part __b) - html part 1.2 - picture file attachment

I see the following in DC:

part 1.1 a) - (text part) is shown as text (correct) part 1.2 - (picture attachment) is not recognized and not shown (incorrect).

I think there is a bug in decoding messages in - interleaved - MIME multipart format.

[testbird]

https://github.com/jstedfast/gmime/ ? (listed on https://autocrypt.org/dev-status.html)

[csb0730]

Hi @r10s this issue is not solved and an would recommend this for v1.0.0 . A significant number of msg's I receive are encoded in this manner.

[r10s]

@csb0730 i've just added this issue to the Release 1.0 milestone, thank you for the hint.

[csb0730]

Only for confirmation: With version v0.17.3 not solved. Would consider this as a bug!

[r10s]

If we would display the images in the example from above, multipart/related would be treated the same way as multipart/mixed. We could do this, however, this may have other effect then :)

In my understanding, mutlipart/related is typically used to embed images in HTML, eg. to show a logo of a newsletter. Delta Chat does not - and probably never will - display HTML-content. Instead the alternative plain-text part is used - if we would display the logos under this text, this may look weired. esp. as this are not always just logos, but also spacing pixels, decorative lines and so on.

I am not sure if we want to see this stuff in delta.

However, the structure i had in mind when showing only the "first body part" (as described at https://tools.ietf.org/html/rfc2387 ) was the following - the real life seems to be different:

1. multipart/alternative
___1.1. text/plain
___1.2. multipart/related
______1.2.1. text/html
______1.2.2  image referenced from 1.2.1
______1.2.3  image referenced from 1.2.1

wondering why outlook uses mutlipart/related in the example above instead of multipart/mixed; i've just checked some messages i received from outlook accounts - the attachments there are sent as multipart/mixed.

[csb0730]

As I described above: The picture is NOT part of the html part. It is included as an extra attachment in mime structure. Text and html part are alternative. The file attachment is the second related part.

I don't know why but I see that it happens. And, it seems: it is an allowed structure!

@r10s, please see the original .eml I sent to you.

[r10s]

I don't know why but I see that it happens

would be interesting where these mails come from anyway.

would you suggest to treat multipart/related in the same way as multipart/mixed then? or what would be the difference?

[csb0730]

In principle yes because of the structure.

But even for me the difference between multipart/related and multipart/mixed is not known exactly. Is that important in this case?

Thunderbird shows this email with an html or text body AND a file attachment as far as I can remember now.

Finally two things:

• But what surprises me: Why DC wants to start a chat with the picture file?
• As I remember this mail came from an Outlook MUA.

[csb0730]

Still exists in v0.19.0 (or even v0.20.0)

[csb0730]

If a part of that multipart structure is recognized as an individual part (not included into a html part) it should be treated as a separate attachment. This should be stored in a file and that's it.

In the moment the behaviour of DC ist weird because it detects an attachment, shows it into the message, makes it NOT available as an attachment and finally (completely weird) presents a link which wants to start a chat with a picture!!!???

See this still simply as a bug.

[csb0730]

Can confirm now IOS gmail app mails with images do not get decoded properly #252 by getting a mail with a picture attachment from an IOS device too.

Mail structure is exactly like my comment from Feb 4 describes it. Attachment not shown.

[r10s]

might be related to https://github.com/deltachat/deltachat-core/issues/690