search

roundcube / roundcubemail

The Roundcube Webmail suite
https://roundcube.net
GNU General Public License v3.0
5.83k stars 1.63k forks source link

List unrefered inline images as attachments #5051

Open rcubetrac opened 11 years ago

rcubetrac commented 11 years ago

Reported by zamri on 31 Oct 2012 08:53 UTC as Trac ticket #1488783

See attachment. I have opened it in Thunderbird and it contains no text message but 1 gif image as an attachment. In RC, I dont see any attachment.

Keywords: attachment, design behaviour Migrated-From: http://trac.roundcube.net/ticket/1488783

rcubetrac commented 11 years ago

Comment by @alecpl on 31 Oct 2012 09:04 UTC

In other words this is a request to add to attachments list inline related images that aren't used in HTML part (part can not exist, be empty, or just doesn't refer to the image by its content-id).

rcubetrac commented 11 years ago

Milestone changed by @alecpl on 31 Oct 2012 09:04 UTC

0.9-beta => later

rcubetrac commented 11 years ago

Summary changed by @alecpl on 31 Oct 2012 09:04 UTC

No attachment in roundcube

List unrefered inline images as attachments

rcubetrac commented 11 years ago

Comment by zamri on 1 Nov 2012 02:13 UTC

Another example added. Pls see attachment 12.zip. This one it has 'something' in the message that it doesn't show in RC and Thunderbird.

rcubetrac commented 11 years ago

Comment by @alecpl on 21 Mar 2013 11:53 UTC

Consider also listing images that are referred, but not displayed - text part is used for display. See #1489003.

rcubetrac commented 11 years ago

Comment by @alecpl on 21 Mar 2013 11:55 UTC

12.zip source is malformed. There's no headers and there's HTML content in plain/text part.

rcubetrac commented 11 years ago

Comment by xenon on 22 Mar 2013 09:43 UTC

I'm not sure how is 'right way' for displaying inline files, but quote for RFC:

2.1 The Inline Disposition Type

A bodypart should be marked `inline' if it is intended ''to be displayed automatically upon display of the message. '' Inline bodyparts should be presented in the order in which they occur, subject to the normal semantics of multipart messages.

http://tools.ietf.org/html/rfc2183

Looks like even if image is not referenced from HTML part, it still should be displayed.

Also, tested message from #1489003 on different software. Webmails: Gmail, Squirrelmail MUA: kmail, thunderbird

all of them (but not RoundCube) displays inline images.

rcubetrac commented 11 years ago

Comment by @alecpl on 22 Mar 2013 09:58 UTC

We have a setting in Roundcube with which user can decide to display them or not below the message body. It is not so simple as RFC says. What if the message is multipart/alternative? What's inline for HTML part don't need to be inline for text.

rcubetrac commented 9 years ago

Comment by @alecpl on 16 Apr 2015 19:41 UTC

Another sample in #1490355.

Pesticles commented 8 years ago

I've encountered this issue in Roundcube v1.1.4-4.11.el7.kolab_3.4

Here's a dirty patch I wrote which "fixes" the issue by forcing all inline attachments to be displayed as normal attachments:

--- ./program/lib/Roundcube/rcube_message.php.orig  2016-04-22 11:31:34.919974077 +1200
+++ ./program/lib/Roundcube/rcube_message.php   2016-04-22 11:31:04.678976612 +1200
@@ -753,6 +753,7 @@
                             $mail_part->content_location = $mail_part->headers['content-base'] . $mail_part->headers['content-location'];

                         $this->inline_parts[] = $mail_part;
+                        $this->attachments[] = $mail_part;
                     }
                     // regular attachment with valid content type
                     // (content-type name regexp according to RFC4288.4.2)

Note, this version has the option "Display attached images below message" which appears to be related to this, however I can find nowhere in the code where the option actually does anything.

It's possible the above could be handled better further down in that file, but the above works nicely so I'm going to stop there.

ner00 commented 6 years ago

I wasnt't aware that this "issue" was going on for so long. I'm using latest 1.3.6 version and also have issues with inline images not showing either inline nor as attachments. I ended up by adapting the useful suggestion above from @Pesticles that solved the issue:

                            $mail_part->content_location = $mail_part->headers['content-base'] . $mail_part->headers['content-location'];

                        $this->add_part($mail_part, 'inline');
+                       $this->add_part($mail_part, 'attachment');
                    }
                    // regular attachment with valid content type
                    // (content-type name regexp according to RFC4288.4.2)
dupgit commented 5 years ago

1.3.8 Still have this issue. Nor @Pesticles or @ner00 suggestions seems working in this version. By the way : in this version inline image are correctly shown in compose window but not in the reading window.

uj commented 5 years ago

This happens when I send a picture from an Android phone with sms to an email address. The image does not show up at all in RoundCube, either as inline nor as an attachment on the side. Just nothing at all.

The above fixes do not work with Roundcube 1.3.7 and later.

I found that I can fix it with the patch below in v1.3.7 (and this should work in later versions as well):

In the file lib/Roundcube/rcube_message.php:


                // calendar part not marked as attachment (#1490325)
                else if ($part_mimetype == 'text/calendar') {
                    if (!$mail_part->filename) {
                        $mail_part->filename = 'calendar.ics';
                    }

                    $this->add_part($mail_part, 'attachment');
                }
+       //ADD THIS ELSE STATEMENT TO FIX MISSING ATTACHMENTS
+       else
+           {                    
+           $this->add_part($mail_part, 'attachment');
+           }
            }
            // if this was a related part try to resolve references
            if (preg_match('/^multipart\/(related|relative)/', $mimetype) && count($this->inline_parts)) {
                $a_replaces = array();
                $img_regexp = '/^image\/(gif|jpe?g|png|tiff|bmp|svg)/';
dupgit commented 5 years ago

@uj: It still seem not to work in my case.

The example message I use has the following fields:

Content-Type: multipart/mixed;
    boundary=Apple-Mail-61171DF1-C781-4C1E-8298-28527926F333

…

 --Apple-Mail-61171DF1-C781-4C1E-8298-28527926F333
Content-Type: text/plain;
    charset=us-ascii
Content-Transfer-Encoding: 7bit

…

--Apple-Mail-61171DF1-C781-4C1E-8298-28527926F333
Content-Type: image/png;
    name=aglpinhgiccnbjic.png;
    x-apple-part-url="part1.B93C3970.BB2F3F54@cng.fr"
Content-Disposition: inline;
    filename=aglpinhgiccnbjic.png
Content-Transfer-Encoding: base64

The image is not showed inlined.

ner00 commented 4 years ago

I had updated Roundcube to v1.4.4 and forgot all about this just to have it happen today with an e-mail and the same approach I used for v1.3.6 (https://github.com/roundcube/roundcubemail/issues/5051#issuecomment-386619659) still worked fine for me in v1.4.4.

As a side note, opening the EML in Thunderbird displays the inline images as attachments, whereas Roundcube does not display them at all.

Below is an example of the EML code which I came accross today. Message was originally sent from Gmail - unsure if web or desktop/mobile client; then received and forwarded by Outlook 2007 client/Exchange 2000 server, lastly received by hMailServer and viewed on Roundcube 1.4.4):

Return-Path: person.a@domain.local
Received: from domain.local (server1.domain.local [192.168.12.34])
    by server2.domain.local with ESMTP
    ; Fri, 19 Jun 2020 17:39:53 +0100
Content-class: urn:content-classes:message
Return-Receipt-To: "Person A" <person.a@domain.local>
MIME-Version: 1.0
Content-Type: multipart/related;
    boundary="----_=_NextPart_001_01D64658.43C8EDDA";
    type="multipart/alternative"
Disposition-Notification-To: "Person A" <person.a@domain.local>
Subject: =?UTF-8?B?Rlc6IFRoaXMgaXMgYSB0ZXN0IHN1YmplY3Q?=
Date: Fri, 19 Jun 2020 17:39:55 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <5724D5779026FE7B43A1ACFF668CC7F988E7CA1F@server1.domain.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: =?UTF-8?B?VGhpcyBpcyBhIHRlc3Qgc3ViamVjdA==?=
Thread-Index: AdZGV/0KnZLHSJgdQGOvII69WGii0QAAEPMw
From: "Person A" <person.a@domain.local>
To: "Person B" <person.b@domain.local>

This is a multi-part message in MIME format.

------_=_NextPart_001_01D64658.43C8EDDA
Content-Type: multipart/alternative;
    boundary="----_=_NextPart_002_01D64658.43C8EDDA"

------_=_NextPart_002_01D64658.43C8EDDA
Content-Type: text/plain;
    charset="UTF-8"
Content-Transfer-Encoding: base64

[BASE64_CODE]

------_=_NextPart_002_01D64658.43C8EDDA
Content-Type: text/html;
    charset="UTF-8"
Content-Transfer-Encoding: base64

[BASE64_CODE]

------_=_NextPart_002_01D64658.43C8EDDA--

------_=_NextPart_001_01D64658.43C8EDDA
Content-Type: image/jpeg;
    name="My image 1.jpg"
Content-Transfer-Encoding: base64
Content-ID: <ii_kbmfpvi21>
Content-Description: My image 1.jpg
Content-Disposition: inline;
    filename="My image 1.jpg"
Content-Location: My%20image%201.jpg

[BASE64_CODE]

------_=_NextPart_001_01D64658.43C8EDDA
Content-Type: image/png;
    name="My image 2.png"
Content-Transfer-Encoding: base64
Content-ID: <ii_15ede0d9eaf5a302>
Content-Description: My image 2.png
Content-Disposition: inline;
    filename="My image 2.png"
Content-Location: My%20image%202.png

[BASE64_CODE]

------

As mentioned, used the same approach as before in rcube_message.php:

                    // part belongs to a related message and is linked
                    // Note: mixed is not supposed to contain inline images, but we've found such examples (#5905)
                    if (preg_match('/^multipart\/(related|relative|mixed)/', $mimetype)
                        && ($mail_part->content_id || $mail_part->content_location)
                    ) {
                        $this->add_part($mail_part, 'inline');
+           $this->add_part($mail_part, 'attachment');
                    }

Maybe not the correct approach but somehow it still works on the cases I've come accross.

bohwaz commented 1 year ago

Thanks for the patch, I proposed a PR based on this patch: #9150

Neustradamus commented 8 months ago

Dear @roundcube team, @alecpl, @thomascube, @karlitschek, @nextcloud team: Can you look the PR done by @bohwaz which solves this imported ticket from 2012 (more 11 years and 3 months)?

Thanks in advance.

Linked to:

bohwaz commented 8 months ago

@alecpl What kind of solution would be accepted? Or is this a won't fix?

bohwaz commented 8 months ago

@alecpl see #9326 for another option.