<a class="header-button" href="https://bugzilla.mozilla.org/home" title="Go to home page"> Bugzilla

Assignee

Comment 4

•

18 years ago

Motion to REOPEN this bug ========================= The initial motivation for this enhancement request was related to Thunderbird's unusual default behavior of forwarding e-mails as attachments, whereas most other e-mail clients forward messages inline by default. More recently, this setting is causing substantial problems as internet service providers increasingly filter messages for potentially harmful content. E-mails forwarded as attachments may be received not at all or with the attached message removed, thus defying the purpose and potentially reducing Thunderbird's acceptance. Consequently, this request should be revisited to ensure that the best suitable mode of forwarding e-mails is selected by default. The fix for bug 220646 has introduced an ".eml" suffix for all forwarded e-mail attachments. This causes frequently problems with provider filters, as discussed in bug 271211 and bug 380354 in more detail. While the filtering and removal of attachments simply based on the suffix is a questionable approach, it is equally concerning that Thunderbird has a default setting which likely causes such rules to be triggered in the first place. In addition to this fundamental issue, several other problems with e-mails forwarded as attachments suggest *not* to use it as the default mode for practical reasons: (1) Many e-mail clients have problems with nested MIME encodings and are therefore unable to display ".eml" attachments properly. E-mails forwarded inline have only a single level of MIME parts, thus provide an easier to handle encoding. Also, virus scanners may be more successful if the attachment is on a single level rather than having to traverse into attachments within attachments. (2) It is not possible to edit e-mails forwarded as attachment prior to sending them, unless they are edited as new. Frequently, only part of the message is supposed to be forwarded, or the sender wants to remove some header data. This is only directly possible in inlined forwards. (3) When the display of inline attachments is disabled, e-mails forwarded as attachments are not visible in the receiving client - bug 227720 - which may be confusing to end users. Also, when replying to an e-mail forwarded as attachment or subsequent inline forwards, bug 161775 and bug 227994 are contradicting each other whether or not text or images contained in the attachment should be included. There is no such ambiguity when e-mails were forwarded inline, as they simply become part of the message itself. While there are good reasons for forwarding e-mails as an attachment in certain situations, the default setting should reflect the expectations of the majority of the users, and should provide the greatest chance that the message is received and can be displayed correctly at the other end. Therefore, I would strongly argue for making "inline" the default forward setting.

Comment 5

•

18 years ago

Valid request (though not one I really support).

Status: RESOLVED → UNCONFIRMED

OS: Windows 2000 → All

Hardware: PC → All

Resolution: EXPIRED → ---

Updated

•

18 years ago

Assignee: mscott → nobody

Status: UNCONFIRMED → NEW

Ever confirmed: true

QA Contact: preferences

Updated

•

18 years ago

Whiteboard: [wontfix?]

Assignee

Comment 6

•

18 years ago

Attached patch Proposed patch (obsolete) — Details — Splinter Review

(split off attachment 287729 [details] [diff] [review] from bug 380354) Magnus, thanks for reopening this enhancement request despite your skepticism. As this affects both Thunderbird and SeaMonkey defaults, I'd propose to change this to a Core RFE for the Trunk version.

Assignee

Comment 7

•

18 years ago

As information for those who were not following bug 380354, please allow me to summarize the statements relating to the forwarding default here briefly. Bug 380354 comment #10 lists issues occurring with forwarding as attachment, depending on the presence or absence of the ".eml" extension. The following comments up to #16 explore the different types of forwarding. A conclusion that forwarding inline offers the best chance that a forwarded message is received and readable at the other end isn't disputed in any of the following comments. There appears to be no clear-cut solution for forwarding as attachment that fits all cases. Bug 380354 comment #35 reiterates the reasons for proposing inline forwarding as the default, based on prior comments and MZ forum experiences. I'm not disputing a prior statement that forwarding as attachment is the best choice to retain the structure of the original message, but argue there that the default should pragmatically reflect the option that works best for the majority of users. Bug 380354 comment #59 points out that the current default was apparently set in 1999 by bug 22791, and that the a review if a setting is still adequate seems to be reasonable while working on a related issue, as it appears that forwarding as attachment is not (or no longer) a well justified default. While the last two links point to my own comments, they were at least partially seconded by other contributors in the following comments. I couldn't find any further justification to maintain "as attachment" for the default mode stated in that bug report.

Assignee

Comment 8

•

18 years ago

Comment on attachment 289217 [details] [diff] [review] Proposed patch Flagging this for review now, no more comments but additional votes came in. The patch would change the default for the mail.forward_message_mode preference from 0 (as attachment) to 2 (inline). This would avoid the problems associated with forwarding as attachment, make it more intuitive for the inexperienced user, and ease the transition from other mail clients. It would also make Thunderbird's/SeaMonkey's default behavior more consistent with other Gecko clients (e.g., Netscape 7.x), which applied this change long before.

Attachment #289217 - Flags: superreview?(mscott)

Attachment #289217 - Flags: review?(neil)

Karsten Düsterloh

Comment 9

•

18 years ago

If you want to forward stuff, it should by default be sent with as less changes as possible - thus the default should stay "as attachment". There may be certain cases where you want to forward it inline, so there's a menu item for that. If a user wants to forward inline always, he can change that default in the preferences. So, for the time being, this is WONTFIX for SeaMonkey.

Comment 10

•

18 years ago

Are you talking about changes to the content or to the headers or to the form? - Content: That should be up to the forwarder - Headers: Only relevant when reporting spam - Form: Usually I receive things in-line When forwarding messages, it is considered basic netiquette to remove e-mail addresses from people not known to the addressee(s). This is a lot more difficult when forwarding as attachment. Besides that, when receiving messages forwarded as attachment, I have to open the attachment as well, resulting in extra actions I have to take.

neil@parkwaycc.co.uk

Comment 11

•

18 years ago

Comment on attachment 289217 [details] [diff] [review] Proposed patch As per comment #9; if Thunderbird should want this please patch all-thunderbird.js instead, thanks.

Attachment #289217 - Flags: review?(neil) → review-

Assignee

Updated

•

18 years ago

Attachment #289217 - Attachment is obsolete: true

Attachment #289217 - Flags: superreview?(mscott)

Assignee

Comment 12

•

18 years ago

Attached patch Proposed patch (TB only) (obsolete) — Details — Splinter Review

Updated patch per comment #11. As this is now affecting Thunderbird only, the review requests are changed respectively. I'm somewhat surprised by the quick dismissal of the proposed change from the SeaMonkey side, therefore some responses to comment #9. The apparent difference in thinking here is which user's expectations a default should reflect. IMHO, the argument "sent with as less changes as possible" is rather academic in nature (and it's the only argument stated in favor of keeping the current default). The problems with forwarding as attachment are well documented. An inexperienced user, possibly just switching from another application, is confused by the original message showing up just as an attachment icon, not being able to edit the message (as pointed out in comment #10), apparently missing attachments of the original message (nesting), and the message possibly not arriving or not being visible at the recipient's end. User inquiries on those issues are posted on average every other day (frequently multiple posts a day) in the MZ Thunderbird support forums. Thus, these are real problems for the end users, who often don't know how to resolve them. I agree fully with the statement that forwarding as attachment preserves the original format of the message best from a technical perspective, it is just not practical to forward by attachment in most cases, and is effectively necessary only in a few special cases (like forwarding spam to a provider for filter training). I also agree with the notion that the forward mode can be changed by the user, but - who would know better where the problem is and what he or she is supposed to do? The beginner (who frequently does not even find that setting) or the experienced user, who knows what those options actually imply? I still think (rather strongly) that a default should mainly support the "default user", and this is clearly done by the "inline" mode. The more experienced user will always find his or her way through the menus and change the mode to what he or she sees fit.

Attachment #293459 - Flags: review?(mscott)

Daifne

Comment 13

•

18 years ago

> inquiries on those issues are posted on average every other day (frequently > multiple posts a day) in the MZ Thunderbird support forums. Thus, these are > real problems for the end users, who often don't know how to resolve them. As a moderator at MZ and the most prolific helper there, I confirm that we are seeing this on an almost daily basis. Most are asking how to edit out the email addresses, but enough are also getting .eml files rejected by antivirus software on their servers. I understand the desire to keep forwards unedited, but this is just not working. With spammers collecting the addresses on forwarded messages and now servers rejecting them, it's just not functional to keep this as the default. The option needs to remain, but the default needs to be set to inline.

ceciliaj

Comment 14

•

18 years ago

About 3 - 4 months ago, all e-mail from a specific listserv arrived as 'attachment'. I can get around this by asking for 'message source' - which can be time consuming. Now, this same issue is seen on e-mail from another listserv. I have enabled 'inline attachments' - what else can I do?

Comment 15

•

18 years ago

> About 3 - 4 months ago, all e-mail from a specific listserv arrived as > 'attachment'. I can get around this by asking for 'message source' - which can > be time consuming. Now, this same issue is seen on e-mail from another > listserv. I have enabled 'inline attachments' - what else can I do? Not much you can do besides asking the listserv admins as it is on their side. Besides that, your question is completely off-topic.

Assignee

Comment 16

•

18 years ago

This enhancement request is about how Thunderbird sends forwarded e-mails by default, whereas comment #14 describes a problem on receiving and displaying such an attached message. However, the fact that users run into issues with viewing message attachments obviously supports the notion to *not* forward e-mails in this way by default.

Comment 17

•

17 years ago

I think I've warmed up on the thought of changing the default. Arguably most other mailers forward inline.

Assignee

Comment 18

•

17 years ago

Attached patch Proposed patch (TB, v2) — Details — Splinter Review

Minor housekeeping: I've removed the explicit reference to this bug from the patch, as those are provided in the CVS-log/blame information.

Attachment #293459 - Attachment is obsolete: true

Attachment #299602 - Flags: review?(mscott)

Attachment #293459 - Flags: review?(mscott)

Assignee

Comment 19

•

17 years ago

Scott, it has been three months since I flagged the original patch for review. Any opinion or other remarks from you at this time? As stated in comment #12 and confirmed in comment #13, we continue to see this being a problem for users very frequently in the forums. Thus, changing that default with the next version would definitely help to remove this hurdle, especially for new users.

Assignee

Comment 20

•

17 years ago

Comment on attachment 299602 [details] [diff] [review] Proposed patch (TB, v2) Reassigning, no reaction from Scott on review request for about six months now. It would be really good to see this change made in Thunderbird 3.0.

Attachment #299602 - Flags: review?(mscott) → review?(dmose)

Bryan Clark (DevTools PM) [:clarkbw]

Comment 21

•

17 years ago

Comment on attachment 299602 [details] [diff] [review] Proposed patch (TB, v2) Requesting ui-review on this; I'd like to get Bryan's signoff here...

Attachment #299602 - Flags: ui-review?(clarkbw)

Comment 22

•

17 years ago

Comment on attachment 299602 [details] [diff] [review] Proposed patch (TB, v2) In general I think this is the better way of forwarding, personally I've seen more problems with attached forwards than inline forwards. After doing a bit of searching it does seem that most other clients default to forward inline, though some include a menu item for forwarding as an attachment. Though I think it would take some more design than just adding something like that.

Attachment #299602 - Flags: ui-review?(clarkbw) → ui-review+

Comment 23

•

17 years ago

What do people think about adding a mode that both includes inline and as attachment and making it the default? It seems like it would address more use cases, and would have most (though not all) of the advantages of what's proposed here...

Updated

•

17 years ago

Whiteboard: [wontfix?]

Comment 24

•

17 years ago

(In reply to comment #23) > What do people think about adding a mode that both includes inline and as > attachment and making it the default? It seems like it would address more use > cases, and would have most (though not all) of the advantages of what's > proposed here... > I admit that it will split the differences in the middle, but unlike Solomon's solution, you will end up doubling the original message. Even with the cheap bandwidth and storage of the present, I don't think that is a good idea.

Comment 25

•

17 years ago

The cheap bandwidth and storage of the present are exactly why I think it's a reasonable thing to consider. Why don't you think it's a good idea?

Comment 26

•

17 years ago

For one, bandwidth isn't cheap for everyone. Secondly, are you going to guarantee that bandwidth and storage will remain cheap?

Assignee

Comment 27

•

17 years ago

(In reply to comment #23) I'm somewhat curious what use cases for a combined both-inline-and-attachment scenario you see. I don't think people would need both as it introduces some redundancy. Also, when the message/rfc822 attachment is sent with inline disposition (current default), the recipient would actually get the message displayed twice then as well, which may be confusing. For the case in comment #10 where the aim is to edit content (e.g., removing e-mail addresses), the user would have to remember to delete the attachment, which would still contain this information (keeping privacy in mind). Thus, I wouldn't see this as a preferred forwarding option, at least not as a default setting. P.S.: Thanks for the quick action on the review request.

Comment 28

•

17 years ago

Thanks for pointing out #10, I had forgotten to include that one.

David :Bienvenu

Comment 29

•

17 years ago

Maybe Dan was being truly Solomonic, because his proposal made me appreciate the proposal to change the default :-) I think doing both would be very confusing. My problem with Forward Inline is that users often mangle the forwarded message, but as Stephen Colbert says, the market has spoken, and forward inline is much preferred. I know of one large deployment that switched the default to forward inline site-wide by changing their default prefs.

Comment 30

•

17 years ago

(In reply to comment #26) > For one, bandwidth isn't cheap for everyone. Valid, but not the only consideration here. > Secondly, are you going to guarantee that bandwidth and storage will remain > cheap? Historically, Moore's law has applied pretty well to bandwidth and storage, and making some sort of decision based on the idea that's suddenly going to change seems folly. So it seems exceedingly reasonable to assume that it will continue to get cheaper for pretty much everyone. (In reply to comment #27) > (In reply to comment #23) I'm somewhat curious what use cases for a combined > both-inline-and-attachment scenario you see. One advantage is that you get any attachment that was part of the original message (eg somebody forwards something with an attached .doc). I could think of other ways to make that happen, however. Another is that some mailers (e.g. Thunderbird) can/could treat it as a regular message w.r.t. copying, replying, forwarding, etc. > I don't think people would need both as it introduces some redundancy I believe there's some amount of value in allowing the user to both edit and/or interpose comments in the original, while also providing the original unaltered, possibly for the reasons above. How much value, I'm not sure. > Also, when the message/rfc822 attachment is sent with inline disposition > (current default), the recipient would actually > get the message displayed twice then as well, which may be confusing. I agree that any such mode would not want to use Content-Disposition: inline for the attachment. > For the case in comment #10 where the aim is to edit content (e.g., removing > e-mail addresses), the user would have to remember to delete the attachment, > which would still contain this information (keeping privacy in mind). Agreed, this would fail to address comment 10. (In reply to comment #29) > Maybe Dan was being truly Solomonic, because his proposal made me appreciate > the proposal to change the default :-) I think doing both would be very > confusing. Heh; actually, no. Can you elaborate a bit on what exactly you would find confusing, and why? If we were to do such a thing, it would certainly only make sense we believed that we could structure the message in such a way that it would likely be presented in a non-confusing manner to most users (multipart/related, maybe?).

David :Bienvenu

Comment 31

•

17 years ago

I don't think many senders are going to realize we're sending two copies (suppose they edit out something that looks sensitive in the forward inline part, oblivious to the attachment!), and I think a lot of recipients are going to wonder why there's both an attachment and an inline forwarded message. If we don't set the content disposition to inline (which I agree, we can't), some users are going to double click on the attachment to see what it is, and they're going to see an other version of the forwarded message. That just seems awfully strange, especially for a default behavior. And some mail clients are going to ignore the content disposition, and try to display the attachment inline (like Thunderbird). There's no way for the recipient mail program to know that the message body and the forwarded message attachment are really the same thing (and in fact, it's very likely that they're not, if the user makes changes. We can't use multi-part alternative because they're not two representations of the same thing, and multipart related just means they're separate parts of the same document.

Jeff Beckley

Comment 32

•

17 years ago

My vote would be to default to just inline, like the patch does. I made this exact change in Penelope a while back, in order for the behavior to be consistent with Eudora. The inline + attachment feature has too many problems associated with it.

Phil Ringnalda (:philor)

Comment 33

•

17 years ago

(In reply to comment #31) > (suppose they edit out something that looks sensitive in the forward inline > part, oblivious to the attachment!) That's enough reason for me - I can see myself doing that, much less one of the millions of users not cc'ed on the bug. I think we'd be better off promoting the menu to choose between inline and attachment up to a menubutton so people who only occasionally want to forward as attachment will have that little sliver of dropdown on the button to remind them that they don't have to change their default pref (which I do most of the time, including just now, since I forget about the menu) just for one forward.

Assignee

Comment 34

•

17 years ago

(In reply to comment #30) > One advantage is that you get any attachment that was part of the original > message (eg somebody forwards something with an attached .doc). I could think > of other ways to make that happen, however. This is already the case today with forwarding inline, any attachment of the original message is reattached to the forwarding message. If the original message contains a "doc" and a "pdf" document, for example, they will be direct attachments to the composed message when forwarding it inline. In contrast, forwarding as attachment will "hide" them in the second MIME-level, not all mail clients can handle that. > I believe there's some amount of value in allowing the user to both edit and/or > interpose comments in the original, while also providing the original > unaltered, possibly for the reasons above. How much value, I'm not sure. I agree with David's comment #31 on that. If you make such a mode the default, people may not realize what they are doing, especially but not restricted to the case where they think they just edited the message and then send out the original along with it anyway. The confusion factor here is likely high on both sending and receiving ends, given that many are already confused by the current forward as attachment default.

Assignee

Comment 35

•

17 years ago

Dan, have you come to a conclusion or are you still making up your mind? It appears that the discussions two weeks ago were fairly unambiguous...

Comment 36

•

17 years ago

Comment on attachment 299602 [details] [diff] [review] Proposed patch (TB, v2) Alta88, yeah, sorry for the delay. The reasoning already in the bug is sound, and the thing I was most worried about turns out to already do the right thing: attachments do get copied over even when forwarding inline. r=dmose

Attachment #299602 - Flags: review?(dmose) → review+

Assignee

Comment 37

•

17 years ago

Attached patch Final patch (TB, v2 for check-in) — Details — Splinter Review

Thanks Dan. I have updated the patch against the current CVS version to make sure that it still applies. Check-in for trunk then, please.

Assignee: nobody → rsx11m.pub

Status: NEW → ASSIGNED

Assignee

Updated

•

17 years ago

Keywords: checkin-needed

Version: unspecified → Trunk

Assignee

Comment 38

•

17 years ago

...once the tree is open again, that is (forgot about the a2 code freeze).

Reed Loden [:reed]

Comment 39

•

17 years ago

Checking in mail/app/profile/all-thunderbird.js; /cvsroot/mozilla/mail/app/profile/all-thunderbird.js,v <-- all-thunderbird.js new revision: 1.120; previous revision: 1.119 done

Status: ASSIGNED → RESOLVED

Closed: 20 years ago → 17 years ago

Keywords: checkin-needed

Resolution: --- → FIXED

Target Milestone: --- → Thunderbird 3

Assignee

Comment 40

•

17 years ago

Great, thanks to all.

sia

Comment 41

•

17 years ago

After reading all of the comments it is still not clear what the final decision was. There seems to be significant argument for both ways. Should the option to change the default from/or to inline be included in tools/options so that whomever is used to and/or wants the forwarded email as an attachment will and those who want it changed can?