Forward as attachment: Attachment name is subject, without ".eml" extension

VERIFIED FIXED in mozilla1.9alpha1

Status

defect
--
major
VERIFIED FIXED
16 years ago
5 years ago

People

(Reporter: rimas, Assigned: mkmelin)

Tracking

(Blocks 1 bug, {verified1.8.1, verified1.8.1.3})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

16 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 5.5; Windows 95)
Build Identifier: 

In Thunderbird, when forwarding message as an attachment, that attachment gets 
a filename "subject" instead of "subject.eml". This causes problems to, for 
example, MSOE users that get an attachment and don't know how to open it.

Reproducible: Always

Steps to Reproduce:
1. Choose any message in your inbox in thunderbird, go to "Message > Forward as 
> Attachment", enter your email address in "To:", send the message.
2. Open MSOE and check your messages. Find the one you just sent and try to 
open its attachment.
3.

Actual Results:  
You get a "Choose program for this file" dialog.

Expected Results:  
The message should have been opened with your default .eml file handler

Mozilla thunderbird does not append an extention ".eml" to a file it forwards. 
It confuses mail clients that do not rely on a specified MIME type of an 
attachment only.
Comfirmed on both Thunderbird 0.3(20030924) / Win-Me and Mozilla
2003093004-trunk / Win-Me.
Content-Type header was;
> Content-Type: message/rfc822;
>  name="Test Plain"

Note: Windows regitry HKEY_CLASSES_ROOT\.eml properly contains Content
Type="message/rfc822".

When I tested with former Mozilla, ".eml" was appended.
Following is my draft mail created by Mozilla
> Date: Mon, 24 Feb 2003 01:03:36 +0900 
> Content-Type: message/rfc822;
> name="HTML Mail.eml"

Side effect of bug 120327 bug 65827 bug 129979 bug 163254 series?

Comment 2

16 years ago
To transfer a mail containing an attached file removes the extension of this
file.  For example, if I want to transfer a mail containing a file pdf called
foobar.pdf Thunderbird will open a window of composition with like file attached
foobar without his extension.

I'm using Mozilla Thunderbird 0.4 (20031206)
Reporter

Comment 3

16 years ago
It's still not fixed :// Is anybody going to change that behaviour? I cannot
forward messages as attachments as long as all my co-workers are unable to open
these attachments easily :/

changing OS to ALL as this also happens on Linux....
OS: Windows 98 → All

Comment 4

15 years ago
I'm surprised this hasn't been opened for Mozilla Mail/News, since the problem 
does exist there as well.  Maybe I just couldn't find it, but for now I'm moving 
this.

Interesting contrast to bug 154332.

See also bug 192262, bug 209629.
Component: Message Compose Window → Composition
Product: Thunderbird → MailNews
Version: unspecified → Trunk

Updated

15 years ago
Blocks: 258454

Comment 5

15 years ago
*** Bug 262722 has been marked as a duplicate of this bug. ***

Comment 6

15 years ago
Updating summary for ease of searching.
Summary: Forwarding message as an attachment does not add ".eml" to its filename, that causes problems for users of other software. → Forward as attachment: Attachment name is subject, without ".eml" extension

Comment 7

15 years ago
*** Bug 265451 has been marked as a duplicate of this bug. ***

Comment 8

15 years ago
I am not sure if this is related, but perhaps due to this it is also not
possible to open the forwarded message in TB9 (Build 20041103, Windows XP):

1. Press "Forward" (a composition window appears with oroginal mail as attachment)
2. Double click on original mail in attachment window

Actual result  
New empty (!!!) message window appears

Expected result
New message window with original mail should appear

Comment 9

15 years ago
(In reply to comment #8)
> I am not sure if this is related, but perhaps due to this it is also not
> possible to open the forwarded message in TB9 (Build 20041103, Windows XP):

That's a TB-only bug because MailNews can't open an attachment from the compose 
window.  I've opened bug 271094 for this problem.  It may well be related to 
this bug, because an attached file.eml has a different, but still bogus, 
behavior when attempting to open from the compose window.
Product: MailNews → Core
Blocks: 269826
No longer depends on: 269826
*** Bug 189206 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Flags: blocking-thunderbird2?
Assignee

Comment 11

13 years ago
Posted patch proposed fixSplinter Review
Simple fix.
Assignee: mscott → mkmelin+bugzilla
Status: NEW → ASSIGNED
Attachment #212404 - Flags: superreview?(mscott)
Attachment #212404 - Flags: review?(mscott)
Assignee

Comment 12

13 years ago
*** Bug 258454 has been marked as a duplicate of this bug. ***

Comment 13

13 years ago
Comment on attachment 212404 [details] [diff] [review]
proposed fix

this seems reasonable to me.
Attachment #212404 - Flags: superreview?(mscott)
Attachment #212404 - Flags: superreview+
Attachment #212404 - Flags: review?(mscott)
Attachment #212404 - Flags: review+
Attachment #212404 - Flags: approval-branch-1.8.1+
Assignee

Updated

13 years ago
No longer blocks: 258454
Whiteboard: [checkin needed]

Comment 14

13 years ago
not a blocker, already has branch approval anyway.
Flags: blocking-thunderbird2?

Comment 15

13 years ago
fixed on the trunk, thx, Magnus. I'll try to get it onto the branch as well.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 16

13 years ago
fixed on 1.8.1 branch as well.
Keywords: fixed1.8.1
Whiteboard: [checkin needed]
Assignee

Comment 17

13 years ago
*** Bug 339580 has been marked as a duplicate of this bug. ***
V with TB 2a1-0523.

(In reply to comment #9)
> bug 271094 [...] may well be related to this bug

No -- that bug has the same behavior, even with this fix.
Status: RESOLVED → VERIFIED
A cautionary note:  This "feature" may cause breakage because some spam filters to  reject e-mails with .eml attachments that they were formerly passing when no .eml was forced onto the attachment name.   As an example, I've been forwarding stock spams to the US Securities and Exchange Commission for several months.  Once I upgraded to Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b2) Gecko/20060819 SeaMonkey/1.1a, the e-mails were refused:

    This message has been rejected because it has
    a potentially executable attachment "Re: ticker news1etter.eml"
    This form of attachment has been used by
    recent viruses or other malware.
    If you meant to send this file then please
    package it up as a zip file and resend it.

I realize this is stupidity on the part of the SEC to have this test on an abuse mailbox, but I do think this will cause a problem for some TB & SM users that wasn't there before.   Can the behavior be made optional?  (about:config?)  Better yet, provide a way to rename attachments before sending?
Oops, sorry about the broken sentence in the above.

"already-attached attachments should be able to be renamed" is
https://bugzilla.mozilla.org/show_bug.cgi?id=190298
Yes, I want an option to disable appending the ".eml" to the attachment name.

Virus filters that disallow attachments with the .eml file name extension are
pretty dumb.  But it's extremely commonplace now.   Red Hat, for example,
bounces all incoming email with an attachment with .eml file name extension.

I used to have no trouble forwarding emails to my colleagues at Red Hat. 
Now, I can no longer forward ANY emails to my Red Hat colleagues, simply 
because my email program is now appending .eml to file names of forwarded
messages.

So, please, let's have a way to defeat this stupid filtering.  Let's have 
an option to NOT append .eml.  Thanks.
Assignee

Updated

13 years ago
Duplicate of this bug: 365253

Comment 23

13 years ago
Wouldn't it make more sense to name the attachment .txt, as almost no one will be blocking attachments named .txt?

I'm sure naming it .eml is, or was at one time, the technically right thing to do ... but it seems that the practically right thing to do these days is identify it as a .txt file.  (and, personally, I think messageX.txt is better than $SUBJECT.txt, where the X is an integer in case there are multiple such messages attached to a single outgoing message).

Maybe the best thing would be a preference setting that gives 4 choices:  
1) .txt (default), 
2) .eml, 
3) none, 
4) ask per attachment

Comment 24

13 years ago
IMO, you shouldn't even name the attachment.  Don't use a name=xxx field in
the Content-Type header.  A Content-Type of message/rfc822 should be correctly
handled even if it is unnamed.
(In reply to comment #23)
> Wouldn't it make more sense to name the attachment .txt, as almost no one will
> be blocking attachments named .txt?

No.  Because that would be overloading the meaning of .txt, and losing important information about the content-type.

If you save out the attachment into the filesystem, and then try to open it later as a flat file, you'd want your filesystem browser (or "Finder" or whatever) to open it correctly.

For this purpose, .eml is more appropriate than .txt, which is a catch-all for any human readable ASCII content (and sometimes, not even that).

> I'm sure naming it .eml is, or was at one time, the technically right thing to
> do ... but it seems that the practically right thing to do these days is
> identify it as a .txt file.  (and, personally, I think messageX.txt is better
> than $SUBJECT.txt, where the X is an integer in case there are multiple such
> messages attached to a single outgoing message).

Well, we could classify the entire world into .bin (or .dat) and .txt extensions if we really tried hard enough...

> Maybe the best thing would be a preference setting that gives 4 choices:  
> 1) .txt (default), 
> 2) .eml, 
> 3) none, 
> 4) ask per attachment

I don't think we need additional dialogues or pop-ups per message, and certainly not multiple repetitive dialogues for the same message... so #4 is out.  And #1 would cause a message saved to the filesystem to be reopened via Notepad (or gedit, or whatever) rather than the MUA...  so #1 is out also.


(In reply to comment #24)
> IMO, you shouldn't even name the attachment.  Don't use a name=xxx field in
> the Content-Type header.  A Content-Type of message/rfc822 should be correctly
> handled even if it is unnamed.

That breaks the "Save All..." functionality of right-clicking on the attachment list at the bottom of the message panel.

Comment 27

13 years ago
>
> If you save out the attachment into the filesystem, and then try to open it
> later as a flat file, you'd want your filesystem browser (or "Finder" or
> whatever) to open it correctly.

IMO, opening it as a txt file is opening correctly.


> For this purpose, .eml is more appropriate than .txt, which is a catch-all for
> any human readable ASCII content (and sometimes, not even that).

I think that's a user choice, not a developer choice.

>
>> I'm sure naming it .eml is, or was at one time, the technically right thing to
>> do ... but it seems that the practically right thing to do these days is
>> identify it as a .txt file.  (and, personally, I think messageX.txt is better
>> than $SUBJECT.txt, where the X is an integer in case there are multiple such
>> messages attached to a single outgoing message).
>
> Well, we could classify the entire world into .bin (or .dat) and .txt
> extensions if we really tried hard enough...

The argument for that paragraph was really more about "Subject" vs "messageX" not the extension.  For that paragraph, you could just as easily change my argument to:

messageX.eml instead of $SUBJECT.eml

And, to generalize:

mesasge$ATTCHMENT_NUMBER.$EXTENSION vs $SUBJECT.$EXTENSION

I don't think using the subject in the attachment name is a good idea.


>> Maybe the best thing would be a preference setting that gives 4 choices:  1) .txt (default), 2) .eml, 3) none, 4) ask per attachment
>
> I don't think we need additional dialogues or pop-ups per message, and
> certainly not multiple repetitive dialogues for the same message... so #4 is
> out.  

In the vast majority of cases (forwarding/replying to a message where we are attaching the original message instead of quoting it), "per attachment" will be identical to "per message".  And, again, since it's not the suggested default behavior, I think this is a user preference and not a developer preference.  Give the user the option, let the user decide.

After all, thunderbird already gives them the same freedom/burden when opening attachments.

> And #1 would cause a message saved to the filesystem to be reopened via
> Notepad (or gedit, or whatever) rather than the MUA...  so #1 is out also.

Again: it's a user preference.  Let the user decide.  If you want to argue that the default should be .eml instead of .txt, go ahead.  But arguing that the user shouldn't have the choice, especially given all of the anti-virus systems out there that will block .eml files, seems rather inappropriate.

Having the developer prevent the user from making this choice is a bad idea.
(In reply to comment #27)
> >
> > If you save out the attachment into the filesystem, and then try to open it
> > later as a flat file, you'd want your filesystem browser (or "Finder" or
> > whatever) to open it correctly.
> 
> IMO, opening it as a txt file is opening correctly.

Consistency is the hobgoblin of... well, many things.  Including good user interfaces.

The app that saves a file, should be the app that reopens it.


> > For this purpose, .eml is more appropriate than .txt, which is a catch-all for
> > any human readable ASCII content (and sometimes, not even that).
> 
> I think that's a user choice, not a developer choice.
> 
> >
> >> I'm sure naming it .eml is, or was at one time, the technically right thing to
> >> do ... but it seems that the practically right thing to do these days is
> >> identify it as a .txt file.  (and, personally, I think messageX.txt is better
> >> than $SUBJECT.txt, where the X is an integer in case there are multiple such
> >> messages attached to a single outgoing message).
> >
> > Well, we could classify the entire world into .bin (or .dat) and .txt
> > extensions if we really tried hard enough...
> 
> The argument for that paragraph was really more about "Subject" vs "messageX"
> not the extension.  For that paragraph, you could just as easily change my
> argument to:
> 
> messageX.eml instead of $SUBJECT.eml
> 
> And, to generalize:
> 
> mesasge$ATTCHMENT_NUMBER.$EXTENSION vs $SUBJECT.$EXTENSION
> 
> I don't think using the subject in the attachment name is a good idea.

Yet it's unique... or more unique... so you're less likely to stomp on already saved message attachments on your Desktop.


> >> Maybe the best thing would be a preference setting that gives 4 choices:  1) .txt (default), 2) .eml, 3) none, 4) ask per attachment
> >
> > I don't think we need additional dialogues or pop-ups per message, and
> > certainly not multiple repetitive dialogues for the same message... so #4 is
> > out.  
> 
> In the vast majority of cases (forwarding/replying to a message where we are
> attaching the original message instead of quoting it), "per attachment" will be
> identical to "per message".  And, again, since it's not the suggested default
> behavior, I think this is a user preference and not a developer preference. 
> Give the user the option, let the user decide.

Well, hopefully without giving the user with which to hang himself with a really boneheaded decision that opens himself up to further security concerns...


> After all, thunderbird already gives them the same freedom/burden when opening
> attachments.
> 
> > And #1 would cause a message saved to the filesystem to be reopened via
> > Notepad (or gedit, or whatever) rather than the MUA...  so #1 is out also.
> 
> Again: it's a user preference.  Let the user decide.  If you want to argue that
> the default should be .eml instead of .txt, go ahead.  But arguing that the
> user shouldn't have the choice, especially given all of the anti-virus systems
> out there that will block .eml files, seems rather inappropriate.

Where do you stop?  Where everything is potentially configurable?  And misconfigurable?

Since it's currently fixed, but fixed to something potentially dangerous, why don't we focus (in the first cut, anyway) on getting it to something fixed that isn't dangerous?  And then we can examine if it's really the next most pressing item that "isn't configurable but really really should be"...

I'd rather have code that was solid but had few bells & whistles, than code that was buggy and insecure, but infinitely customizable.

> Having the developer prevent the user from making this choice is a bad idea.

Having the developer fix known bugs before adding further functionality of questionable value isn't.

Comment 29

13 years ago
(In reply to comment #26)
> (In reply to comment #24)
> > IMO, you shouldn't even name the attachment.  Don't use a name=xxx field in
> > the Content-Type header.  A Content-Type of message/rfc822 should be correctly
> > handled even if it is unnamed.
> 
> That breaks the "Save All..." functionality of right-clicking on the attachment
> list at the bottom of the message panel.

It looks like the need for a name is only to satisfy the Composer's ability to open an attachment. Until the user requests that the attachment be saved or opened, it can remain unnamed.

If you need a unique name at that point, incorporate the message ID and attachment index in the name, and append the ".eml". But don't put the name in the parent message's header.

The interesting case is when a .eml file is dragged into a message and recognized as a message/rfc822 attachment. One might want the option of attaching it anonymously to avoid server filter issues.
Before this bug was "fixed", I had no trouble forwarding messages to 
my correspondents.  Since it was "fixed", I CANNOT forward emails to 
my colleages and numerous companies, incuding Red Hat, whose incoming
mail servers bounce all messages with attachments whose names end in
".eml".  

Now, IMO, bouncing emails because of the names of their attachments 
is utterly absurd, Especially at a company whose employees are 
forbidden to use MSOE.  But it's a fact of life.  

I don't care about anyone who uses MSOE.  They get what they deserve.
But when I cannot forward a message to my mozilla colleages at Red Hat
because of this ".eml" file name extension, then the addition of that 
extension dis-serves me (and them).  So, I seriously want a way to turn 
this off, to STOP adding ".eml" to file names for forwarded emails. 

It's sad when I have to resort to another email client program to do
my job because mozilla's email client can no longer do the job 
satisfactorily, especially when it did it successfully for years!  :(

Comment 31

13 years ago
(In reply to comment #29)

I fully agree with Kenneth Porter's suggestion, it's the best one I've seen so far.  (and it largely agrees with, and extends, David Skoll's, but I think Kenneth added enough extra that it sways my position on the subject)
Reporter

Comment 32

13 years ago
(In reply to comment #30)
> Now, IMO, bouncing emails because of the names of their attachments 
> is utterly absurd, Especially at a company whose employees are 
> forbidden to use MSOE.  But it's a fact of life.  

Why would Thunderbird have to work around every absurdish tactics that exist around there? You, or RH employees, could simply contact the mailserver admin and ask him to remove this "security" limitation. Alternatively, they could use a different mailbox to communicate you, if it turns out that message/rfc822 attachments are banned intentionally and this is a policy of RedHat.
Assignee

Comment 33

13 years ago
Why not just use forward inline in the cases .eml is blocked? (assuming only one forwarded msg per mail).
Reporter

Comment 34

13 years ago
(In reply to comment #33)
> Why not just use forward inline in the cases .eml is blocked? (assuming only
> one forwarded msg per mail).

Exactly!
(In reply to comment #32)
> (In reply to comment #30)
> > Now, IMO, bouncing emails because of the names of their attachments 
> > is utterly absurd, Especially at a company whose employees are 
> > forbidden to use MSOE.  But it's a fact of life.  
> 
> Why would Thunderbird have to work around every absurdish tactics that exist
> around there? You, or RH employees, could simply contact the mailserver admin
> and ask him to remove this "security" limitation. Alternatively, they could use
> a different mailbox to communicate you, if it turns out that message/rfc822
> attachments are banned intentionally and this is a policy of RedHat.

I concur that whatever solution gets selected (or has already been selected, in this case), it will conflict with a misguided policy that some site has decided to employ.  In this case, I don't see any viable justification for blocking .eml attachments (unless they happen to *not* be message/rfc822 content-type).

My last employer had an untouchable (and by the same token, "out-of-touch") security group that would enact whatever policy they wanted without regard for how it might affect productivity, or how minimal the actual risk might be (which they would never actually quantify).

Sounds like something similar might be going on.


It seems that sysadmins live in their own world.  They share a set of 
"received wisdom", ideas that are thought to be true within their group
and are taken as articles of faith that cannot be disproven by mere facts.

And so it is that MANY corporations now block email with attachments with
.eml extensions, even those that are supposedly enlightened open source 
OS companies!  

Believe me, I have tried, and several RH employees have tried, to get their
IT department to drop this silliness, without success.  So like it or not,
whether sensible or not, we live in a world where attachments with .eml 
simply don't get through.  

And whose fault is it that ".eml" gets appended to the subject in the 
formation of the file name?  OURS! (that is, mozilla's mail client's).  

There are MANY reasons not to forward "in line" including (to name just two):
a) loss of all mail headers   on the forwarded email
b) loss of digital signatures on the forwarded email
(In reply to comment #36)
> It seems that sysadmins live in their own world.  They share a set of 
> "received wisdom", ideas that are thought to be true within their group
> and are taken as articles of faith that cannot be disproven by mere facts.

Ah, group-think.

> And so it is that MANY corporations now block email with attachments with
> .eml extensions, even those that are supposedly enlightened open source 
> OS companies!  
> 
> Believe me, I have tried, and several RH employees have tried, to get their
> IT department to drop this silliness, without success.  So like it or not,
> whether sensible or not, we live in a world where attachments with .eml 
> simply don't get through.  
> 
> And whose fault is it that ".eml" gets appended to the subject in the 
> formation of the file name?  OURS! (that is, mozilla's mail client's).  
> 
> There are MANY reasons not to forward "in line" including (to name just two):
> a) loss of all mail headers   on the forwarded email
> b) loss of digital signatures on the forwarded email

I agree that inline forwards are not an acceptable replacement to receiving the original message verbatim and entire.

The problem, though, is that whatever solution we come up with, somewhere someone will have some boneheaded policy against it.  We can't let that paralyze us.

Can we simply add a preference that defaults to "eml" if not otherwise set as the forward-attachment suffix?

And anyone misguided enough to set it to .txt can do so (or .msg or .822 or whatever)?

And what does Outlook/Exchange do?


It should be possible to configure it to add no suffix at all.
That will restore compatibility with the behavior before this bug 
was "fixed".

Comment 39

13 years ago
What is the problem with using no name whatsoever? Until the message lands on the disk as a unique file, I see no reason for it to have a name.
To *disagree* with comment 19, can we get the current patch on 1.8.0.x as well?  Forwarding an email whose subject ended with "... from Target.com" resulted in the SMTP server rejecting it because of the "potentially executable attachment".

Isn't .com more likely to be filtered than .eml?
Reporter

Comment 41

13 years ago
(In reply to comment #37)
> And what does Outlook/Exchange do?

AFAIR, Outlook Express only knows how to forward inline.

Comment 42

13 years ago
(In reply to comment #41)
> (In reply to comment #37)
> > And what does Outlook/Exchange do?
> 
> AFAIR, Outlook Express only knows how to forward inline.
> 

Better yet, what does (did) Eudora do? Aren't there a team of people from Eudora now working on Thunderbird issues?
Verified on the 1.8 branch using version 2.0.0.0pre (20070328) (Mac).

Comment 44

12 years ago
I agree that this ".eml" suffix MUST be made optional.  I started running into the same problem others have reported as soon as I upgraded to TB 2 -- the sysadmins at my work are using a virus scanner that flags any e-mail with an ".eml" attachment as suspected of having a virus.  I've asked them to change this, but they've refused, citing concerns over the Nimda worm.

I've gone back to TB 1.5 until/unless the ".eml" suffix can be disabled or turned into something else via a preference or a configuration option.
Reporter

Comment 45

12 years ago
heh... so it's stupid MSOE handling vs. stupid antivirus tactics now.
However, there's some difference. A virus (Nimda in this case) usually doesn't live longer than, say, a few weeks (or rather a few days). And it dates back to 2001!!!
Meanwhile, Outlook Express, released in 2001 or so, is still very common.

It's just absurd. Admins should take care to update their clients' computers and keep their antivirus definitions up to date, instead of blocking anything that has ever been misused by a virus or spammer. And if they do so, maybe they should consider to simply block e-mail traffic?

Comment 46

12 years ago
Understood and agreed, but in the meantime, the reality is that some users are stuck with situations like this and have no choice but to accommodate in some way.  Read some of the earlier comments in this bug if you've forgotten that trying to put the responsibility back on the sysadmins is frequently futile.

If people are so convinced of the rightness of the ".eml" file name extension that they can't understand any legitimate reason to change TB 2's behaviour (not even by making it changeable via a user preference in prefs.js or about:config), then could someone with experience writing extensions please step in and write something to handle this issue?  Then those of us who have to deal with ISP's or sysadmins who insist on filtering out ".eml" attachments could have a solution.
Reporter

Comment 47

12 years ago
not that I can't understand. I'm just saying there's a similar reason to keep current behaviour intact.

an option in about:config would be nice though.
(In reply to comment #47)
> not that I can't understand. I'm just saying there's a similar reason to keep
> current behaviour intact.
> 
> an option in about:config would be nice though.

As mentioned back in comment #20, bug 190298
"already-attached attachments should be able to be renamed" 
seems like an excellent solution, allowing greater flexibility.

Comment 49

12 years ago
Allowing the renaming of already-attached attachments would certainly be a nice feature, and better than the current (broken) situation in TB2, but users who know they need to avoid using ".eml" attachment file names shouldn't be forced to patch up attachment names by hand each and every time.  I still believe this filename extension needs to be configurable.

Comment 50

12 years ago
This bug is a MSOE bug!!!


As described in part 2.1, 2.2, and 2.3 of the RFC 2183 “the sender may want to suggest a filename” AND when “the receiving MUA writes the entity to a file, the suggested filename should be used as a basis for the actual filename.”

Please note that filename extension serves as a file-system specific way to identify actual type of a file which is stored in the same file-system. Email system is using MIME Content-Type for that purpose and the file extension is irrelevant and even unwanted because the file in question may be saved to a file-system that does not use filename extensions at all. MUA should add the extension, or set the creator code, or set the Type code, as appropriate for the target file-system at the time of writing to the specific file-system. 

The MIME content-type concept is invented to solve the problem of transferring files between different systems. Translation between MIME content-type and file-system specific file type is OS specific.

So, when forwarding or attaching a message we should set the Content-Disposition filename suggestion without adding any extension, or even remove any extension if it is already part of the filename.

Any MUA that is relying on the filename extension from the Content-Disposition filename field to recognize content-type is non-conforming non-interoperable and should not be used. We should not try to fix the problems of deficient substandard mailers. We should not blindly follow what MS/Outlook/Exchange would do... those mailers are not capable to recognize Content-Type: message/rfc822 field...

Reporter

Comment 51

12 years ago
(In reply to comment #50)

Milan, 

in theory, you are 100% right. However, in practice this bug saved not just users of OE, but also users of Thunderbird from the headache caused by MSOE's incompetence while not breaking anything. I think this is the main rationale for it to remain fixed as it is now.

Comment 52

12 years ago
Again, from my perspective, the real problem is that as long as TB2 insists on naming forwarded e-mail attachments with the ".eml" suffix, I'm at the mercy of sysadmins who have chosen to use a virus scanner that flags all ".eml" attachments as suspect.  I have tried to convince them that this is overkill and get them to change the default behaviour of the virus scanner, but they insist they're doing the right thing and refuse to listen to anything I say.

Thus, I can't forward messages as attachments in TB2; I have to forward inline.  It has nothing at all to do with whether the person I'm writing to is using MSOE or not; I'm talking about misbehaviour by an ISP (my ISP, and/or my recipient's ISP) -- misbehaviour which I can't change and which I understand is fairly common out there.

If there were some way for me to change the default ".eml" suffix to something else, I could start using the "forward messages as attachments" option in TB2.  Why is the idea of adding this kind of optional flexibility (for people who want to use it, but without forcing a change on people who are content with the current default behaviour) so objectionable?

Comment 53

12 years ago
(In reply to comment #51)
> 
> in theory, you are 100% right. However, in practice this bug saved not just
> users of OE, but also users of Thunderbird from the headache caused by MSOE's
> incompetence while not breaking anything. I think this is the main rationale
> for it to remain fixed as it is now.
> 

We are not in business of saving MSOE users from the MSOE's incompetence!


Comment 54

12 years ago
(In reply to comment #53)

> 
> We are not in business of saving MSOE users from the MSOE's incompetence!
> 

No, but you should be in the business of helping TB users inter-operate with all other users, and helping them save themselves from the incompetence of other mail clients.  Burying your head in the sand and saying "we don't need to deal with that, because it's just THEIR problem" is short sighted, and its own form of incompetence.

And, by the way, filename extensions aren't ONLY used by Windows and MS apps anymore.  Lots of applications use them as hints to the file contents and how to deal with them.  If you're going to complain, at least have an informed complaint.

TB should:
1) allow users to set a default attachment mechanism and file-name extension.
2) allow users to set that forwarded messages have NO file name.
3) allow users to edit attachment file names (including forwarded messages) after they have been attached.

I have yet to hear any reasonable argument against these.  All I've heard is "we don't want to" or some sort of buck passing to it being someone else's problem.

None of these counter-arguments address the needs of users to inter-operate with other users, which should be the PRIMARY concern.

Comment 55

12 years ago
(In reply to comment #54)
> 
> > 
> > We are not in business of saving MSOE users from the MSOE's incompetence!
> > 
> 
> No, but you should be in the business of helping TB users inter-operate with
> all other users, and helping them save themselves from the incompetence of
> other mail clients.  Burying your head in the sand and saying "we don't need to
> deal with that, because it's just THEIR problem" is short sighted, and its own
> form of incompetence.
> 
> And, by the way, filename extensions aren't ONLY used by Windows and MS apps
> anymore.  Lots of applications use them as hints to the file contents and how
> to deal with them.  If you're going to complain, at least have an informed
> complaint.
> 

Please note that filename extension serves as a file-system specific way to
identify actual type of a file which is stored in the same file-system. Email
system is using MIME Content-Type for that purpose and the file extension is
irrelevant and even unwanted because the file in question may be saved to a
file-system that does not use filename extensions at all. MUA should add the
extension, or set the creator code, or set the Type code, as appropriate for
the target file-system at the time of writing to the specific file-system.

Any MUA that is relying on the filename extension from the Content-Disposition
filename field to recognize content-type is non-conforming non-interoperable
and should not be used.

Comment 56

12 years ago
(In reply to comment #55)
> Any MUA that is relying on the filename extension from the Content-Disposition
> filename field to recognize content-type is non-conforming non-interoperable
> and should not be used.


When you come back to the real world, and start dealing with issues users face in the real world, let us know.

Comment 57

12 years ago
(In reply to comment #56)
> > Any MUA that is relying on the filename extension from the Content-Disposition
> > filename field to recognize content-type is non-conforming non-interoperable
> > and should not be used.
> 
> 
> When you come back to the real world, and start dealing with issues users face
> in the real world, let us know.
> 

Could somebody, from the real world, please state what was the exact real world problem that the current solution solved, how many people were facing this real world problem, and especially if there is any new trouble TB users are facing because of this, in my opinion, totally wrong solution. Extra points question: How many TB users are facing the new trouble, if any?

Assignee

Comment 58

12 years ago
People from the real world can now save their attachments and open them by double clicking their saved file. They can also avoid having their mails thrown out by *valid* filtering if they happened to have a subject like "seen the new mozilla.com"

Comment 59

12 years ago
(In reply to comment #58)
> People from the real world can now save their attachments and open them by
> double clicking their saved file. They can also avoid having their mails thrown
> out by *valid* filtering if they happened to have a subject like "seen the new
> mozilla.com"
> 

Which people? How many of them? What MUA do they use? How that affects TB users? Is there any new trouble TB users are facing because of this “solution,” and how many?
(In reply to comment #59)
> Which people? How many of them? What MUA do they use? How that affects TB
> users? Is there any new trouble TB users are facing because of this
> “solution,” and how many?

Me, for one.  And I use TB.

And it's not the MUA that are the issue.  That's what you're not getting.

It's the intervening MTA's and spam-filter relays.

Comment 61

12 years ago
(In reply to comment #60)
> Me, for one.  And I use TB.
> 
> And it's not the MUA that are the issue.  That's what you're not getting.
> 
> It's the intervening MTA's and spam-filter relays.
> 

OK, you use TB but you did not say what is your trouble. You did not explain what is the thing that I do not get. I know that there were no serious troubles for TB users until somebody "fixed" this bug.

If it is not clear what is my position go back and read Comment #50 and then carefully read RFC 2183. In short, there is no need to add any filename extension at the time when forwarded message attachment is created and attached to a message. Adding the filename extension at this time is making trouble because of widespread practice of blocking/filtering/eating-up of messages with .eml filename attachments. Therefore, the fix applied onto TB that apparently "fixed" MSOE bug is making trouble for TB users.

The filename extension can be added, if needed, when saving the attached message to a file system. Any mailer not capable to correctly recognize  an message/rfc822 attachment and not capable to save it correctly together with the file system specific content type metadata to a file on given file system is deficient. 

Go figure.

Unfortunately, this patch traded one set of problems for another set of problems.  So be it.  Seems to me there's no point in arguing about which side of the patch is more damaging.  

The answer is to get https://bugzilla.mozilla.org/show_bug.cgi?id=190298 "already-attached attachments should be able to be renamed" landed on both branch and trunk as soon as possible.  Magnus got it written but it has not been super reviewed or landed.  Why don't we chill out on this bug and root for bug 190298 landing instead??  Magnus just poked again for review, so let's sit back, munch some popcorn and see what happens.   Thanks!
(In reply to comment #61)
> OK, you use TB but you did not say what is your trouble. You did not explain
> what is the thing that I do not get. I know that there were no serious troubles
> for TB users until somebody "fixed" this bug.
> If it is not clear what is my position go back and read Comment #50 and then
> carefully read RFC 2183. In short, there is no need to add any filename
> extension at the time when forwarded message attachment is created and attached
> to a message. Adding the filename extension at this time is making trouble
> because of widespread practice of blocking/filtering/eating-up of messages with
> .eml filename attachments. Therefore, the fix applied onto TB that apparently
> "fixed" MSOE bug is making trouble for TB users.
> The filename extension can be added, if needed, when saving the attached
> message to a file system. Any mailer not capable to correctly recognize  an
> message/rfc822 attachment and not capable to save it correctly together with
> the file system specific content type metadata to a file on given file system
> is deficient. 
> Go figure.

I didn't restate the problem because it's already described in comment #40.

If you get an email with a subject such as "New specials from Amazon.com", then try to forward this message, the attachment name becomes "New specials from Amazon.com", and ".com", ".exe", ".cmd", ".pif", ".scr", ".bat", ad nauseum are all well-known exploits for Windows.

Hence many transit MTA's will filter messages containing these MIME attachments regardless of the recipient's MUA (and host operating system).

Kind of fascist, but that's the world we live in.

What system are you running TB on?  I'll see if I can build an image with a work-around fix when I have time... no promises...  Otherwise, I'll send you a .src.rpm and you can build it yourself.
Just out of curiosity, what happens if we don't name the attachment at all, as suggested in comment #50?

What if we built an image with:

--- mailnews/compose/src/nsMsgCompose.cpp	3 Feb 2006 14:18:18 -0000	1.481
+++ mailnews/compose/src/nsMsgCompose.cpp	19 Feb 2006 19:44:21 -0000
@@ -1871,7 +1871,6 @@
             nsCOMPtr<nsIMsgAttachment> attachment = do_CreateInstance(NS_MSGATTACHMENT_CONTRACTID, &rv);
             if (NS_SUCCEEDED(rv) && attachment)
             {
-              attachment->SetName(subject);
               attachment->SetUrl(uri);
               m_compFields->AddAttachment(attachment);
             }

instead?

Comment 65

12 years ago
If we're worried about subject lines like "New specials from Amazon.com", then why not encode the punctuation (e.g., New specials from Amazon%2Ecom)?

Or maybe just use a generic name like "Attached message"?

I understand the issue with potentially having an attachment name ending in ".com" or the like, but I can't accept that this should be a reason to insist on using the ".eml" suffix.
Reporter

Comment 66

12 years ago
(In reply to comment #61)
> The filename extension can be added, if needed, when saving the attached
> message to a file system. Any mailer not capable to correctly recognize  an
> message/rfc822 attachment and not capable to save it correctly together with
> the file system specific content type metadata to a file on given file system
> is deficient. 

And that's what the real world is about. It's the world of deficiency. You could just apply your argumentation against server admins with the same rate of success. Any mail server that strips attachments based on their name is deficient and should not be used, or am I wrong? :)

Comment 67

12 years ago
(In reply to comment #66)
> 
> And that's what the real world is about. It's the world of deficiency. You
> could just apply your argumentation against server admins with the same rate of
> success. Any mail server that strips attachments based on their name is
> deficient and should not be used, or am I wrong? :)
> 

Of course, but there is one important difference. Ordinary users could easily switch over from MSOE to TB and save themselves from the troubles this “fix” is “solving,” while ordinary users could not easily change the path a message has to travel over from the senders MUA to the recipients MUA. Moreover, this “fix” is causing TB users to switch back from TB 2 to TB 1.5 and even look for alternative MUA's because the messages are not getting to the recipients MUA's, they are getting eaten-up while traveling. 

Comment 68

12 years ago
(In reply to comment #50)

What about reversing the MSOE fix that was applied to TB.

For example:

--- mailnews/compose/src/nsMsgCompose.cpp	3 Feb 2006 14:18:18 -0000	1.481
+++ mailnews/compose/src/nsMsgCompose.cpp	19 Feb 2006 19:44:21 -0000
@@ -1871,7 +1871,7 @@
             nsCOMPtr<nsIMsgAttachment> attachment = do_CreateInstance(NS_MSGATTACHMENT_CONTRACTID, &rv);
             if (NS_SUCCEEDED(rv) && attachment)
             {
+              attachment->SetName(subject);
-              attachment->SetName(subject + NS_LITERAL_STRING(".eml"));
               attachment->SetUrl(uri);
               m_compFields->AddAttachment(attachment);
             }
(In reply to comment #68)
> (In reply to comment #50)
> What about reversing the MSOE fix that was applied to TB.

You're kidding, right?

That would take us back to where we were before, and would fix your problem, but revert the problem that others (such as myself) were seeing... and we could go back and forth ad infinitum, jockeying for whose inconvenience was greater...

So, rather than doing that (as much fun as it sounds like), why don't we try something *new*, such as simply not using named attachments, which you yourself recommended in comment #50 and comment #61.

My question was not a rhetorical one:  can you build and test an image with that specific fix and tell us if it works for you?

Time to "put up or shut up", as they say.  We've tried both approaches.  Both have issues.

Let's get some new data into this conversation.

If you don't have the means to build an image, I might be able to build one for you.  What's your platform?

Comment 70

12 years ago
(In reply to comment #65)
> If we're worried about subject lines like "New specials from Amazon.com", then
> why not encode the punctuation (e.g., New specials from Amazon%2Ecom)?
> 
> Or maybe just use a generic name like "Attached message"?
> 
> I understand the issue with potentially having an attachment name ending in
> ".com" or the like, but I can't accept that this should be a reason to insist
> on using the ".eml" suffix.
> 

I agree. There is no valid reason to add .eml extension nor any other filename extension at the time of creating forwarded message attachment.
(In reply to comment #70)
> I agree. There is no valid reason to add .eml extension nor any other filename
> extension at the time of creating forwarded message attachment.

Let's not confuse fact with opinion, mmmmkay?

There is no system *that you use*, perhaps, that requires a filename extension to derive the content type.  That doesn't mean they aren't out there and that other people don't use them.

Comment 72

12 years ago
(In reply to comment #71)
>
> Let's not confuse fact with opinion, mmmmkay?
>
> There is no system *that you use*, perhaps, that requires a filename extension
> to derive the content type.  That doesn't mean they aren't out there and that
> other people don't use them.
> 

Are you talking about attachment content type identifying or about content type identifying of a file which is located in a specific file system?

If you are talking about attachment content type identifying then we need the facts. We need to identify which MUA is having trouble with this, how widespread is it, how that affects TB users and at what degree. MUA's are supposed to identify content type using standard MIME content-type field.

If you are talking about content type identifying of a file which is located in a specific file system then adding of .eml filename extension at the time of attaching of a forwarded message is inappropriate. All file-system specific requirements need to be fulfilled at the time of writing to the file-system and not at the time of attaching of a forwarded message. The MIME content-type needs to be translated to a file-system specific content type identifier at the time of writing to the specific file-system. The .eml filename extension is hated by email server administrators and by antivirus/security guys. It is very likely that the message attachment with .eml filename extension will not get to the recipient which is a big trouble that TB users face today. Ordinary users are not able to choose which servers will transport a message to the recipient, but they are able to choose decent MUA that just works: TB. 

The Comment #63 problem just enhances this position and probably calls for additional sanitization of the Content-Disposition suggested filename at the time of creating of a forwarded message attachment. This could mean removing or encoding of blacklisted filename extensions or replacing dots with underscores (it seems that MS tends to fix this problem by replacing dots with underscores).

Comment 73

12 years ago
(In reply to comment #72)
> We need to identify which MUA is having trouble with this

No, we don't.  What we need to do is:

1) either:
   a) catalog which *MTA*s are having trouble with this, and then either:

   b) get those MTAs to no longer need to block/alter/quarantine messages
         that have dangerous filename extensions, which will in turn require
         the TB team forcibly eliminating all user platforms which use
         filename extensions, whether they're in use by TB users or not
         (in other words, this option is a dead end)
    OR
   c) catalog all possible mail paths that pass through those MTAs,
         and publish mail routes that go around them, or produce non-
         delivery reports for those mail servers which can't be routed
         around (also a dead end).

2) fix thunderbird so that the attachment filenames it generates aren't going to be blocked/altered/quarantined by typical and well known MTA practices.


This isn't actually an MUA issue, as you keep trying to suggest.  It's an issue where TB is butting heads with well known MTA practices.  MTAs that are obeying best practices in fighting viruses.


As I have suggested, the right thing to do is one or more of the following:

1) allow the sender to pick between "forward inline" or "forward as attachment".  At least in the application settings, but preferably with a run-time option as well (so they can chose different actions if they know that the recipient has different needs/obstacles).

2) don't name attached/forwarded/etc. email messages at all.  Preferably, make this a setting with multiple choices: "when forwarding as attachment: [] don't name the attachment, [] name the attachment with the subject, [] generate a unique safe attachment name".  (where "unique safe attachment name" wouldn't have any periods in it)  (and, I would set the initial default behavior, when you first install TB, to be "don't name the attachment")

3) allow the sender to alter any attachment name after attaching but before sending


IMO: Thunderbird should do all 3 of those, with #1 and #2 having both account preference settings AND run-time choices (setting determine default behavior, but the user can easily use a menu option to pick a different behavior than the default).
Reporter

Comment 74

12 years ago
(In reply to comment #73)
> No, we don't.  What we need to do is:
> 
> 1) either:
>    a) catalog which *MTA*s are having trouble with this, and then either:
<...>

This first solution is a dead-end anyway.

> 2) fix thunderbird so that the attachment filenames it generates aren't going
> to be blocked/altered/quarantined by typical and well known MTA practices.
> 
> This isn't actually an MUA issue, as you keep trying to suggest.  It's an issue
> where TB is butting heads with well known MTA practices.  MTAs that are obeying
> best practices in fighting viruses.

I somehow believe that a best practice in fighting viruses is actually scanning e-mails for them.

This attachment filename extension based practice is probably much rather just a paranoia of certain sysadmins.

> As I have suggested, the right thing to do is one or more of the following:
> 
> 1) allow the sender to pick between "forward inline" or "forward as
> attachment".  At least in the application settings, but preferably with a
> run-time option as well (so they can chose different actions if they know that
> the recipient has different needs/obstacles).

That is already implemented.

> 2) don't name attached/forwarded/etc. email messages at all.  Preferably, make
> this a setting with multiple choices: "when forwarding as attachment: [] don't
> name the attachment, [] name the attachment with the subject, [] generate a
> unique safe attachment name".  (where "unique safe attachment name" wouldn't
> have any periods in it)  (and, I would set the initial default behavior, when
> you first install TB, to be "don't name the attachment")

For me, not naming the attachment at all seems like probably the most logical choice. It makes the final filename depend on the MUA, its abilities and probably even settings. However, I wonder – maybe there was a reason why Mozilla decided to suggest the filename for message/rfc822 attachments?

> 3) allow the sender to alter any attachment name after attaching but before
> sending

That's a the bug #190298, I guess?

> IMO: Thunderbird should do all 3 of those, with #1 and #2 having both account
> preference settings AND run-time choices (setting determine default behavior,
> but the user can easily use a menu option to pick a different behavior than the
> default).

As for the runtime configuration, #1 is already implemented, and #2 is probably just a case of #3.
Assignee

Comment 75

12 years ago
Again, why not use forward inline? 
Users who loose mail bc of such stupid rules will loose mail from OE users too. Those admins need to wake up and stop living in 2001.

Comment 76

12 years ago
(In reply to comment #74)
> (In reply to comment #73)
> > No, we don't.  What we need to do is:
> > 
> > 1) either:
> >    a) catalog which *MTA*s are having trouble with this, and then either:
> <...>
> 
> This first solution is a dead-end anyway.

It was intended to be.

> > MTAs that are obeying best practices in fighting viruses.
> 
> I somehow believe that a best practice in fighting viruses is actually scanning
> e-mails for them.
> 
> This attachment filename extension based practice is probably much rather just
> a paranoia of certain sysadmins.

The best practice is to do _both_ (attachment checking and direct anti-virus checking).  Attachment checking catches things that are:

a) not yet on the radar of an anti-virus engine (during the earliest stages of an outbreak)

b) more narrowly focused than a virus (ie. one person directly attacking another user or a specific site to break into that site; whatever trojan they develop, if they're not just a script-kiddie, may not ever cross the radar of anti-virus signature developers)

c) easy to categorize as inappropriate, so that you can save CPU cycles instead of sending the message to your AV or AS program (ex: there's no good reason to send around directly executable files, so why not have your attachment checking engine eliminate those up front?  and not all of these will be caught by mime type checking alone)

(before you counter with "self extracting zip files", I am not ignoring that in my claim that "there's no good reason to send around directly executable files"; I include those in my "no good reason" assertion; they are convenient, yes, but convenience alone is not a sufficient argument for poor security practices)

And, no, it's not any level of paranoia beyond the level of paranoia that goes into good basic security.


(In reply to comment #75)
> Again, why not use forward inline?

Because it a lossy representation of the original message.  There are cases where you definitely want your users to be set up for sending forwarded messages as attachments (sending you anti-spam misses or false positives, so that you can submit them to your anti-spam engine's learning system; reputing abuse messages; etc.).  For your more basic user support, though, you don't want to require them to be using multiple forwarding techniques.  So, it makes the most sense to set your configuration standard as "forward as attachment".  That way the basic users don't need special hand holding in order to submit the loss-less original message to you.

> Those admins need to wake up and stop living in 2001.

Those admins aren't wrong.  Just because you don't like the practice doesn't make it a bad practice.

Comment 77

12 years ago
"reputing abuse messages" should have been "reporting abusive messages".

Comment 78

12 years ago
Let me add this, and then I'm probably going to drop out of the discussion.

The latest argument that "the MTAs along the path of the message's travel shouldn't do attachment checking" is a non-issue.  As is "whether or not OE users will also lose messages".

The fact is, you the MUA developer have no control, nor input, into what those MTAs are or aren't going to do.  The "dead-end" argument I put forward was exactly to illustrate that trying to dictate to the MTAs what they are or aren't allowed to do, outside of obeying MTA related RFCs, is a pointless avenue for an MUA developer to take.  You can't catalog them, you can't catalog and impose routes around them, etc.  You have to deal them and their implemented behaviors, whether you like it or not.

The real world is that many MTAs check attachments by filename (and good ones _also_ check them by mime type, but the point is: they DO check them by filename).  Unless you want to make your MUA defective by design, by purposefully making your MUA unable to deal with those MTAs, then you'll develop behaviors for your MUA that work within that real world.

If, however, you DO want your MUA to be defective by design, and relegate it to a niche user-base, then go right ahead.  But that's effectively the argument that's being made when pontificating about what other people _should_ do with their MTAs, instead of recognizing the reality of what other people _actually_ do with their MTAs: you are making your MUA defective by design.
Assignee

Comment 79

12 years ago
The use cases you cite against fw inline really don't give me much. 

Forwarding spam to learning systems - basic users don't do this, and that'd be one foolish system if *they* (the learning system) filter it... 

In the cases *you* want to receive an .eml you can complain to your service provider if they filter out valid mails to you. There are a lot of good free ones you can use if they don't want you as a customer.
(In reply to comment #74)
> I somehow believe that a best practice in fighting viruses is actually scanning
> e-mails for them.
> This attachment filename extension based practice is probably much rather just
> a paranoia of certain sysadmins.

The first time you see a previously unknown virus, it doesn't get filtered... it comes in, infects machines, causes havoc... you eventually root-cause the source of the virus, diagnose it, develop counter-measures, and defeat the virus.  This can take anywhere from hours to weeks.

In large organizations, some viri never completely disappear.  I know sites that still have BUGBEAR lurking.

And no "paranoid" sysadmin was ever disappointed.  Paranoia ranks on my list 2nd right after "anal-retentive" in desirable qualities.

You don't have to like your system admin.  They just have to be competent and diligent.

Their jobs might have been (in the past) to assist users.  These days, it's to protect corporate assets such as Intellectual Property.

When I worked for an email server appliance company 8 years ago, we had customers that handled 30,000 messages per hour on their corporate email relay.  Inbound only.

I'm guessing that number has gone up by an order of magnitude since then.

As has the number of viri that have to be scanned for, and the complexity of their signatures.

So saying "scan them all" sounds good, but it's harder to do effectively than you might know.

Given this harsh reality, tossing certain attachments *is* a pragmatic and effective solution.

I don't like it.  But I dislike being infected even more.


> For me, not naming the attachment at all seems like probably the most logical
> choice. It makes the final filename depend on the MUA, its abilities and
> probably even settings. However, I wonder – maybe there was a reason why
> Mozilla decided to suggest the filename for message/rfc822 attachments?

If everyone likes this so much, why isn't anyone volunteering to test an image with this fix?

(In reply to comment #78)
> The real world is that many MTAs check attachments by filename (and good ones
> _also_ check them by mime type, but the point is: they DO check them by
> filename).

Not sure I agree.  When you have files that are mailed around by disparate host OSes (such as Solaris, Linux, MacOS, and Windows) and not all OS's native desktop managers (Explorer, Gnome, Finder, etc) understand all formats (but they might have applications that know how to *import* and translate certain formats)... they don't register extension to mime-type mappings.

Which means that as often as note, the content-type of an "unknown" attachment becomes "application/octet-stream".  Sigh.

So your receiving MUA needs to figure out what the type *really* is, and grovels around for hints...  "Well, if the attachment's filename extension is .docx, and it may have come from another Windows system, then it's probably a Word Document."  Otherwise, the user has to constantly be selecting the "Save as... file type..." dialog, which quickly becomes tedious.

Comment 81

12 years ago
(In reply to comment #79)
> The use cases you cite against fw inline really don't give me much. 
> 
> Forwarding spam to learning systems - basic users don't do this, and that'd be
> one foolish system if *they* (the learning system) filter it... 
> 
> In the cases *you* want to receive an .eml you can complain to your service
> provider if they filter out valid mails to you. There are a lot of good free
> ones you can use if they don't want you as a customer.
> 


a) the user doesn't forward the message to the learning system, the user forwards the message to a sysadmin (or helpdesk, or ticket system, etc.).  The sysadmin then decides whether or not to submit the message for learning.

b) the case doesn't have to do anything to impress you.  This another of those specious arguments on your part.  If you want your MUA to be defective by design, then don't accommodate this behavior.  If you want your MUA to be able to work in all standard complaint environments, then accommodate the behavior.  Whether you like the choice or not is irrelevant.


I'm out. Thanks.  Bye.
Reporter

Comment 82

12 years ago
Disclaimer: everything below is my personal opinion.


(In reply to comment #76)
> (In reply to comment #74)
> > (In reply to comment #73)
> > > MTAs that are obeying best practices in fighting viruses.
> > 
> > I somehow believe that a best practice in fighting viruses is actually scanning
> > e-mails for them.
> > 
> > This attachment filename extension based practice is probably much rather just
> > a paranoia of certain sysadmins.
> 
> The best practice is to do _both_ (attachment checking and direct anti-virus
> checking).  Attachment checking catches things that are:
> 
> a) not yet on the radar of an anti-virus engine (during the earliest stages of
> an outbreak)

you're right at this point.

> b) more narrowly focused than a virus (ie. one person directly attacking
> another user or a specific site to break into that site; whatever trojan they
> develop, if they're not just a script-kiddie, may not ever cross the radar of
> anti-virus signature developers)

I guess you should evaluate the possibility of such message being sent at all.

If it's a virus (a program that copies and spreads itself), then it will get into the AV signatures at some point. And WHEN that point comes, depends quite a lot on its specificity and potential impact, ie, the bigger the latter is, the faster it gets into relevant databases.

If it's not a virus, you should probably again evaluate a possibility of a certain type of attachment being sent at all. Do you honestly think that most of the .eml attachments are viruses? I don't, at least not so far. Meanwhile it seems quite logical to forward email message as an attachment.

> c) easy to categorize as inappropriate, so that you can save CPU cycles instead
> of sending the message to your AV or AS program (ex: there's no good reason to
> send around directly executable files, so why not have your attachment checking
> engine eliminate those up front?  and not all of these will be caught by mime
> type checking alone)

Checking should be sane. This discussion alone shows that filtering out .eml attachments isn't as sane as it appears to some people.

> And, no, it's not any level of paranoia beyond the level of paranoia that goes
> into good basic security.

You should define what "basic security" is anyway.

> Those admins aren't wrong.  Just because you don't like the practice doesn't
> make it a bad practice.

The number/percentage of false positives does.

(In reply to comment #78)
> The real world is that many MTAs check attachments by filename (and good ones
> _also_ check them by mime type, but the point is: they DO check them by
> filename). 

So, does that suggest we shouldn't set the MIME-type either, just because some really paranoid servers filter that out?


(In reply to comment #80)
> > For me, not naming the attachment at all seems like probably the most logical
> > choice. It makes the final filename depend on the MUA, its abilities and
> > probably even settings. However, I wonder – maybe there was a reason why
> > Mozilla decided to suggest the filename for message/rfc822 attachments?
> 
> If everyone likes this so much, why isn't anyone volunteering to test an image
> with this fix?

Well, I personally could test it, but I usually forward as attachment only to my co-workers, and they all use just ONE e-mail server which always acts the same, so I guess you couldn't conclude much from my testing. OTOH, it's pretty easy to test how Outlook and Outlook Express handles unnamed messages, you don't even need an image for that...
Magnus, forward inline only works for text, and it's lousy at that.
It looses all message headers.  It's useless for messages with attachments
of any sort, or non-text contents.

Thunderbird is aboug giving users choices and empowering TB users to 
accomplish the mail/news tasks they need to accomplish.  You're hearing users 
say "TB won't let me do what I need to do, because it forces me to have a 
file name with a certain extension".  A reply of "tough, we might offend some 
OE users" puts the interests of another group (non-TB user) ahead of the interests of TB users.

Comment 84

12 years ago
(In reply to comment #82)
> 
> If it's not a virus, you should probably again evaluate a possibility of a
> certain type of attachment being sent at all. Do you honestly think that most
> of the .eml attachments are viruses? I don't, at least not so far. Meanwhile it
> seems quite logical to forward email message as an attachment.
> 

Of course, but the attachment does not have to have .eml extension, except for MSOE recipients. In fact incompetence of MSOE developers is the main cause why .eml extension got such a bad treatment from MTA administrators and antivirus/security guys. 

You can not change the behaviour of MSOE developers, MTA administrators, and antivirus/security guys, but you can just reverse this patch and bring back forwarding without .eml extension as it was in TB 1.5 (Bug 380354); sanitize the suggested file name created from the message subject (Bug 271211) ; and let TB users to be able to rename the suggested file name of any attachment (Bug 190298);

Note:  Bug  271211 description claims that MS Outlook converts dots to underscores so the received attachment ends with _eml not .eml
Reporter

Comment 85

12 years ago
(In reply to comment #83)
> Thunderbird is aboug giving users choices and empowering TB users to 
> accomplish the mail/news tasks they need to accomplish.  You're hearing users 
> say "TB won't let me do what I need to do, because it forces me to have a 
> file name with a certain extension".  A reply of "tough, we might offend some 
> OE users" puts the interests of another group (non-TB user) ahead of the
> interests of TB users.

Being a Thunderbird user, I can assure you that it is my interest to get my forwarded message read without problems, even in MSOE. MSOE and MS Outlook are probably two most popular e-mail agents around there, you just can't ignore them no matter how broken they are.

(In reply to comment #84)
> Of course, but the attachment does not have to have .eml extension, except for
> MSOE recipients. In fact incompetence of MSOE developers is the main cause why
> .eml extension got such a bad treatment from MTA administrators and
> antivirus/security guys.

You're right, but you have to understand that ignoring incompatibility with the mainstream software won't bring Tb any new customers.

> You can not change the behaviour of MSOE developers, MTA administrators, and
> antivirus/security guys, but you can just reverse this patch and bring back
> forwarding without .eml extension as it was in TB 1.5 (Bug 380354);

Not acceptable.

> sanitize the suggested file name created from the message subject
> (Bug 271211);

I think sanitizing is a good thing, but .eml should stay there.

> and let TB users to be able to rename the suggested file name of any
> attachment (Bug 190298);

That is a more generic bug and should be fixed on its own, of course.

> Note:  Bug  271211 description claims that MS Outlook converts dots to
> underscores so the received attachment ends with _eml not .eml

It's kind of hard to believe, actually. I suspect Outlook actually leaves .eml alone (otherwise there's absolutely no point to add _eml at all).

BTW, just how many bugs has this discussion spread to?
Assignee

Comment 86

12 years ago
Far too many. Especially as most of it is advocacy which doesn't really belong in bugzilla. Yes, I did my part too:( I'll shut up now, and aim for getting bug 190298 in...

Comment 87

12 years ago
(In reply to comment #85)
> Being a Thunderbird user, I can assure you that it is my interest to get my
> forwarded message read without problems, even in MSOE. MSOE and MS Outlook are
> probably two most popular e-mail agents around there, you just can't ignore
> them no matter how broken they are.
> 
> (In reply to comment #84)
> > Of course, but the attachment does not have to have .eml extension, except for
> > MSOE recipients. In fact incompetence of MSOE developers is the main cause why
> > .eml extension got such a bad treatment from MTA administrators and
> > antivirus/security guys.
> 
> You're right, but you have to understand that ignoring incompatibility with the
> mainstream software won't bring Tb any new customers.
> 

Take a look at "Security issues" and "Handling of PGP/MIME signed messages" at http://en.wikipedia.org/wiki/Outlook_Express and note that this troublesome application is, in fact,  discontinued.

Reporter

Comment 88

12 years ago
(In reply to comment #87)
> Take a look at "Security issues" and "Handling of PGP/MIME signed messages" at
> http://en.wikipedia.org/wiki/Outlook_Express and note that this troublesome
> application is, in fact,  discontinued.

You too, take a look at the facts about its population. I know it sucks, yes, but it's still too popular to be ignored.

Furthermore, this troublesome application exists in not so much discontinued Vista by name of Windows Mail. And it also has a successor named Windows Live Mail, which, I suspect, will suffer from the same problems you described.

Comment 89

12 years ago
(In reply to comment #85)
> 
> > Note:  Bug  271211 description claims that MS Outlook converts dots to
> > underscores so the received attachment ends with _eml not .eml
> 
> It's kind of hard to believe, actually. I suspect Outlook actually leaves .eml
> alone (otherwise there's absolutely no point to add _eml at all).
> 

If you do not agree give us something more than suspicion.

(In reply to comment #88)
> 
> You too, take a look at the facts about its population. I know it sucks, yes,
> but it's still too popular to be ignored.

Where are the facts? I'm asking about those facts from the beginning of my discussion here. How widespread this troublesome application is, at what degree TB users are affected by *not adding* .eml filename extension at the time of creating the forwarded message attachment, at what degree TB users are affected by *adding* .eml filename extension at the time of creating the forwarded message attachment? I would like to see the facts. 

> Furthermore, this troublesome application exists in not so much discontinued
> Vista by name of Windows Mail. And it also has a successor named Windows Live
> Mail, which, I suspect, will suffer from the same problems you described.
> 

Do not just suspect, if you do not agree give us the facts.

Please refrain from commenting when you don't have new information to add, thanks. If you want hard numbers and you think it's feasible to get them, go for it. If you want to disprove a suspicion, test it.

Comment 91

12 years ago
(In reply to comment #88)
> Furthermore, this troublesome application exists in not so much discontinued
> Vista by name of Windows Mail. And it also has a successor named Windows Live
> Mail, which, I suspect, will suffer from the same problems you described.

Windows Mail Version 6.0.6000.16386 does not have any trouble receiving/showing up/saving messages forwarded as attachments without .eml extensions. Moreover, when you save the message attachment it will add the .eml extension to the suggested file name that does not have it. I just tested it by forwarding a message as attachment from TB 1.5.

The forwarded messages as attachment without .eml extension problem is becoming obsolete together with discontinuation of MSOE. 

We should:

1. Revert this patch as soon as possible, and bring back forwarding as it was in TB 1.5!
2. Sanitize the suggested attachment file name generated from the message subject to deal with Comment #63 problem

Any other suspicions?
(In reply to comment #91)
> We should:
> 1. Revert this patch as soon as possible, and bring back forwarding as it was
> in TB 1.5!
> 2. Sanitize the suggested attachment file name generated from the message
> subject to deal with Comment #63 problem
> Any other suspicions?

Repeating yourself doesn't add any weight to your arguments.

In fact, it makes people *less* likely to follow this thread, or contribute to it, if they suspect they're going to be beaten down with the same repetitive comments.

So, in the interests of keeping discussion on this thread relevant and concise, please state your case once and only once.

We all want the right solution for this issue: but driving people away who might otherwise have contributed useful insight isn't going to make that happen.

And for what it
Bugger.  Hate the keyboard on this Dell.

As I was saying, for what it's worth (re: Comment #91), the use of .eml might be *in the process* of being phased out, but it will take a long time for that to be the case.

Commercial software release cycles don't happen with the frequency of popular open source projects.

In other words, don't expect the use of .eml to vanish completely for 5 or more years, assuming what you say is true.
(In reply to comment #0)
> In Thunderbird, when forwarding message as an attachment, that attachment gets 
> a filename "subject" instead of "subject.eml". This causes problems to, for 
> example, MSOE users that get an attachment and don't know how to open it.

> 2. Open MSOE and check your messages. Find the one you just sent and try to 
> open its attachment.
> 3.
> 
> Actual Results:  
> You get a "Choose program for this file" dialog.
> 
> Expected Results:  
> The message should have been opened with your default .eml file handler
> 

(In reply to comment #3)
> It's still not fixed :// Is anybody going to change that behaviour? I cannot
> forward messages as attachments as long as all my co-workers are unable to open
> these attachments EASILY :/
[my emphasis]

For the record, what are the options for an MSOE user who receives a forwarded e-mail as an attachment without a .eml extension?  

Are they totally screwed?
Sounds like they get a program picker option if they click on it. (Yeah, ugly)
Can they Save As and rename it?
Other workarounds?

Seems to me that we've introduced considerable bustage with this "fix", mainly for the *convenience* of MSOE users.  Comment #19 noted, but subjects with unfortunate endings only happen sometimes.  .eml now happens every time.
There are other solutions to that, like bug 271211 (sanitize) or bug 190298 (rename attachment.)
(In reply to comment #94)
> Comment #19 noted, but subjects with
> unfortunate endings only happen sometimes.  .eml now happens every time.
> There are other solutions to that, like bug 271211 (sanitize) or bug 190298
> (rename attachment.)
> 
Oh *rats*, that should have been Chris Thomas's comment #40, about subjects ending in .com and such.

Turns out, BTW, that you can't forward as attachment to my family's graysmail.com.  .eml gets rejected.  :(  I'm going to have to try to find where this is actually coming from and how hard it is to override.  :/
I've posted i386 and x86_64 fc7 RPM's of:

thunderbird-2.0.0.5-3.fc7.*.rpm

on ftp://ftp.redfish-solutions.com/pub/ .  These have the name removed from the attachment, as described in comment #73 by John.

If anyone wants to give them a try, including forwarding me a message, please do so and report on their success or if they've encountered issues with MTA's that don't like unnamed attachments.
(In reply to comment #96)
> I've posted i386 and x86_64 fc7 RPM's of:
> 
> thunderbird-2.0.0.5-3.fc7.*.rpm
> 
> on ftp://ftp.redfish-solutions.com/pub/ .  These have the name removed from the
> attachment, as described in comment #73 by John.
> 
> If anyone wants to give them a try, including forwarding me a message, please
> do so and report on their success or if they've encountered issues with MTA's
> that don't like unnamed attachments.

Alas, this wasn't sufficient.  After a test on a borrowed FC7 machine (I run this on my servers, but they're all "headless"), the result was:

Content-Type: message/rfc822;
 name="Attached Message"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Attached Message"

I'll dig a little deeper and see if it's possible to have unnamed attachments.


Comment 98

12 years ago
I am a user of TB mature both in experience and years. I am not a programming whiz. 
However, I have just spent a couple of hours reading this bug discussion and, with your permission, I would like to make one or two suggestions.
This problem is now a very real one since many forwarded emails are not getting through and, I suspect, frequently without either sender or recipient being aware of the fact.

Firstly, could one or two of the many protagonists take some time out to summarise   the agreed status of the problem today, its historical progression over 4 years, and the pro's and cons. of the many arguments above. Much sensible comment is hear but my reading indicates that some of this is lost in egos. 
Secondly, out of such an effort must inevitably arise a decent plan that will get the whole thing back on track so that:
TB can thrive and interoperate with all competitors;
people can forward their emails to others who may be interested in their content;
no information gets lost in the process;
sensible anti-virus strategies can be implemented that provide all of us with the necessary security in a reasonably automatic manner.

I write this in good faith to possibly assist an excellent enterprise to make the world a better place in trying times.
Thank you. 
Product: Core → MailNews Core
Assignee

Updated

11 years ago
Target Milestone: --- → mozilla1.9alpha1
You need to log in before you can comment on or make changes to this bug.