When sending a message, if the message is successfully sent, but copying to the Sent folder fails, you receive the following message: "Your Send operation was successful, but copying the message to your Sent folder failed. Would you like to return to the compose window?" (Note: This is the 4.x behavior, and I've never understood it.) I don't want to go back to the compose window, I want an opportunity to save the message to a folder (local or server) *without* having to resend the message, since I don't want the recipient to get stuck with multiple copies of the message. I would prefer the dialog say "Your message was successfully sent, but copying the message to your Sent folder failed. Would you like to (a) try copying the message to your Sent folder again (b) try copying the message to another folder, or (c) forget the whole thing. Build ID 2000-02-14-16 Steps to reproduce: 1. Launch Mail 2. Compose a new message (New Msg) 3. Send the new message ("Send") *If* the message is successfully sent, but copying to the Sent folder fails, you will see the dialog described above.
Status: NEW → ASSIGNED
Target Milestone: M15
Mass moving to M16 to get these off the M15 radar. Please let me know if this is really an M15 stopper.
Target Milestone: M15 → M16
Not beta2 stopper. Marking M18.
Target Milestone: M16 → M18
Would be nice to get this (I was the reporter :), but I think we have more important things to work on for Seamonkey, so I moved to future milestone.
Target Milestone: M18 → Future
Adding mail3 keyword.
For what it's worth, I believe this error has something to do with whether or not the SENT folder summary file has been successfully generated. If I get this error, then all subsequent sends ALSO fail to copy to sent folder. When I click to VIEW the SENT folder, I can tell that not all messages are being shown. I can then shutdown Mozilla, restart, click on SENT and let mozilla rebuild the summary file. After this, sends successfully copy to SENT folder. I would recommend that on a failed-copy, have mozilla rebuild the sent folder summary from scratch and then try again.
marking nsbeta1+ and moving to mozilla0.8. If we don't have a sent folder, can we let the user try again in local folders?
Target Milestone: Future → mozilla0.8
Bug 41833 is somewhat related and could be merged with this bug. This dialog is confusing and isn't very helpful to users. Some ideas for fixes (some wording suggestions taken from mpt in bug 41833): 1. Why is the Send operation sometimes successful, yet copying to the Sent folder unsucessful? Can we fix this problem and prevent the error from occuring? Can we retry without bothering the user? 2. "Your message has been sent, but it could not be saved in your <SentFolder> folder because an error occurred. A copy will be placed in your Local Sent folder instead." 3. "Your message has been sent, but it could not be saved in your <SentFolder> folder because an error occurred. Choose Retry to try saving the message again, or Cancel to return to the message."
If I eject the disk on which my mail files are kept, or if some accident totally horks my mail files, you'd jolly well better give me the opportunity to leave the composition window open after sending -- so that I can print the message out, or save it as a file, or copy its contents to paste into a separate document, or whatever.
moving to mozilla0.9
Target Milestone: mozilla0.8 → mozilla0.9
If you are looking for a reproduceable case, send yourself a bugzilla bug report. Then reply to the message and send it to yourself. You will get in this case. I have a Sent Folder in my Local Folders. I talked to Varada and it sounds like if we fail the first time we're going to fail every time so putting this dialog up is only going to give the user false hope. Perhaps with this test case we can fix the main reason why copying to sent fails.
Re-assigning to Self.
re-assigning to self - really!!
I've been using mozmail for months, and this is one of the most frustrating bugs. Where's the bug to fix that fact that the failed copy shouldn't happen in the first place? This is intermittent for me - most of the time it works. Why does it only fail some of the time?
I've been told that once it fails retrying isn't going to do any good. We've gotten rid of most of the cases where we know this occurs. Right now when it fails to send it gives you the option to go back to the compose window. From there you can save it as a draft. Is this acceptable (I guess not because this bug was filed but it seems reasonable to me)? Or do we feel the need to explicitly ask the user if they want to save it to the drafts folder (or possibly some other folder)? What are some examples of things we could without asking the user to retry the current sent folder or if the current sent folder is the local folders? We need to get the wording done soon if we want to do this.
Since most users have trouble summoning the energy to read them, alerts should be kept as simple as possible. So if the message composition window itself easily lets you save the message in the Drafts folder, or save it as a file, or print it, or whatever, the failed-copy alert probably shouldn't offer any of these options. I think the alert should have only one button, `OK', which should take you back to the composition window. From there, it is your decision whether you close the window, or do anything else to keep a permanent record of your message. If necessary, the alert could contain a sentence (in the small system font) explaining that you can do any of these things before closing the composition window.
I agree with mpt that a simple alert that lets you go back to the compose window is acceptable. I think the current alert isn't perfect but is close to this. I'd like to either lower the priority of this bug or mark it won't fix based on the current subject.
moving to 0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
moving to 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
moving to 0.9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Mail news triage meeting --> .9.5
Priority: P3 → P2
Target Milestone: mozilla0.9.4 → mozilla0.9.5
moving to 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
moving to 1.0
Target Milestone: mozilla0.9.6 → mozilla1.0
*** Bug 119152 has been marked as a duplicate of this bug. ***
*** Bug 119150 has been marked as a duplicate of this bug. ***
*** Bug 108752 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Keywords: nsbeta1+ → nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2
*** Bug 117862 has been marked as a duplicate of this bug. ***
I've just tried the reproducible test case in comment 11, and it doesn't work (by which I mean it doesn't reproduce the problem). CVS build 2002-05-04-10 WinXP. One case where I can reproduce this behaviour reliably (see the caveat below) is if you send a mail and click Cancel in the progress box. The message then pops up (which appears to be another bug in that the message was still sent - I guess there comes a "point of no return" after which a Send can't be cancelled. Maybe the Cancel button should be disabled at that point?). Returning to the compose window and re-sending will save it to the Sent folder (although it will, of course, have now sent the message twice). CAVEAT: To make this work you have to Cancel the send when it is too late (so the message is still actually sent), which of course is a bit hit and miss.
Change qa contact
QA Contact: sheelar → meehansqa
With a password protected imap folder, things are worse. steps: 1. configure imap and smtp to require passwords. use imap for your sent folder. 2. make sure mozilla doesn't know your passwords 3. compose a message to yourself 4. click send 5. [at password prompt] click cancel 6. do 4 7. [at password prompt] enter password and click ok 8. do 5 9. do 3,4,7 The problem is visible at step 9 where you have to do step 3 again. The reason you have to do it again is that mozilla eats your message (it's sent, you'll get it once for each time you reach step 7). Note that this is causing me serious problems because it happens when i use my second imap account which while touching the same imap/smtp server with the same password is normally unused and therefor doesn't know /some/ of my passwords. The result is that when i send personal mail I frequently at the password prompt think: oh, whoops, i wanted to add something more to the message. if i click cancel, i should be able to go back to the message and add to it. This is wrong about half the time, I can't tell from the password prompt dialog if it's looking for SMTP or IMAP, it's usually looking for IMAP. So instead of stopping the message from being sent, I stop the message from being saved and now there's only one copy of the message, and I don't have it. To make my life easier, we should change the order we do things: 1. make sure we can write to the sent folder 2. talk to the smtp server, send the message 3. write to the sent folder. Perhaps we should actually write the message in step one (marked as deleted) and then undelete it in step 3. I'd expect this would work for imap: and file:, I don't know how well it'd work for other implementations.
*** Bug 169015 has been marked as a duplicate of this bug. ***
I would imagine there are many possible scenarious that would trigger this, but here is one of them: 0) Change your connectivity/preferences/etc so that SMTP is available, but the "Sent" folder is not. For example: a) Disconnect machine from the network with SMTP set to localhost and Sent pointing to IMAP server. b) Point Sent to IMAP server, block copnnections to that server. c) Change "Sent preferences. 1) Compose a message in off-line mode, for "Send later". 2) Go to online telling Mozilla to send unsent messages. 3) Observe that (as expected) SMTP goes trough, but saving to Sent fails. Expected: Mozilla falls back to "Plan B". There are many alternative "Plan B"s, for example: I) Save to Sent on Local Folders and pop up a warning telling user what happened. II) If the Sent folder is and Offline folder, save the message in "Offline" mode (so that it gets transferred to the server once it becomes available). III) Pop up a warning telling user what happened and give user a choice of: a) Retry b) Save to Local Folders -> Sent c) Pick another folder d) Ignore the error and continue. Actual: I get a warning telling that message was Sent, but not saved advising me to "try again". Of course, there is no chance to "try again" since the message is now completely gone (unless I had it CC/BCC to myself). This bug is not limited to offline, although its consequences are worse (dataloss) in the "Send Later" scenario. In "Send now", I get the warning that message was sent, but not saved. After that the "Compose" window is still around, but with most of the controls disabled. However it's not a complete dataloss - I still get a chance to save it as Draft (and then move it from Draft to Sent). P.S. The above is copied from my report in dup bug 169015. There I've set Severity: major for the dataloss reasons.
Summary: On Send, fail to copy to Sent folder should let user retry, not return to compose window → On Send, fail to copy to Sent folder should let user retry, or offer "plan B"
taking all of varada's bugs.
Assignee: varada → sspitzer
Status: ASSIGNED → NEW
This bug used to occur intermetently with Mozilla 1.2.1, but with Mozilla 1.3a, it occurs for every message send after the 2nd or 3rd send. Sometimes I get the dialog box that other people have mentionned ("could not copy to sent folder"); some other times I simply see the progress bar indicating "copy to sent folder in progress", but there is never any progress, even after several minutes. Everything is back to normal after a restart, but obviously 1.3a is unusable as far as I am concerned, since the problem occurs now so frequently.
I forgot to mention that when this bug occurs, messages can no longer be deleted or moved to another folder, whatever the source or target folders.
Re: comment #34, comment #35. Are you using IMAP? If so, then you are probably seing bug 182808. "Plan B" could have helped, but in your case the real issue is that "plan A" should have worked in the first place.
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
This is still happening on 1.5a (2003060704). Once it happens, I have to change the sent mail folder in order to send mail. Why is it still getting trashed? I am using IMAP, but putting sent mail into a local folder.
Am using Thunderbird 2003-07-23-trunk on Windows XP with an email service that uses Cyrus. I have the following folders: - Inbox - Sent Items - Junk - Saved + - Acads + - BugZilla + - Jobs - Drafts When I choose to save my Sent Mail in any of the top level folders (Inbox, Sent Items, Junk, Saved, Drafts) Thunderbird saves mail without any qualms. But when I choose to save my Sent Mail in any of the sub-folders of Saved (Acads, BugZilla, Jobs), it gives me a message "The current command did not succeed. The mail server responded: Mailbox does not exist." Here are the relevant lines from my prefs.js: user_pref("mail.identity.id1.useremail", "**edited email address**"); user_pref("mail.identity.id1.fcc", true); user_pref("mail.identity.id1.fcc_folder", "imap://**edited firstname.lastname@example.org/Saved/Acads"); user_pref("mail.identity.id1.fcc_folder_picker_mode", "1"); I mentioned this here coz I wasn't sure whether it is un/ related to the current discussion. As an aside, couldn't something like Aleksey Nogin's Comment 32 be implemented when copying to the Sent Mail folder fails? From Comment 16 above I gather the current intention is that the user should press OK, and then choose his options from the composition window. But I do not think this is very intuitive; atleast after using Thunderbird for 2-3 months, it never struck me that I could choose my options from the composition window (most often, I would simply press cancel). If nothing else, maybe the error message should be modified to indicate that the user can choose his options from the composition window.
adding myself to cc
Tried sending myself a mail, to see what options I have from the composition window, if copying to the Sent Mail folder fails. Is the following the correct way to go? 1. Go to Options > Send a Copy to > and choose the folder you want to save the mail to; and 2. Go to File > Save to save the mail to the folder chosen in Step 1. (By the way, I tried following the same steps to try and save the mail in one of the problem folders (see Comment 39) -- still does not work).
Oh geez, I'm just a usr and may screw this up, please forgive....I have the same bug, tried setting prefs in mail folder prefs to send copy of sent mail to sent folder. I am using Mozilla 1.6, just DL'd recently. My prefs selections are not saved and my sent mail is not copied to "sent" folder. My OS is WinME, recently upgraded from Win95. Did not have this problem with Mozilla 1.5b and Win95. I have changed machines from a Compaq to a Sony Vaio, ghosted the Win95/Compaq and upgraded to Sony/Win98, then upgraded to WinME and then upgraded Mozilla to 1.6. Actually all that was done by a techy friend of mine.
(In reply to comment #42) My problem is sorta not the original bug description, but is the same as comment #42. I've been using ns/moz mail for a hundred years. Since March 24 this year, i magically stopped saving my mail in the sent folder. "Oh ****". I noticed in the "Mail & Newsgroups Account Settings" / "Copies & Folders" dialog, that the check boxes are clear. The dropdowns for all 6 entries are "dik on sean.buckosoft.com". No matter what i change *any* of the settings to in this box (checks, radios, dropdowns), when i press OK and come back to the dialog, the settings are unchanged and show the all cleared settings mentioned above. I have been running 2 pop accounts (8 year old, spam laden dick@; 1 year old dik@). Perhaps this is near when i switched servers from sarah.buckosoft to sean.buckosoft which did auto-rename the parent folder from "dick on sarah.buckosoft" to "dick on sean.buckosoft" or Perhaps around the time i broke this, i added a third account: IMAP dickb@. I was using Moz 1.5 since Dec'03 and now 1.7RC1 since 2 days ago.
Since I upgraded to a 1.7 RC or messed around with the profile data, sent messages are not saved in the Sent folder anymore - without warning - so I lost the track of my sent e-mails of June. Also, I get "saving to .... has failed" error message when trying to manually save in drafts or templates. I think all this has to do with corrupted or incompatible profile data. I use Mozilla since 0.9 and have installed many versions, even some betas, and already had to fix things manually, so my Mozilla profile is severely scarred. I think I will have to migrate to a new profile.
Same problem as #42 and #43, maybe this should be filed as a separate bug? Is there anything in the profile that can be done to fix this? (using 1.7.3) Click in the Copy sent mails to ... radio button has no effect, when you return to this screen everything is blank again.
(In reply to comment #45) I had the same problem as the last few comments, on two computers. One, my work computer, suffered a hard drive crash, and I had to reinstall everything (Win2k system) from scratch. My Mozilla user directory (and mail folders/prefs) were located on a network drive, so all I had to do was point Mozilla there (1.6a for my work computer) after installing, and everything was good to go... except that I couldn't save sent messages, or save to the drafts folder from the compose window (I could save as text files elsewhere, however). Never received an error message for [not] saving to sent folder, but I did when I tried the drafts folder (see #44). Same problem on my home computer: got a new computer, went from Mozilla 1.7.1 on WinME (Norton as AV) to same version (1.7.1) on WinXP (PC-Cillin as AV). Later upgraded to 1.7.3. Couldn't save sent messages, no error message popped up. When I attempted to change the "place a copy in..." settings (edit->mail&news...->copies&folders...) it would accept settings without complaint, then when I went back to double-check, the settings were blanked out. I did have some user@server@localhost mis-directs in my prefs.js file as other users have suggested here, as well as in other bugs (#221386). Editing the file manually did not fix the problem. I tried what comment #6 suggested, but to no avail. I did know that if I manually moved a message from my inbox to my sent folder, I could properly read it there later, I just couldn't get Mozilla to automatically save there. I did manage a work-around. I simply backed up my user/xxx.slt/mail directory, removed the account from the list of accounts, added a new account with the same name, settings, etc. Everything is working again, and it turns out I didn’t need to back up the files, they were kept in the same directory (though I would recommend backing them up anyway). I had to point the local directory setting back to what it was and restart Mozilla (it returned to windows/application data/... rather than XPuser/application data/... that it was before), but there were no other complications. The work-around worked on both computers. FWIW, I have 3 accounts, 2 POP and 1 IMAP. I never had a problem with the IMAP account, but did with both POP accounts. Only one of the POP accounts had a problem (that I could spot) in the prefs.js file. Has anyone else tried a work-around like this?
Thunderbird: version 1.0 (20041206) * 3 IMAP accounts * SMTP requires authentication * Using local Sent folder Been using this software for almost a month before this bug cropped up. Now all of a sudden it is happening constantly. A shut down and restart of the application alleviates the problem temporarily. Also a save to Drafts and copy to sent does work. But what a pain in the a**.
i started using xpunge extension and this is alleviating the problem to some extent. I still get the hang on copy to sent folder occasionally but less frequently after using the extension
I've run into this as well, and also think it needs the option to save it elsewhere. In my case, there's also a more fundamental problem: in network monitoring, I found that it check subscribed folders, finds "INBOX.Sent", then tries to create "Sent", which is invalid on this server (cyrus) and fails. There is never any indication that the folder creation failed, tbird just hangs until it times out. That is completely broken error handling. Further, there's no way to change what the "Sent" folder is to fix it (with the possible exception of manually editing the config file).
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
In thunderbird 1.5 I had problem with copy to send folder in IMAP courier. But it was very rare. But in TB 2 it is very often, sometimes when I close and open TB2 again it helps and I can send emails without problem (and filters works too). All our customers have the same problem. I guess somebody during writing TB2 make it worse then TB1.5. I started install TB1.5 again because this bug is really disturbing. Generally I think that TB2 has a lot of bugs which didn't exists earlier or were not so annoying.
Filter on "Nobody_NScomTLD_20080620"
QA Contact: meehansqa → composition
Product: Core → MailNews Core
Putting this on the TB3 blocking radar as I need to fix it for bug 440794.
Assignee: nobody → bugzilla
Whiteboard: [needed for send in background]
Target Milestone: mozilla1.2alpha → Thunderbird 3.0b3
Created attachment 381502 [details] [diff] [review] WIP Initial work, this replaces the current "There was an error copying the message to the Sent folder. Retry?" with a single automated retry. Reasons: - If we're copying to local folders then if there has been a failure and it isn't fixed after the first retry, the user is probably not going to be able to fix it without doing something else. - If we're copying to IMAP, again one retry is probably enough - David (B) tells me that IMAP should retry internally anyway. Thoughts for the next part: - If the retry fails, copy the message to the outbox and set special flags. Next time we process messages in the outbox check the flags and only do copy to sent folder. There will probably need to be some UI in the message header for this in the sent folder. - If we can't send to the outbox, see if we can leave it as a .eml file and notify the user. This is really worst-case, but better than nothing.
(In reply to comment #54) > - If we can't send to the outbox, see if we can leave it as a .eml file and > notify the user. This is really worst-case, but better than nothing. Can't we already let the user do this via "Save as File..."?
(In reply to comment #55) > (In reply to comment #54) > > - If we can't send to the outbox, see if we can leave it as a .eml file and > > notify the user. This is really worst-case, but better than nothing. > Can't we already let the user do this via "Save as File..."? Not if the user has sent later (e.g. offline mode) as per bug 215044, or if we're sending in background.
Can't they just move the message themselves in that case?
(In reply to comment #57) > Can't they just move the message themselves in that case? Move the message from where? If you mean the outbox, that is currently not possible. When we send a message it gets deleted from the outbox as soon as the send is complete - because it is creating a temp file (with reduced set of headers) for the actual send. It is then processing that temp file into a copy to the sent folder - so we have to at least get the message back into the outbox. I'm looking for a solution that will work in all cases and hopefully be as behind the scenes as possible (whilst also telling the user what's happening).
What do you mean by send is complete? I don't call it complete if we failed to copy the message to the Sent folder... If the code really drops the message in this case (send later + copy fails) then I think that needs some sort of fix (which could include one of your existing suggestions).
Target Milestone: Thunderbird 3.0b3 → Thunderbird 3.0b4
Due to the amount of work left for completing send in background, we've decided that it isn't going to make Thunderbird 3. Therefore this bug isn't needed for TB 3 to complete that work, so taking off the blocking list.
Flags: blocking-thunderbird3+ → blocking-thunderbird3-
Target Milestone: Thunderbird 3.0b4 → Future
(In reply to email@example.com from comment #59) > What do you mean by send is complete? I don't call it complete if we failed > to copy the message to the Sent folder... The current process is: - From the message in the outbox, formulate a temp file of the message to be sent - Send the temp file over SMTP - Once SMTP sending is complete, remove message from the outbox - Copy the temp file to the appropriate sent message folder > If the code really drops the > message in this case (send later + copy fails) then I think that needs some > sort of fix (which could include one of your existing suggestions). Yes, it is the last step that can fail, and if it does, then you've hit dataloss. Hence the reason for the suggestions in comment 54. Unfortunately, I'm not actively working on this at the moment, so unassigning myself. I will be happy to give move help to anyone who wants to have a go at fixing this.
Assignee: mbanner → nobody
Priority: P3 → --
Whiteboard: [needed for send in background] → [needed for send in background][has partial patches]
Target Milestone: Future → ---
15 years of data losses... :-(
I'd like to add, that the actual underlying error must be available too: . out of disk-space locally? . some other local problem? . remote unreachable? . remote refused our credentials? . some other remote error? . .... Simply saying "there was a problem" is so "microsoftish", it is disgusting...
Bug 1298000 is a somewhat similar issue with saving to drafts.
https://hg.mozilla.org/comm-central/rev/a6a1279292d055c75b9554b01dab78b1cd9f27de We fixed this bug here in bug 1366591 where a "Plan B" was implemented. Now, if saving a sent message fails, the user can save the sent message to a local folder and it doesn't get lost any more. Due to the string changes sadly this cannot be backported to the current TB 52 and will have to wait for a release in TB 59 in March 2018.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 56.0
Part of the problem was, even when the user asked to "try again", the attempt to save would keep fail even if the underlying reason for the failure was eliminated -- the entire TB had to be restarted for the saving into a remote folder to start working again. The actual error was never communicated to the end-user either (although the admin could deduce something from IMAP-server's logs). Have _these_ two problems been solved too?
I don't think so. Please file a new bug for the remaining problems. "Plan B" has been implemented, so this bug here is resolved.
> Please file a new bug for the remaining problems. I did -- two years ago. My bug #1237051 was deemed a duplicate of this one (see Comment #66) and it did enumerate these additional problems. If they haven't been solved, I can reopen it...
Just for the record, FF ESR 52.7 still suffers from this issue. Will it be resolved with release of ESR 60.0 in May?
Yes, this was fixed in TB 56. Try the latest beta: https://www.mozilla.org/en-US/thunderbird/channel/
I'd rather stick to the ESR version (stable branch), for now, if possible. But thanks for the info.
You need to log in before you can comment on or make changes to this bug.