Closed Bug 28211 Opened 22 years ago Closed 4 years ago

On Send, fail to copy to Sent folder should let user retry, or offer "plan B"


(MailNews Core :: Composition, defect)

Not set


(Not tracked)

Thunderbird 56.0


(Reporter: sol, Unassigned)


(Blocks 1 open bug)


(Keywords: dataloss, helpwanted, Whiteboard: [needed for send in background][has partial patches])


(1 file)

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 

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.
Target Milestone: M15
OS: Windows NT → All
QA Contact: lchiang → esther
Hardware: PC → All
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.
Keywords: mail3
QA Contact: esther → sheelar
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?
Keywords: nsbeta1
Whiteboard: [nsbeta1+]
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.
Assignee: ducarroz → varada
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?
Target Milestone: mozilla0.9 → mozilla0.9.1
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 
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
Blocks: 104166
Keywords: mail3nsbeta1+
Whiteboard: [nsbeta1+]
Priority: P2 → P3
*** 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. ***
Blocks: 122274
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.
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

   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.
Keywords: dataloss
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
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 <> and
<>, 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
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

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".  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"
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?
Product: MailNews → Core
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
Blocks: 215044
Putting this on the TB3 blocking radar as I need to fix it for bug 440794.
Assignee: nobody → bugzilla
Blocks: 440794
Flags: blocking-thunderbird3+
Whiteboard: [needed for send in background]
Target Milestone: mozilla1.2alpha → Thunderbird 3.0b3
Attached patch WIPSplinter Review
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
No longer blocks: 440794
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
Duplicate of this bug: 519910
(In reply to 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
Keywords: helpwanted
Priority: P3 → --
Whiteboard: [needed for send in background] → [needed for send in background][has partial patches]
Target Milestone: Future → ---
Duplicate of this bug: 776354
Duplicate of this bug: 1224457
15 years of data losses... :-(
Duplicate of this bug: 1237051
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...
Duplicate of this bug: 858983
Duplicate of this bug: 1311023
Bug 1298000 is a somewhat similar issue with saving to drafts.
Duplicate of this bug: 1298000
Duplicate of this bug: 1263863
Duplicate of this bug: 1351672
Duplicate of this bug: 1285120
Duplicate of this bug: 1013836
Duplicate of this bug: 1126069
Duplicate of this bug: 786868
See Also: → 1343858
Duplicate of this bug: 1357713
Blocks: 817392
Duplicate of this bug: 1366591
See Also: → 1366591

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.
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 56.0
No longer blocks: 354064
Duplicate of this bug: 354064
No longer blocks: 215044
Duplicate of this bug: 215044
No longer blocks: 726377
Duplicate of this bug: 726377
No longer blocks: 1298000
No longer blocks: 817392
Duplicate of this bug: 817392
See Also: 1343858
Duplicate of this bug: 1343858
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:
I'd rather stick to the ESR version (stable branch), for now, if possible. But thanks for the info.

This issue is NOT a duplicate of

Because this ticket is about 'copy to sent folder' rather than a complete loss of a mail after a fail to send it

Can someone reopen that other ticket?

And why are these tickets not resolved (original report of this one is 20 years ago?!) Is Thunderbird not supported anymore ? should I look for another email client (any suggestions?)

Hmm, "complete loss of a mail" maybe bug 1077418.

You need to log in before you can comment on or make changes to this bug.