The patch costs up to $70.63

This was already fixed in DIMP several days ago.  However, there was a 
typo in this code that I just fixed a few minutes ago.

Since DIMP is now working, I could verify that this is broken in 
DIMP... You'll need to apply the same patch to DIMP's compose I guess?

Now you're talking! This is now working as expected.



Thanks again, Chuck.

I see what you mean, but it's unrelated, really - you're seeing the 
text that was in the message body dialog after you clicked forward, 
and then the text from the message/rfc822 nested part.



I agree that when forwarding the entire message we should match the 
behavior of forward from the mailbox - the forwarded message is _just_ 
in the encapsulated attachment, not also in the body - so I've made 
that change. Let me know if you have other questions, of course.

OK, after the changes were moved from the MIME module to the IMP 
module, I definitely get the FWD message twice in the attachment 
within the same email when I send it to Gmail. My Framework is up2date.



Have you tested this yourself, Chuck?

For anyone else monitoring this bug, just note that the fixes are all 
in the framework MIME package, not in IMP.

This works for me with a very complicated MIME message being forwarded 
(the forward, as rfc822, works in both IMP and on Gmail).



Michael, I'm assigning this to you to make sure this won't cause 
horrid issues somewhere else, or to see if we can make it more 
efficient by not doing it for binary parts, etc.



Thanks Marc.

Actually, only the preg_replace on the parent->toString() was needed 
(see patch attached)

I have tested with Image Attachment and tar.gz attachment: works 
great! It is in ADDITION to the patch you provided. You fixed the 
headers, I fixed the "content" of the MIME message.



Cheers.

I'll take a look; have you tested this with binary attachments and 
other things that might be mucked up by having their newlines changed? 
Also, does this replace what I committed, or is it in addition to it?

Hi Chuck,

the attached patch fixes the whole problem for me.



Thanks.



--marc

Nope, I use Postfix also.



I will take a further look at this later.

Hi Chuck,



    I think you're on the right track, but as you said, the Body still 
has the extra newlines.... which breaks any attachments you have.



I'm also using Postfix.



Thanks.

Marc, please try this patch:



http://cvs.horde.org/diff.php/framework/MIME/MIME/Headers.php?r1=1.58&r2=1.59&ty=u



(if you have the message you test with cached you'll need to clear caches)



What's going on as far as I can tell is that by the time the message 
gets to Gmail the newlines have been doubled. I've fixed it for the 
headers, which mean the message should be recognized correctly, but it 
still seems to happen to text, and I don't want to randomly replace 
newlines in the body of rfc822 parts without knowing we're dealing 
with text.



Michael, if I'm guessing correctly you may be using a different MTA 
(I'm using postfix), so when you forward to Gmail things are slightly 
different. If this all makes sense to you I'd appreciate your eyes on 
the patch I committed and thoughts on a more complete fix.

We are using this files:



*IMAP:*

courier-imap-4.1.2(sec1/sec7)



*lista PEAR:*

Package          Version  State

Archive_Tar          1.3.1    stable

Cache                    1.5.5RC4 beta

Console_Getopt    1.2      stable

Date                       1.4.7    stable

HTTP_Request      1.4.0    stable

Log                         1.9.10   stable

Net_FTP                  1.3.2    stable

Net_Socket             1.0.6    stable

Net_URL                 1.0.14   stable

PEAR                      1.4.11   stable

SOAP                      0.9.4    beta

Services_Weather  1.4.0    stable

Structures_Graph  1.0.2    stable

XML_Serializer       0.18.0   beta

XML_Util                 1.1.4    stable

Here is the list/version of my PEAR packages:



INSTALLED PACKAGES, CHANNEL PEAR.PHP.NET:

=========================================

PACKAGE            VERSION STATE

Archive_Tar        1.3.2   stable

Auth_SASL          1.0.2   stable

Console_Getopt     1.2.3   stable

DB                 1.7.13  stable

Date               1.4.7   stable

File               1.3.0   stable

File_Gettext       0.4.0   beta

Fileinfo           1.0.4   stable

HTTP_Request       1.4.1   stable

I18N               0.8.6   beta

I18N_UnicodeString 0.2.1   beta

I18Nv2             0.11.4  beta

LZF                1.4     stable

Log                1.9.11  stable

MDB2               2.4.1   stable

MDB2_Driver_mysql  1.4.1   stable

Mail               1.1.14  stable

Mail_Mime          1.5.2   stable

Mail_mimeDecode    1.5.0   stable

Net_SMTP           1.2.10  stable

Net_Sieve          1.1.5   stable

Net_Socket         1.0.8   stable

Net_URL            1.0.15  stable

PEAR               1.6.2   stable

SOAP               0.11.0  beta

Structures_Graph   1.0.2   stable

And again, this works perfectly fine here.  If I have a message with 4 
images and I forward as message/rfc822 to gmail, I see a message with 
4 images there.  If I forward a text message to gmail, I see the text 
message.

OK, it turns out that even a simple email forwarded from Horde to 
gmail is not recognised correctly as a "message/rfc822".



So we don't need to test this with attachments.

OK, I found how to test removing/adding the headers I wanted. Even 
with all the same Headers as with the email fwd by Thunderbird, GMail 
still can't crok these attachments.



  I also checked the line delimiters, and they look the same to me 
from both tests.



Anyone has some ideas of what could be wrong?

One difference I'm seeing between the forwarded message from Horde and 
the one forwarded from Thunderbird is that Horde does not add the 
"Content-Disposition: inline" header to the RFC822 MIME Part.



I tried hacking the code to set the disposition, but it seem to ignore this.



Any pointer would be appreciated.

fwiw, I have never seen this.

I have seen this same problem when forwarding an email from IMP and 
the recipient opens it in Outlook.



When selecting "Forward attachments only", the email is received 
properly, but the entire message text is there, with the attachments.

I can reproduce this, though only when forwarding the whole message, 
not if I just forward attachments.

When forwarding an email with attachments (like a PDF document) from 
IMP to a gmail account, the attachments don't show up as attachments 
but as text in the body of the message.



When forwarding the SAME email from Thunderbird (tested under Linux) 
to the same gmail account, the attachments properly show up as 
ATTACHMENTS, not in the email body.



Note: when looking at the email "source" from the gmail interface, 
there are extra newlines that show-up which might explain the behavior.