Inline images are wrongly detected as attachments

[Zero3K]

It seems that emails from a JIRA Bug Tracker are showing attachments that are not actual attachments. Here's a screenshot of the issue:

[the-djmaze]

Could you:

• Menu => view source
• copy the souce
• remove content (but keep mime parts headers)
• remove email adresses
• paste/attach result here

Because somehow jira sends a mutlipart message and SnappyMail has no clue what the parts are.

See v2.10.2 notes if you try this with v2.10.1 as it contains a bug.
https://github.com/the-djmaze/snappymail/releases/tag/v2.10.2

Your result should be like:

Content-Type: multipart/mixed;
	boundary="a1_ed8cca5e303c0e70a6a563412a16ed0d"

--a1_ed8cca5e303c0e70a6a563412a16ed0d
Content-Type: multipart/alternative;
	boundary="a2_ed8cca5e303c0e70a6a563412a16ed0d"

--a2_ed8cca5e303c0e70a6a563412a16ed0d
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"

******* TEXT DATA *****

--a2_ed8cca5e303c0e70a6a563412a16ed0d
Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset="utf-8"

******* HTML DATA *****

--a2_ed8cca5e303c0e70a6a563412a16ed0d--
--a1_ed8cca5e303c0e70a6a563412a16ed0d
Content-Transfer-Encoding: base64
Content-Type: application/pdf; name="document.pdf"
Content-Disposition: attachment; filename="document.pdf"

******* DATA *****

--a1_ed8cca5e303c0e70a6a563412a16ed0d
Content-Transfer-Encoding: base64
Content-Type: application/xml; name="document.xml"
Content-Disposition: attachment; filename="document.xml"

******* DATA *****

--a1_ed8cca5e303c0e70a6a563412a16ed0d--

[Zero3K]

Here's what you asked for:

Content-Type: multipart/related; 
   boundary="----=_Part_17702_1520386819.1641244560635"

------=_Part_17702_1520386819.1641244560635
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

------=_Part_17702_1520386819.1641244560635
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline
Content-ID: <jira-generated-image-static-comment-icon-dfaab862-aac2-441c-b070-a3e1ddf27f53>

------=_Part_17702_1520386819.1641244560635
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline
Content-ID: <jira-generated-image-avatar-d5028a4f-ddfc-4537-82c5-c4342dff43e4>

------=_Part_17702_1520386819.1641244560635
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline
Content-ID: <jira-generated-image-avatar-6604926b-380e-4518-a0b0-83ea419c5995>

------=_Part_17702_1520386819.1641244560635--

[the-djmaze]

Thanks, i see the issue.

What does work is:

Content-Type: image/png; name="image.png"
Content-Disposition: inline; filename="image.png"
Content-ID: <896394a6be3f15d4b647dccf88a9ba7b>
Content-Transfer-Encoding: base64

In case of Jira the Content-Type and Content-Disposition headers don't add name/filename so SnappyMail just makes it "ATT-[id].dat"

I could change the system with 2 things:

1. give file extension based on Content-Type
2. use inline-[id] for inline instead of ATT-[id]

[the-djmaze]

I made several changes to improve this.
Additionally i reactivated the isLinked system to hide the found inline attachments from the attachments area (just like RainLoop does).

[Zero3K]

Thanks.

[the-djmaze]

This bug is back again due to #89

I had to move loads of PHP code into JavaScript for proper parsing of PGP encrypted emails.
Eventually this will be solved again.