312025 - Filter action Forward Message to sends the mail as attachment regardless of option

Status: RESOLVED FIXED

(MailNews Core :: Filters, defect)

Description

[mozilla]

User-Agent:       Opera/8.50 (Windows NT 5.0; U; en)
Build Identifier: version 1.5 Beta 2 (20051006)

The value of Option-->Composition-->General-->Forward messages is "Inline".
In "message filters" I have a filter that forwards som e-mails. The reciver of 
this forward e-mail get the mail as attachemt and not as inline.

Reproducible: Always

Steps to Reproduce:
1. Go to Option->Composition->General->Forward messages and chage it to inline
2. Make a filter with the action "Forward Message to", thoose a vaild e-mail 
address
3. Send a mail that trigger the filter to the account that has the filter.
4. Check the receiving account

Actual Results:  
The receiver gets a e-mail where the original e-mail is an attachment.

Expected Results:  
Forward the mail inline.

Comment 1

[Magnus Melin [:mkmelin]]

*** Bug 321719 has been marked as a duplicate of this bug. ***

Comment 2

[Robert H Henson]

I'm not sure if this should be listed as a separate bug, but since it relates to this bug in that it arises because of the forwarding as attachments only, I add this comment. If those that know think it should be a new bug, please tell me, and I'll post it separately. 

I set up a mail rule to use the new "Forward to" facility depending on a
criterion set in the Subject field. The Forward action worked fine and test messages were forwarded. When the forwarded message is read it appears in another screen including a copy of itself as an attachment - weird in itself, but not a bug, I assume?

However - if the original forwarded message had an attachment of its own, then when the forwarded message is opened the message appears to contain two attachments, one being itself (as above), and the other the actual original attached file. Now the bug - any attempt to recover the original attached file using Detach, Detach All, Save as or Save All gives the error message "Unable to save the attachment. Please check your file name and try again later" - so it is impossible to recover the original attachment. 

 

Comment 3

[kinau]

If we set the value of Option-->Composition-->General-->Forward messages is "Inline", forward message action under filter should forward inline message instead of attachment.

Comment 4

[Robert H Henson]

(In reply to comment #3)
> If we set the value of Option-->Composition-->General-->Forward messages is
> "Inline", forward message action under filter should forward inline message
> instead of attachment.
> 

It *should* do, but it doesn't. It forwards them as attachments, as described above. When received, it is necessary to set View > Display attachments inline to view the forwarded message. 

Comment 5

[Sebastian Wain]

Very important in case of forwarding filters to mobile phones not accepting attachments in the mails.

sw

Comment 6

[Majken Connor [:Kensie]]

did this happen in the 1.0.x builds or is this a regression in 1.5.0.x?

Comment 7

[Rick A. Scovel]

Any word on progress fixing this shortcoming.

All other email clients have no problems forwarding an message inline using message filters.

It always seems Thunderbird is one step behind other email clients... I want to use Thunderbird but it always seems to come up short oneway or another.

:-(

Comment 8

[Mike Cowperthwaite]

From bug 360304 comment 1:
> This was changed intentionally in bug 298969. Confirming as RFE to make us
> follow the pref.

Comment 10

[Majken Connor [:Kensie]]

This isn't an RFE.  This is the intended behavior.  Bienvenu had to use a work around that forced the messages to forward attached so that they wouldn't send empty email.  Infact, I wouldn't call 298969 fixed, either.

Comment 11

[Nick Howitt]

I reported this as bug 360304 which was resilved into this one.

I would really like this to be fixed as an anti-phishing measure. I get quite a lot of phishing e-mails supposedly from Barclays Bank. I always forward them to Barclay's abuse reporting address so they can try to take action as soon as possible. If I forward the message manually, it goes in-line and is accepted by Barclays. If the forwarded message goes as an attachment, if bounces back to me as not accepted. Clearly the current implementation of the filter action is no use to me.

Comment 13

[WADA:World Anti-bad-Duping Agency]

Enhancement by Bug 11034 is still in progress, and currently only "fowarding as attacment" is implemented, i.e. "fowarding as inline" is not implemented yet.
(Sorry but I don't know well about "Reply with template" case) 
> Bug 11034 – new filter actions: Auto reply, forward, bounce
Watch Bug 11034, please.

Comment 15

[javaroast]

Except but 11034 has no progress.  This needs to be fixed.  Heck gmail even does this correctly

Comment 16

[Luis García Pimentel Ruiz]

I see this behaviour too in some of my users of the spanish version 2.0.0.6. I did not have this problem before. "Inline" and "attachment" show the same behaviour. It is very crippling and annoying because many servers are rejecting .eml right away. Please fix this asap!

Comment 17

[Magnus Melin [:mkmelin]]

Luis: the behaviour hasn't changed (for a release) since the filter forward action was implemented. 

Comment 18

[Luis García Pimentel Ruiz]

Well, I didn't have this problem before. Maybe it's the mail servers blocking de .eml files recently. Anyway, I think the option should work as described to the user.

Comment 19

[Christian]

When will we see a fix for this issue?

I see that it's been pending (in one form or another) since 2005?

Comment 20

[rsx11m]

(In reply to comment #18)
> Well, I didn't have this problem before. Maybe it's the mail servers blocking
> the .eml files recently.

The provider filtering was in place before, but the problem became more significant in 1.8.1.x when the ".eml" suffix was added to the filename. In its current version, the forwarding feature is therefore de facto useless with an increasing number of internet providers.

Also see bug 380354 for a general discussion on the ".eml"-suffix issue when forwarding, which could provide workarounds for automated forwarding as attachment too (once fixed). Bug 298969 mentioned in comment #8 appears to simply suppress a problem for inline forwarding using a filter, but is not solving it. Given the sum of issues with attachment-based forwarding, I agree that the user should have a choice here.

Comment 21

[rsx11m]

(In reply to comment #10)
> This isn't an RFE.  This is the intended behavior.  Bienvenu had to use a work
> around that forced the messages to forward attached so that they wouldn't send
> empty email.  Infact, I wouldn't call 298969 fixed, either.

If your last sentence is a somewhat disguised suggestion to reopen that bug, I would support this. However, judging from bug 298969 comment #2 a fix doesn't appear to be trivial, thus this may take a while.

There is an interesting alternative proposed in bug 11034 comment #59 to use the resending mechanism for automated inline forwardings, along with an idea for its implementation in #60. This would retain the original headers and leave the message format unchanged without sending it as an attachment, also important for the spam-forward case mentioned in comment #11 here. On the flip side, that wouldn't be fully compliant with the RFC, and it is unknown how ISP filters on the sending and receiving servers would react to that.

So, this looks like a trade-off either way...

Comment 22

[David :Bienvenu]

this depends on the work to make forward inline work w/o a compose window.

Comment 23

[Ed Freeman]

I found a way to fix this in TB 2.0.0.9

under tools -> options do the following:

advanced tab then click on the confi editor button under the General tab.

In the search field type inline next double click on browser.display.force_inline_alttext to set it to TRUE.

After this step is done, restart TB and all messages that you manually forward by using the forward button/icon will be inline instead of an attachment.

Comment 24

[Magnus Melin [:mkmelin]]

This bug is about what the format the filter action uses. For forwarding (using the button/icon) it uses the format set under Options | Composition | General

Comment 25

[Del Simmons]

So is this one planned to be fixed anytime soon? In the current state I am unable to use a filter to forward messages to my pager because the filter forward action is forwarding as an attachment even though Thunderbird is configured to always forward as inline. 

Any chance we'll see this issue resolved anytime soon? It seems to have been a problem for a REALLY long time.

Thanks!

Comment 27

[Carmen]

Any chance of a fix for this?  Basically re-iterating comment #25. Going to have to move to another mail app. if it isn't fixed soon.

Thanks.

Comment 28

[iLan]

Just wanted to put in my 2 cents to say that I too would like to see a fix for this bug. 

Comment 29

[Stoney Meyerhoeffer]

Good Lord.  I cannot believe that this bug has been out here for 2 years.  Every other mail client I have used does this.  This has not been an issue for me until now.  I want to forward messages to my iPhone.  Doesn't work.

Let's get this fixed guys.  You already have the code to do this either way.  Get it done.

Comment 30

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #29)
> I want to forward messages to my iPhone.  Doesn't work.

"Forward as attachment" produces problem when mobile phone in many cases, because many of them don't support message/rfc822 part.
Following is an currently available simplest/easiest workaround (recently posted to a forum in Japan), if your ISP doesn't have filtering capability or your ISP's filtering service is charged option.
  (0) Get Gmail IMAP account (free account can use 6GB)
  (1) Transfer(forward) all mails to the Gmail account by ISP's forward service
  (2) Forward mails to your iPhone by Gmail's filter
  (3) Remove message filter for "Forward" from Thunderbird's filter 
Because any of (a) Web Interface, (b) POP3, (c) Gmail IMAP(new) can be used, management of Gmail's mail box is easier than before.
If you can afford that Google reads all your mails(at least spam filter/virus checker reads all your mails), above is an effective workaround.

Comment 31

[sean webb]

(In reply to comment #29)

Agreed. Its closing 3 years now ... The code should be there and it is a major stumbling block for my getting various clients to accept thunderbird.
They have blackberries and want certain emails to be forwarded
depending on various filter criteria. The .eml generated by the filter 'forward to' cannot be opened, and until otherwise , i have no way of getting thunderbird into their setup. It should be simple to apply in-line rule 
to the filtering.
 

Comment 32

[Rick A. Scovel]

Wow, thunder"broke" still has not fixed this shortcoming... I asked for this back in 2006! Sometimes open source programs just come up short in being taken seriously - I sure wish I was a programmer but life has dealt me other cards.  

Rick A. Scovel   2006-11-29 12:38:09 PDT

Any word on progress fixing this shortcoming.

All other email clients have no problems forwarding an message inline using
message filters.

It always seems Thunderbird is one step behind other email clients... I want to
use Thunderbird but it always seems to come up short one way or another.

:-(

Comment 33

[John Windhorst]

Just another voice pleading to have this fixed for my use under WinXP & SeaMonkey.

-- 
 JohnW-Mpls

Comment 34

[Chris Keene]

http://www.mozillamessaging.com/en-US/thunderbird/3.0a2/releasenotes/

I note the 3.0a2 Alpha "Forwarded messages are inline by default", I have not tried this myself, but may well resolve this issue. If so, good news.

Comment 35

[rsx11m]

(In reply to comment #34)
> Forwarded messages are inline by default

This affects only the default setting for the forwarding mode. Thus, it won't fix the issue here.

(In reply to comment #32)
> Any word on progress fixing this shortcoming.

If you don't see any discussion here or in the related bugs, or any patches attached, unlikely that anything happened to this point.

(In reply to comment #31)
> It should be simple to apply in-line rule to the filtering.

This requires bug 400213 to be fixed first, forwarding inline doesn't work currently without a composition window involved (bug 298969).

As a reminder to the last couple of posters, there are etiquette rules listed in https://bugzilla.mozilla.org/page.cgi?id=etiquette.html on adding a comment, and many of you haven't actually voted yet for this bug.

Comment 37

[Aizoon]

Sorry if this sounds like "me too", but this makes the TB filter useless for forwarding e-mails to my mobile. I would hate to go back to a Microshaft product, but this is serious enough to make that a real possiblity. This facility is essential to the way I run my office.

Until I read this bug report, I thought it was something I'd missed in my TB configuration :-(

Comment 38

[Aizoon]

Well that's it. I've gone back to OE6, and a bustard job it was, too.

If as serious a bug as that can remain unfixed for three years, who knows what other terrors lurk.

That's All, Folks.

Comment 39

[myke amend]

I'm almost there myself. I have a filter on Thunderbird set to automatically forward emails to my phone, if they are payment notifications.

The problem is that even though I have forwarding set to "inline", thunderbird still forwards these with the ".eml" attachment, and my provider blocks them. So currently, all this (once handy) filter does, is to fill my email box with additional "sending of message failed" notifications :/

Comment 43

[Matt]

This is crazy how has such a bug lasted this long? This should be an easy fix and needs to be done due to spam block becoming so common.

Comment 44

[David :Bienvenu]

Because of the way forward inline works, it's a very difficult fix, as I explained in some bug that this is a dup of...

Comment 45

[Aizoon]

Because of this bug, I've gone back to MicroShaft Outlook Excess. It took ages to do, but I had no choice, because I needed the facility. Until it's fixed, I shan't be using T/bird again...

Comment 46

[Geoffrey Myers]

I've toyed with moving to Kmail.  My problem is that when the message is forwarded to my iPhone as an attachment, the iPhone does not recognize the .eml extenstion, so the email content is not presented.  Totally useless.  This is a combination of issues between Thunderbird not forwarding properly and the iPhone not handling the extension.  By the way, the iPhone handled these attachments fine up until a recent update.  I contacted Apple, but they claimed nothing had changed.  Just the same, if Thunderbird handled the forward properly, I wouldn't be having this issue at all.

Comment 48

[joerg]

with this critical and very old bug i've to go back to Kmail. There Inline-Forwarding works like selected in my preferences...

Comment 49

[David :Bienvenu]

Attachment: wip

this gets the basics working, though it needs some cleanup and testing.

Comment 50

[David :Bienvenu]

Attachment: cleaned up version

this gets rid of the duplicated code by adding a couple helper routines, and adds some documentation.

Comment 51

[David :Bienvenu]

Comment on attachment 413434 [details] [diff] [review]
cleaned up version

Given that rkent cares about this feature, and knows the filter code and the mime code to some extent, I'm asking him for a review, and standard8 an sr, because he knows the compose code.

Comment 52

[Kent James (:rkent)]

Review of attachment 413434 [details] [diff] [review] "cleaned up version":

Part 1: code review

+  PRInt32 forwardType = 0;

"0" is really serving as a magic number here, as forwardType is really a kind of enum. Throughout the code you are treating it as a cross between an enum and a count, which I think is confusing. Yes it is currently 2-valued, but it is still an enum as implemented, so treat it like one with stuff like

  PRInt32 forwardType = kForwardAsAttachment;

and
  if (forwardType == kForwardAsAttachment) ...

+
+  // get the MsgIdentity for the above key using AccountManager
+  nsCOMPtr <nsIMsgAccountManager> accountManager = do_GetService (NS_MSGACCOUNTMANAGER_CONTRACTID) ;
+  if (NS_FAILED(rv) || (!accountManager) ) return rv ;

and

+  account->GetDefaultIdentity(getter_AddRefs(identity));
+  NS_ENSURE_SUCCESS(rv, rv);

Yes you copied this code, but you touch it, you own it. You are checking rv values that you did not actually set in the call you are checking.

+
+  if (forwardType) // forward inline
This is another example of using forwardType as a boolean, when it is really
an enum.

+ * @param aAddInlineHeaders  true if doing a forward inline

This parameter gets immediately transferred to a forwardInline boolean, why not just call if aForwardInline?

+nsresult
+nsMsgComposeService::RunMessageThroughMimeDraft(
+            const nsACString& aMsgURI, nsMimeOutputType aOutType,
+            nsIMsgIdentity * aIdentity, const char * aOriginalMsgURI,
+            nsIMsgDBHdr * aOrigMsgHdr,
+            PRBool aAddInlineHeaders,
+            const nsAString &aForwardTo,
+            PRBool aOverrideComposeFormat,
+            nsIMsgWindow *aMsgWindow)

The code as written does not allow js code to separately specify whether to
forward inline, or forward as attachment. If I want to do separate custom filter
actions for those two choices, there is no way to do that. Perhaps elevating
RunMessageThroughMimeDraft to an idl routine would do that, but it may not be the best way to accomplish that. But please consider how, in js, I could request
forwarding of a message and control the forward type without modifying a global
preference.

+  //Create a mime parser (nsIMimeStreamConverter)to do the conversion.
Nit: space before Create

+
+  nsCOMPtr<nsIMsgWindow> topMostMsgWindow;
+  rv = mailSession->GetTopmostMsgWindow(getter_AddRefs(topMostMsgWindow));
+  NS_ENSURE_SUCCESS(rv, rv);
+  if (topMostMsgWindow)
   {
-    pMsgComposeParams->SetType(composeType);
-    pMsgComposeParams->SetFormat(format);
-    pMsgComposeParams->SetIdentity(identity);
-    pMsgComposeParams->SetComposeFields(compFields);
-    if (originalMsgURI)
-      pMsgComposeParams->SetOriginalMsgURI(originalMsgURI);
-    if (origMsgHdr)
-      pMsgComposeParams->SetOrigMsgHdr(origMsgHdr);
+    nsCOMPtr<nsIDOMWindowInternal> domWindow;
+    rv = topMostMsgWindow->GetDomWindow(getter_AddRefs(domWindow));
+    rv = pMsgCompose->Initialize(domWindow, pMsgComposeParams) ;
+    NS_ENSURE_SUCCESS(rv,rv);
OK so I'm not an expert on compose and windows stuff, but this seems really odd to me. Compose does lots of strange things to the window sent to it - like changing the type of the docshell, and trying to close it when done. That does not really seem to me to make sense for the topMostWindow in any case. For the filter case, why do you need a window at all?

I could be persuaded if you know what you are doing.
 
+NS_IMETHODIMP
+nsStreamConverter::SetForwardToAddress(const nsAString &aAddress)
+{
+  mForwardToAddress = aAddress;
+  return NS_OK;
+}
+
+
Nit: extra blank line

Part 2: testing

I'm afraid that I found I was crashing regularly with this patch installed. The 
character of the crash changed all of the time, and I will post some examples as
attachments. Generally the setup that caused me to crash, is that I was trying
to automatically forward with a message filter, a message that was created with
"forward as attachment", so that it had a attachment that was also a message.
I'll describe this more in comments associated ith my attachments.

Comment 53

[Kent James (:rkent)]

Attachment: This is the email that I edit as new, and resend

I edit this bug as new, and resend. I have the patch applied, and a message filter setup that does:

if (subject contains forward1) then (forward to [e-mail])

The crashes appear some time after I receive the resent email, and therefore the
filter has forwarded it with message inline. The character of the crashes is
not consistent, and the crash stacks are not very helpful, but I will send
some examples anyway. I also seem to recall that I got a windows message about the heap, that I was using it before writing to it or something like that. I'll try to get that more precisely if I see it again.

These are all tested on POP3 deferred to Local Folders.

Comment 54

[Kent James (:rkent)]

Attachment: DOS console output during crash 1

Comment 55

[Kent James (:rkent)]

Attachment: DOS console output during crash 2

Comment 56

[Kent James (:rkent)]

Attachment: Visual Studio stack during crash 2

Comment 57

[David :Bienvenu]

Ah, that crash is not really a crash - js assert in debug builds crashes and then exits. I see js assertions when not doing forward filter actions, so I doubt it has to do with this patch, but something broken in js/xpconnect.

Comment 58

[Kent James (:rkent)]

But it crashed regularly with your patch applied, and did not crash when it was not applied.

Comment 59

[Kent James (:rkent)]

Bienvenu, if you cannot reproduce the program failures (maybe "crashes" is too strong) than I would be happy to collect some more samples.

Comment 60

[David :Bienvenu]

I've commented out that js assertion in my tree as I couldn't even launch the app with it, but I'll see if that's been fixed...

Comment 61

[David :Bienvenu]

With your steps, I do see some things that look like memory corruption, though they start immediately after the edit message as new step, so long before the patched code is executed. Perhaps there are two different memory corruptions going on, though that makes Occam's Razor very sad.

Comment 62

[David :Bienvenu]

though maybe the fact that both edit message as new and forward inline go through the mime draft code will make it happier.

Comment 63

[David :Bienvenu]

Attachment: fix addressing most of rkent's comments

This does not address the issues of what we're doing with the message window (I need to think about that). It also doesn't address the mimedrft memory corruption issue, which I'm reasonably is not introduced by this patch, but obviously has to be addressed somehow.

Comment 64

[David :Bienvenu]

Yeah, if I run with a build w/o this patch, and try to forward inline Kent's test message, I get a heap corruption.

Comment 65

[Kent James (:rkent)]

So where does that leave us? Do plan to investigate that heap corruption as part of this work, or are you claiming that this patch should proceed because the heap corruption is unrelated?

If the latter, then I need tp do some more tests to convince myself that the corruption is equally likely with or without this patch, which wasn't my experience in my limited earlier tests. Because even if the problem already exists, if this patch exposes the problem more frequently, that is an issue that should block this patch.

Comment 66

[David :Bienvenu]

I'm trying to figure out the heap corruption first so that I don't have to claim anything. And yes, this patch would expose the problem more frequently.

Comment 67

[David :Bienvenu]

So, believe it or not (and I can feel the skepticism coming off rkent in waves :-) ) I think the memory corruption involves the url leak detection code added to nsStandardUrl.cpp - if I change netwerk/base/src/nsStandardUrl.h to look like this:

#ifdef NS_BUILD_REFCNT_LOGGING
//#define DEBUG_DUMP_URLS_AT_SHUTDOWN
#endif

then I don't see the corruption, either at edit message as new time, or when the filter fires. This code was recently added to the trunk, which is why, when I updated a different trunk tree w/o this patch, I see the same memory corruption and eventual crash. If I instrument vc's heap to validate after every allocation and free, the next free after the PR_REMOVE_LINK call in the destructor for nsStandardUrl is the one that detects the corruption. 

I kinda doubt that there's a problem with the debug url code. Maybe the end of the url was always getting crunched, but crunching the PRCList variable causes additional heap corruption.

Comment 68

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Sounds worth seeing what valgrind says.  (It works on Mac (10.5+, I think) or Linux.)

Comment 69

[David :Bienvenu]

valgrind says (after several hours of hurrying up and waiting) the same thing - the destructor for nsStandardUrl.cpp is writing into freed memory, corrupting the heap. Maybe it's simply a build dependency problem and a clobber build will fix it, but it's my turn to be skeptical.

Comment 70

[David :Bienvenu]

bug 532693 spun-off for the heap corruption issue, which is indeed not caused by this patch (or the url leak detection code, at least not directly).

Comment 71

[David :Bienvenu]

Attachment: fix addressing rkent's comments

Good question about the msgWindow. I remove the msg window stuff completely. I was afraid we needed a msg window to put up a password prompt, but we do not.

This patch also includes a bit of test cleanup, where we were not dumping exceptions correctly, which was biting me when doing some testing.

Comment 72

[Kent James (:rkent)]

Comment on attachment 417195 [details] [diff] [review]
fix addressing rkent's comments

This patch seems to include the fixes for bug 532693 as well - is that intended?

Comment 73

[David :Bienvenu]

Yes, that was intentional since you really need both patches.

Comment 74

[Kent James (:rkent)]

(In reply to comment #73)
> Yes, that was intentional since you really need both patches.

So then I guess you intend this as the trunk patch, and bug 532693 as branch only.

Comment 75

[David :Bienvenu]

yes, this is for the trunk only, since it has an interface change and I definitely want bug 532693 for the branch.

Comment 76

[Kent James (:rkent)]

Comment on attachment 417195 [details] [diff] [review]
fix addressing rkent's comments

>diff --git a/mailnews/base/util/nsMsgProtocol.cpp b/mailnews/base/util/nsMsgProtocol.cpp

...
>diff --git a/mailnews/base/util/nsMsgProtocol.h b/mailnews/base/util/nsMsgProtocol.h

...

What are these changes all about?

Comment 77

[David :Bienvenu]

ah, sorry, that's an other patch I was working on - those files should not be included in the diff.

(In reply to comment #76)
> (From update of attachment 417195 [details] [diff] [review])
> >diff --git a/mailnews/base/util/nsMsgProtocol.cpp b/mailnews/base/util/nsMsgProtocol.cpp
> 
> ...
> >diff --git a/mailnews/base/util/nsMsgProtocol.h b/mailnews/base/util/nsMsgProtocol.h
> 
> ...
> 
> What are these changes all about?

Comment 78

[Kent James (:rkent)]

Comment on attachment 417195 [details] [diff] [review]
fix addressing rkent's comments

>diff --git a/mailnews/base/util/nsMsgProtocol.cpp b/mailnews/base/util/nsMsgProtocol.cpp
...
>diff --git a/mailnews/base/util/nsMsgProtocol.h b/mailnews/base/util/nsMsgProtocol.h
...

Remove the unrelated changes to these routines.

>--- a/mailnews/compose/public/nsIMsgComposeService.idl
>+++ b/mailnews/compose/public/nsIMsgComposeService.idl

You need to roll the GUID for this changed interface.

>diff --git a/mailnews/imap/src/nsImapMailFolder.cpp b/mailnews/imap/src/nsImapMailFolder.cpp
...
>+                                             nsIMsgComposeService::kForwardAsDefault);
>+        }
>         }

Nit: need extra level of indent on first }

>diff --git a/mailnews/imap/test/unit/test_imapFolderCopy.js b/mailnews/imap/test/unit/test_imapFolderCopy.js
and others:

I assume that the repetitive fixes that you did to minor errors in various unit tests were
intentional. They seem unrelated to this current patch to me, but I won't object if they were
intentional.

>diff --git a/mailnews/mime/src/mimedrft.cpp b/mailnews/mime/src/mimedrft.cpp
...

>+  return pMsgCompose->SendMsg(nsIMsgSend::nsMsgDeliverNow, identity, nsnull, nsnull, nsnull) ;
>+  return NS_ERROR_FAILURE;
>+}

The second return is now unreachable, and should be deleted.

>+
>+

Nit: extra line

r=me with these fixes.

Comment 79

[David :Bienvenu]

Attachment: fix addressing rkent's comments

Carrying forward r+, requesting sr for the patch w/ rkent's comments addressed.

Until mozmill can at least do smtp (and imap/pop3), we can't really do a meaningful test for this. But we can request a litmus test.

I landed the test fixes and the fix for bug 532693 separately.

Comment 80

[Aizoon]

Any idea how long it will be before this appears in a usable version of T-bird? Until it does, I'm stuck with Outlook Excess.

Comment 81

[David :Bienvenu]

3.1 should have the fix - we're shooting for a 4 month cycle this time, so around April.

Comment 82

[shining366]

Thank you very much. Although we have waited nearly 4 years, we will have the bug fixed eventually.

Comment 83

[Fabrizio Castagnotto]

actually I didn't have this problem until 3.0! how can this be possible if - as I see - it is a long standing bug?

regression?

Comment 84

[David :Bienvenu]

No, afaik, it's always done a forward as attachment.

Comment 85

[Fabrizio Castagnotto]

ok, so let me explain how it went for me

I had a friend set up his thunderbird (2.x at the time) to automatically forward to me some email messages about a topic he wanted to keep me informed.

It always worked, I was able to see the full email with iPhone and GMail Webmail interface

suddenly everything changed, now I get .EML attachments all the time, and I discovered that it begun when he upgraded to TB 3.0!

seeing this bug is old, how can this be possible?

Comment 86

[David :Bienvenu]

It might just be that the forwarded message has a .eml extension, whereas it didn't have before. But it's still forwarded as an attachment.  He can turn off the .eml extension tools | options (or preferences, on the mac), compose, general, try unchecking "add extension to file name"

Comment 87

[Fabrizio Castagnotto]

... but the attached message IS a real .eml file (or so it seems, I can open it with thunderbird if I download it and double click on it)

before 3.0 it arrived just as an inline message

it looks very strange to me... anyway I am going to let my friend try and disable adding extensions, maybe with no extension the mail program will just "attach" it to the message?

I will let you know if this solved the problem

Comment 88

[Majken Connor [:Kensie]]

gmail includes "safe" attachments inline if it can. You can attach a text file and it will do so. It does sound like 3 is sending the attachments differently and so gmail is no longer displaying them inline. Feel free to send something to my email address so I can test, if you like.

Comment 89

[rsx11m]

While a bit off-topic, TB 3.0 is sending attachments with a Content-Disposition of "attachment" now (bug 65794), TB 2.0 was "inline" by default. This causes issues with the Gmail web interface not recognizing them (bug 462266). Ask the sender to change mail.content_disposition_type to 0 in the Config Editor.

Comment 90

[Fabrizio Castagnotto]

I let him change both (mail.content_disposition_type and extension) and now it works again as it was working before :)

Comment 91

[Mark Banner (:standard8)]

Comment on attachment 417704 [details] [diff] [review]
fix addressing rkent's comments


>+            nsCOMPtr<nsIMsgComposeService> compService = 
>+              do_GetService (NS_MSGCOMPOSESERVICE_CONTRACTID, &rv);

nit: no space before (

>+              nsCOMPtr<nsIMsgDBHdr> msgHdr;
>+              m_searchHitHdrs->QueryElementAt(msgIndex, NS_GET_IID(nsIMsgDBHdr), getter_AddRefs(msgHdr));

nit: this is an nsIMutableArray, so you should be able to use do_QueryElementAt here. You might have to include nsArrayUtils.h. iirc it is better for type safety.

Comment 92

[David :Bienvenu]

fix will be in 3.1 beta 1 and nightly builds.

Comment 94

[Herve]

I don't know if it is the same bug :
When I moved from TB2 to TB3 some weeks ago, I discovered this "attached instead of inline" problem on some of my messages forwarded by a filter.
Some days ago, after some tests, I discovered that I had the same problem when I forward or reply-to those messages "manually". That is I got a message where the header is forwarded but not the contains of the message : is this problem solved by 3.1 ?

Comment 95

[David :Bienvenu]

Herve, you just need to change the pref to forward as attachment, in tools | options | composition, "forward..."

Comment 96

[Herve]

I did that ! and it works for a almost all my messages but not for some.
And I had not the problem with TB2.
I have such messages in my mailbox : I can export one of them and post it somewhere if it is meaningfull

Comment 97

[rsx11m]

Has the message that you are trying to forward been forwarded to you as an attachment itself? In this case, Thunderbird would treat it like any other attachment and just reattach it to the message you compose, even if you have forwarding inline correctly configured.

Comment 98

[Herve]

I think that I see what you mean but I am not sure of the answer :
We I read the received message in TB3, there is a .eml file attached AND I can read the message inline without clicking on the attached file.
So, I suppose that it was sent to me as an attached file and TB3 is clever enough to display the message inline. And that could explain that the forwarded message contains only the attached file as in fact all the text of the message is in this .eml file even if it is displayed directly in the message by the "very clever TB3". Am I right ?
Second, if i am right, my problem is now : why the person who receives my .eml is enable to open it ?

Comment 99

[rsx11m]

The recipient would open the message attachment in the same way as you did,
it's just forwarded to him or her "as is". If you want to make it part of your
own message as composed, you'd need to use Reply rather than Forward as a workaround, with the mail.reply_quote_inline preference set to "true" to make all inlined content part of the quote in your composed message.

Since this is more of a support question than related to this bug, please utilize the forums at http://getsatisfaction.com/mozilla_messaging or http://forums.mozillazine.org/viewforum.php?f=39 (user-to-user) for a more detailed discussion if this quick advice doesn't resolve it.