Closed
Bug 490745
Opened 16 years ago
Closed 2 years ago
messages moved to drafts lose headers
Categories
(Thunderbird :: Folder and Message Lists, defect)
Thunderbird
Folder and Message Lists
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: niteling, Unassigned)
References
(Blocks 1 open bug)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: version 2.0.0.21 (20090302)
If a non-draft message (in particular a received message from the Inbox) is moved into the drafts folder, it becomes an editable draft. If that message is then opened and saved, most of its original headers (including the original From: header) are truncated and replaced with Thunderbird's standard draft header set.
This is a serious problem, because there is then no way to recover the original sender's address. The From: header is changed to your own name & address the first time you save the draft.
I think the fix should be to make messages that have been outside of the drafts folder at any time read-only. It should be possible to make an editable *copy* of a received message by copying it to drafts, but the original message should never have its headers removed in this way.
Reproducible: Always
Steps to Reproduce:
1. Copy a message from your inbox to your drafts folder.
2. Open the message in the drafts folder.
3. Click save draft.
Actual Results:
The message's original From: header is irrevocably replaced with your own name and e-mail address.
Expected Results:
The original From: header should be preserved. Possibly a warning should be displayed before it is overwritten, for instance, "You are about to change an INCOMING message to an OUTGOING draft. The original sender's name and address will be lost. You probably did not mean to do this!"
This bug is related to these other bugs:
Bug 426373 - Using same folder for Drafts and Sent cause sent messages to be treated like draft messages
Bug 483395 - Double-clicking a mail msg saved in drafts should open it in edit mode. (In my opinion, it most definitely should NOT, as that causes the header truncation described in this bug...)
Comment 1•16 years ago
|
||
"drafts folder for Tb" is folder which is pointed by "Keep message drafts in:" of Copies&Folders setting. (In addition to it, if local mail folder, folder named "Drafts" and subfolders of it seems to be treated as "draft folder for Tb", although it is not used for draft saving if no identity points it as "drafts folder".)
This is same for IMAP folder, and "mail has \Draft flag or not" doesn't have relation to "Edit as Draft mail is permitted or not", although Tb stores \Draft flag upon save mail to "drafts folder for Tb" as draft mail. And if a mail in "drafts folder for Tb" is edited as draft mail and saved, old version is deleted from "drafts folder for Tb".
I think it's inherited design from initial mail application with Unix Mbox on Unix, based on initial POP+SMTP system. It's inherited by Netscape, and inherited by Tb.
Above can be called "folder(Unox Mbox, when TB) based system". In contrast to it, Gmail can be called "mail(+conversation) based system"(draft mail is labeled "Drafts" and displayed in "Drafts" *FOLDER* of Gmail's Web Interface).
Comment 2•16 years ago
|
||
If "Edit As New of mail in drafts-folder-for-Tb" case, see Bug 321355.
See also Bug 360390. It's request of "Compose window open" when double-click of a mail with \Draft flag held in non drafts-folder-for-Tb folder.
Comment 3•16 years ago
|
||
(In reply to comment #0)
> I think the fix should be to make messages that have been outside of the drafts
> folder at any time read-only.
AFAIR, "Read only attribute of mail and/or mail folder" is already requested. Search bugzilla.mozilla.org again, please(via "Advanced Search").
By the way, some people(not so small number) request "edit capability of received mail"(e.g. adding comment in Summary: for house keeping).
It's absolutely opositte request to yours.
> It should be possible to make an editable *copy* of a received message by copying it to drafts,
You can do it always very easily by yourself - "copy" instead of "move".
Why you don't do "copy to Drafts" folder?
Re #3:
I filed this one separately specifically to address the issue of data loss.
The background story for this bug report is that I have a user who moves messages to her Drafts folder as a way of marking them "to deal with later". She started complaining that "when I reply to a message, it just comes right back to me! And then, the original From: address magically turns into mine right before my eyes and I can't get the original one back!"
It took me over an hour to figure out what the hell was going on, because I looked at all of the headers on her problem e-mails and they looked like ordinary drafts, written locally. For a while I was questioning her sanity, wondering if maybe she'd somehow written the drafts herself and forgotten before trying to reply to them, because I couldn't think of any explanation for the total lack of server Received: headers.
If this is an indirect result of someone requesting the ability to edit messages, then that functionality was very badly implemented, because thunderbird is deleting headers. It's not just Received: -- it's overwriting or removing From:, Message-ID:, Return-Path:, Original-To:, CC:, and Date: to name a few.
I've of course told this particular user that the solution is "don't do that," but since this bug causes data loss I figured it should still be dealt with, despite that its cause is a very unlikely behaviour.
Comment 5•16 years ago
|
||
(In reply to comment #4)
Question just because of my curiosity.
Do you always complaint to MS about "MS Windows doesn't work as you expect" when you did "DEL C:\*.* /S" or "FORMAT C:"?|
re #5:
I would indeed complain to Microsoft if the command
move myfile c:\drafts\
modified myfile in any way, yes :P
This bug isn't a case of doing something that most skilled users would recognize as dangerous and being surprised when something dangerous does happen. I don't know about you, but I sure wouldn't expect headers to disappear when I edit an e-mail, even if it is in the drafts folder. I understand why Thunderbird is overwriting From:, but there is absolutely NO excuse for deleting all of the other headers I mentioned.
Honestly, I'm not going to shed any tears if this bug isn't fixed. There's a good chance my user is one-in-a-million and this will never show up again. But, robustness in software is good, and I think Thunderbird should be robust against even rare aberrations like this.
Comment 7•16 years ago
|
||
(In reply to comment #6)
> something dangerous does happen.
> n(snip)g@gmail.com
Do you use Gmail IMAP? Are you talking about phenomenon when you edited draft mail in "Drafts" FOLDER of Gmail at Gmail Web Interface(=="[Gmail]/Drafts" folder via Gmail IMAP) using Thunderbird.
Comment 8•16 years ago
|
||
(In reply to comment #6)
> move myfile c:\drafts\
> modified myfile in any way, yes :P
(For "Original" in Drafts folder)
Your case is similar to(if "Edit of mail in Drafts"):
move myfile c:\drafts\
notepad.exe c:\drafts\myfile, change data, "Save"
=> modified myfile
If you want to keep original c:\drafts\myfile, you have to do "Save As" with different file name.
If "Edit As New" of mail in Drafts folder, as I wrote before, Tb has Bug 321355, then Tb works like "Save" or "Save As with same file name" of notepad.exe.
Which case are you talking about?
Comment 9•16 years ago
|
||
> Actual Results:
> The message's original From: header is irrevocably replaced with your own name and e-mail address.
> Expected Results:
> The original From: header should be preserved.
(For preset From: address of edited draft mail)
"Edit of mail in Drafts" is not equivalent to "Edit of text file by text editor" nor "Edit of mail source text data".
And "From:" address of draft mail is managed by "X-Identity-Key:" header in draft mail source.
(In contrast to it, preset From: in reply is based on X-Account-Key: header which is added to mail source data by Tb upon download from POP3 server.)
I don't know Tb's design of preset From: when no X-Identity-Key: header. I guess "main identity of owner account of Drafts folder" is used if other than pseudo account of "Local Folders"(probably "main identity of default account").
| Reporter | ||
Comment 10•16 years ago
|
||
re #7:
This isn't particular to gmail/IMAP; I've confirmed this bug for a POP3 setup as well as IMAP for any provider.
re #8:
If we really want to be pedantic and make the example of a text file in c:\drafts fit, it would be more like this:
- suppose myfile contains this data:
"Hello
World"
- move myfile c:\drafts\
- notepad.exe c:\drafts\myfile, DO NOT change data, "Save"
- myfile now contains
"Goodbye
World"
even though you DID NOT actually modify any data, and you certainly did not delete the word "hello" and replace it with "goodbye". That would be a bug in notepad, would it not?
This bug isn't really related to "Edit as new" as far as I know, since that command isn't in the steps needed to reproduce.
re #9:
> I don't know Tb's design of preset From: when no X-Identity-Key: header. I
> guess "main identity of owner account of Drafts folder" is used if other than
> pseudo account of "Local Folders"(probably "main identity of default account").
That's the problem. It does indeed set X-Identity-Key: to the default main identity. It then also does all of the header modification that I mentioned -- deletes the original From:, replaces it with the default identity, deletes all Received: headers, etc.
Updated•16 years ago
|
Component: General → Folder and Message Lists
QA Contact: general → folders-message-lists
Comment 11•16 years ago
|
||
does this also happen in version 3?
| Reporter | ||
Comment 12•16 years ago
|
||
(In reply to comment #11)
> does this also happen in version 3?
Yes.
There's also an interesting twist now (not sure if it was there before) -- say I have two accounts, Account1 and Account2. Account1 is the default.
If I copy a message from Account2/Inbox into Account2/Drafts, open it there and hit "save", it disappears from that folder and ends up in Account1/Drafts instead, with Account1 as the From: identity. This might be related to the new "smart folders" feature (which I've disabled).
Comment 13•16 years ago
|
||
(In reply to comment #12)
> If I copy a message from Account2/Inbox into Account2/Drafts, open it there and
> hit "save", it disappears from that folder and ends up in Account1/Drafts
> instead, with Account1 as the From: identity.
It works as currently designed. As I wrote in comment #1, "folder to save draft mail" is determined by identity setting, and identity used is identity which is for mail-addr used as From:. And, if the copied mail doesn't have x-identity-key: header which is used for draft mail, Tb probably sets mail-addr for main identity of default account as pre-set From: upon "Edit Draft".
If you want to save in Account2/Drafts, change From: to mail-address for an identity associated to Account2.
Comment 14•16 years ago
|
||
wada, invalid?
Comment 15•16 years ago
|
||
(In reply to comment #14)
> wada, invalid?
I can't say absolutely INVALID.
As initial IMAP is Inbox only system, draft mail in Inbox was distinguished by \Draft flag of a mail. MS Outlook(maybe in conjunction with MS Exchange) basically inherits this design. MS Outlook saves draft mail in Inbox of IMAP if user requests, and excludes mails of \Draft flag if ordinal mail display, and displays mails of \Draft flag only if draft mail display. So, if the Inbox is viewed by Tb, draft mail saved in Inbox by Outlook is displayed as ordinal mail in Inbox. It's already reported phenomenon to other bug.
For local mail folder, Tb doesn't add \Draft flag like property to a mail. Tb simply considers mail in "folder to save draft" as draft mail.
Currently, Tb applies this rule to IMAP folder too, because current IMAP is already not-Inbox-only system. i.e. Tb stores \Draft flag to a draft mail, but Tb doesn't care for \Draft flag upon draft folder display and upon any other folder display, and upon "Edit Draft" of mail in "folder to save draft mail" too.
So, I dont't think next request is absolutely INVALID.
If IMAP folder, deletion of old draft version by "Save" should be executed
for old draft version which has \Draft flag only.
I never think above is mandary nor many users want it, because, if user want to use an existent mail as draft of new mail composition, there already are several reasonable, easy-to-understand ways.
- "Edit As New" at ordinal folder
- Copy a mail to "Drafts" instead of "move", then "Edit Draft"
- Copy(or move if user wants) a mail to "Templates", and use the template.
However, next use case in comment #0 is better to be considered before final decision.
> Bug 426373 Using same folder for Drafts and Sent
As Tb is system based on "folder" instead of "flag of mail", I think setting of Sent=Inbox/Trash, Drafts=Sent/Inbox/Trash, Archives=Inbox/Sent/Drafts/Trash etc. is better to be prohibited at UI, in order to avoid unwanted problems on users, until "flag of \Draft" like property of a mail will be implemented (received/sent/draft/imported/deleted etc.) for any of IMAP folder and local mail folder(POP3) and "mixture of such mails in a mail folder" will be fully supported by Tb.
Comment 16•13 years ago
|
||
david your thoughts on comment 15?
Comment 17•13 years ago
|
||
perhaps bwinton
Updated•3 years ago
|
Severity: normal → S3
Comment 18•2 years ago
|
||
Hi Thomas, could you check if this is still a thing? Thanks!
Flags: needinfo?(bugzilla2007)
Comment 19•2 years ago
|
||
The message's original From: header is irrevocably replaced with your own name and e-mail address.
This does happen, but I don't know that it is a bad thing. Why would it keep a From address that doesn't exist in your Thunderbird.
Flags: needinfo?(bugzilla2007) → needinfo?(mkmelin+mozilla)
Comment 20•2 years ago
|
||
What was reported no longer happens. If you edit a draft such a message, the original From is kept + we show a notification about not finding the expected identity.
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(mkmelin+mozilla)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•