6.0.0-alpha14
7/2/25

[#14060] forwarding messages in the smartmobile view breaks mime boundaries and encoding
Summary forwarding messages in the smartmobile view breaks mime boundaries and encoding
Queue IMP
Queue Version 6.2.9
Type Bug
State Resolved
Priority 1. Low
Owners Horde Developers (at) , mrubinsk (at) horde (dot) org
Requester timo.veith (at) uni-tuebingen (dot) de
Created 07/20/2015 (3635 days ago)
Due
Updated 10/20/2017 (2812 days ago)
Assigned 01/25/2016 (3446 days ago)
Resolved 11/28/2016 (3138 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
10/20/2017 08:33:42 PM Git Commit Comment #5 Reply to this comment
Changes have been made in Git (FRAMEWORK_5_2):

commit 2b7c9349563f7f4048179a027a8ccd083d51df54
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Mon, 28 Nov 2016 13:17:12 -0500

Bug: 14060 Fix various Content-Type header issues when forwarding email.

In mobile view when forwarding (and maybe when sending any message
with attachments in any view) to multiple recipeients, and choosing
any encryption option (even if the email ends up not being encrypted)
- this causes multiple MIME objects to be generated (one for each recipient),
however the header object for the base part was being reused, thus causing
issues with things like MIME part boundries and charsets etc...Was an
issue in mobile view because of the way the original message is added as
an attachment during the message building.

Looks like this entire section of code was refactored in git master in
such a way that this fix is not necessary there.

  M lib/Compose.php

https://github.com/horde/imp/commit/2b7c9349563f7f4048179a027a8ccd083d51df54
11/28/2016 06:19:28 PM Michael Rubinsky Assigned to Michael Rubinsky
State ⇒ Resolved
 
11/28/2016 06:19:10 PM Git Commit Comment #4 Reply to this comment
Changes have been made in Git (FRAMEWORK_5_2):

commit 8c2478ebb8a230aa0206908fcd75f8e3ce842286
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Mon Nov 28 13:08:48 2016 -0500

     Bug: 14060 Fix various Content-Type header issues when forwarding email.

     In mobile view when forwarding (and maybe when sending any message
     with attachments in any view) to multiple recipeients, and choosing
     any encryption option (even if the email ends up not being encrypted)
     - this causes multiple MIME objects to be generated (one for each 
recipient),
     however the header object for the base part was being reused, thus causing
     issues with things like MIME part boundries and charsets etc...Was an
     issue in mobile view because of the way the original message is added as
     an attachment during the message building.

     Looks like this entire section of code was refactored in git master in
     such a way that this fix is not necessary there.

  imp/lib/Compose.php | 10 +++++-----
  1 file changed, 5 insertions(+), 5 deletions(-)

http://github.com/horde/horde/commit/8c2478ebb8a230aa0206908fcd75f8e3ce842286
01/25/2016 11:52:16 AM Jan Schneider Comment #3
Assigned to Horde DevelopersHorde Developers
State ⇒ Assigned
Reply to this comment
This doesn't happen in master, and it happens with any message 
forwarded to multiple recipients, for any recipient but the first.
07/20/2015 12:23:19 PM timo (dot) veith (at) uni-tuebingen (dot) de Comment #2
New Attachment: cc_example.eml Download
Reply to this comment
Broken mail CC recipient
07/20/2015 12:22:09 PM timo (dot) veith (at) uni-tuebingen (dot) de Comment #1
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ forwarding messages in the smartmobile view breaks mime boundaries and encoding
Queue ⇒ IMP
Milestone ⇒
Patch ⇒ No
New Attachment: to_example.eml Download
State ⇒ Unconfirmed
Reply to this comment
Hello Horde Dev team,

we have noticed that forwarding messages with CC recipients in the 
smartmobile view breaks the message for the CC recipient.

IMP create two independent messages instead of creating an envelope 
header with multiple recipients.

The content type boundary in the message of the CC recipient is the 
same as in the To recipients mail message. But in the CC message a 
different boundary is beeing used.

Also we have seen that the encoding of the message is broken.

Best regards
Timo

Saved Queries