6.0.0-beta1
7/8/25

[#1077] Forwarding/replying to a base64 Content-Transfer-Encoding message
Summary Forwarding/replying to a base64 Content-Transfer-Encoding message
Queue IMP
Queue Version 4.0.1
Type Bug
State Resolved
Priority 1. Low
Owners slusarz (at) horde (dot) org
Requester clawrence (at) optimiser (dot) com
Created 01/05/2005 (7489 days ago)
Due
Updated 01/26/2005 (7468 days ago)
Assigned 01/06/2005 (7488 days ago)
Resolved 01/26/2005 (7468 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
01/26/2005 07:13:56 PM Michael Slusarz Comment #13 Reply to this comment
Yes.  I tried forwarding/replying to your message pre-patch and, as I 
mentioned in a previous entry, it worked perfectly for me.  I saw no 
base64 text in the reply/forward text at all - it was the converted 
text.



Since you seem to be the only one (or one of the very few) having this 
problem, I decided it really wouldn't be worth it to determine why 
exactly your system was causing this strange behavior so I decided to 
just go ahead and change the code.  The new code is actually a bit 
cleaner, less cumbersome, and cleans up an unused function parameter 
and doesn't affect performance so it is a better way of doing this 
anyway.
01/26/2005 06:08:37 PM clawrence (at) optimiser (dot) com Comment #12
New Attachment: bug-1077.JPG Download
Reply to this comment
Erm .. not bug-1077.bmp, see bug-1077.JPG instead.
01/26/2005 06:05:10 PM clawrence (at) optimiser (dot) com Comment #11 Reply to this comment
Without the patch, have you tried replying to the email in 
bug-1077.txt?  The "reply" compose window should show the problem.   
Likewise, the "reply to" and "forward" compose windows (see 
bug-1077.bmp attachment for screenshot).



Thanks for your continued support with this ticket.
01/26/2005 06:03:42 AM Michael Slusarz Comment #10
State ⇒ Resolved
Reply to this comment
As mentioned earlier, I still can't reproduce this (i.e. your patch 
doesn't either fix nor break anything for me).  But looking at the 
_rebuildMessage() code, we might as well do the decoding all the time 
anyway since it doesn't really add any code and makes the code a bit 
simpler.  So I'll go ahead and commit a similar solution to the one 
proposed here to HEAD, test it out for awhile, and if it doesn't break 
anything I will commit to IMP 3.0.x.
01/07/2005 10:50:43 AM clawrence (at) optimiser (dot) com Comment #9
New Attachment: imp-message-decode.diff Download
Reply to this comment
Firstly, I'm not convinced the issue reported here is correctly 
understood by all - I don't mean this to be an offense to anyone, just 
an overall feeling I getting.



Secondly, please find attached a patch which *might* address the 
issue, we are experiencing.



DISCLAIMER: As we don't know enough about the structure, logic, or 
coding styles which make up Horde, the intention of the submitted 
patch is to a) highlight the issue which plagues us, and b) hopefully 
point the right people in the direction to address the issue.  Apply 
the patch at your own peril.



Does this help to identify/reproduce the issue?
01/07/2005 08:45:26 AM clawrence (at) optimiser (dot) com Comment #8 Reply to this comment
So where do we go from here then?

Is there anything else I can provide?

Would screenshots help?


01/07/2005 08:31:27 AM Michael Slusarz Comment #7
Priority ⇒ 1. Low
Reply to this comment
It works perfectly for me also.  I have no idea why it would be doing 
this - and I have never seen this in 3+ years of coding.
01/06/2005 10:31:20 AM Jan Schneider Comment #6
Assigned to Michael Slusarz
State ⇒ Assigned
Reply to this comment
Works fine here. Michael, do you have an idea what might be happening?
01/06/2005 02:45:10 AM clawrence (at) optimiser (dot) com Comment #5
New Attachment: bug-1077.txt Download
Reply to this comment
Please find attached a sample email (filename: bug-1077.txt) detailing 
the observed experience.



HTH
01/05/2005 09:38:33 AM clawrence (at) optimiser (dot) com Comment #4 Reply to this comment
Due to the commercial nature of the email itself, I am unable to 
provide the faulting email.



However, I am in the process of trying to produce a sample email which 
produces the result.  I will upload it shortly ... sorry for the 
inconvenience.
01/05/2005 09:26:37 AM Jan Schneider Comment #3
State ⇒ Feedback
Version ⇒ 4.0.1
Reply to this comment
Can you upload the source of such a message?
01/05/2005 09:08:34 AM clawrence (at) optimiser (dot) com Comment #2 Reply to this comment
Have upgraded IMP to v4.01 just to check whether issue was resolved in 
a later release.  No joy - issue still exists.



HTH.
01/05/2005 07:56:13 AM clawrence (at) optimiser (dot) com Comment #1
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ Forwarding/replying to a base64 Content-Transfer-Encoding message
Queue ⇒ IMP
State ⇒ Unconfirmed
Reply to this comment
The situation:



Received a base64 content transfer encoded email message.  Viewing the 
message correctly decodes the email body.  Replying to the message, 
does not decode the received body - just quotes the original base64 
encoded email body.  Likewise, a similar outcome is observed when 
forwarding the received message.



Here are some of the headers of the received message:



Subject: RE: E-Learning Showcase - Market Report & Feedback

MIME-Version: 1.0

Content-Type: text/plain;

        charset="utf-8"

Content-Transfer-Encoding: base64

content-class: urn:content-classes:message

X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1

Date: Wed, 29 Dec 2004 11:20:17 +0800




Saved Queries