I still this pretty regularly - its usually noticeable when my connection is poor quality - e.g. in a cafe or tethered to my phone - messages transmit, but the save fails. Sometimes hitting Retry works, sometimes it doesnt.

Even worse - unlike "Send Later" there is no way that I can find to make it try and save later, so you have to keep hitting Retry to make the dialog go away, or lose your local copy.

kokop

Comment 44

•

5 years ago

Hello,

I'm surprised to see that this bug is still open after more than 10 years...

It keeps happening for me, from time to time, on two different IMAP servers now. It's VERY annoying when it happens : the only way to male it work is to alternatively click "Retry" - or better hit Alt+R, and select the Sent folder with the mouse to open it. You need to do this quickly because as soon as you click "Retry" the error window reappears immediatly - you only have a few 1/10th of seconds to open the Sent folder and click on a mail inside (try and retry until you're able to select a mail in the Sent folder with the mouse).
Once you're able to do this, and once TB has made an IMAP connection to the Sent folder manually, the error message eventually vanishes, and you can see the sent message in the list.

It also happens on the "Draft" folder sometimes. Less probematic, because after clicking "Retry" you have a few seconds to access the Draft Folder manually and make it work again.

I would be happy to help if I can, as this is driving me nuts...

Thanks !

BMO Automation

Updated

•

3 years ago

Severity: normal → S3

dxtr80

Comment 45

•

2 years ago

Hello,

Still appears on 102.10.0 (64 bit), Win11.
I will check with setting (Maximum number of connections to cache) and set 1 for 2 IMAP accounts.

If the problem appears again I will update.

BR,
Robert

Andrea Venturoli

Comment 46

•

2 years ago

Practically all of my users (in different offices in different companies) have always experienced this from time to time.
However, with v115 it got much worse: I'm receiving daily calls from people who can't save their sent mail because they got stuck in retry/abort loop. The more fortunate one get it saved in a local folder (and unless they move those messages to the IMAP account, they won't reach backups).
I understand this is most probably due to connection problems, but most of them are on the same LAN as the IMAP server.
Windows and Mac versions seem to be equally affected.
Unfortunately it's not easy to get a log because it doesn't deterministically happen and these computers are mostly remote for me.

Has anything changed radically in the IMAP code from 102 to 115?

Just wild guessing (and notice I don't know anything about TB's internals)...
I bet ThunderBird "lost" the IMAP connections to the server (either the server dropped it, somehow the client changed IP, the Internet line had a disconnection, a stateful firewall is in the middle... whatever reason):
_ does it try to keep them open with some keep-alive?
_ is so, if the user left it idle for a while, would then it detect such connections were dropped?
_ given there should be no problem in reopening them, it seems it does so when a user visits a folder, but not when it sends a mail.
Does the above make any sense?

Burki

Comment 47

•

2 years ago

Same problem here with 115.4.x! Here is some logging when trying to save a draft email:

...
[Parent 27910: IMAP]: I/IMAP 7fc65dd1e600:imap.secureserver.net:S-Drafts:SendData: iteu8LsV2yoTgEfMTnA7gDnisVszeW6QzQdbtRqlx4deAW
[Parent 27910: IMAP]: I/IMAP 7fc65dd1e600:imap.secureserver.net:S-Drafts:SendData: wjYyx/311nH6GGus
[Parent 27910: IMAP]: I/IMAP 7fc65dd1e600:imap.secureserver.net:S-Drafts:SendData: 
[Parent 27910: IMAP]: I/IMAP 7fc65dd1e600:imap.secureserver.net:S-Drafts:CreateNewLineFromSocket: clearing IMAP_CONNECTION_IS_OPEN - rv = 804b000e
[Parent 27910: IMAP]: I/IMAP 7fc65dd1e600:imap.secureserver.net:S-Drafts:TellThreadToDie: close socket connection
[Parent 27910: IMAP]: I/IMAP 7fc65dd1e600:imap.secureserver.net:S-Drafts:CreateNewLineFromSocket: (null)
[Parent 27910: IMAP]: D/IMAP URL failed with code 0x804b000e (imap://XXXXXX@imap.secureserver.net:993/appenddraftfromfile%3E/Drafts%3EUID%3E)
[Parent 27910: IMAP]: I/IMAP 7fc65dd1e600:imap.secureserver.net:S-Drafts:ProcessCurrentURL: aborting queued urls
[Parent 27910: IMAP]: I/IMAP 7fc65dd1e600:imap.secureserver.net:S-Drafts:ImapThreadMainLoop: idlePending set
[Parent 27910: IMAP]: I/IMAP 7fc67a505400:imap.secureserver.net:S-INBOX:SendData: DONE
[Parent 27910: IMAP]: I/IMAP 7fc67a505400:imap.secureserver.net:S-INBOX:SendData: 55 logout
[Parent 27910: IMAP]: I/IMAP 7fc678e17f00:imap.secureserver.net:A:SendData: 121 logout

Hopefully there will be some fix soon...

dxtr80

Comment 48

•

2 years ago

Hello,

This issue is blocking user activity randomly while sending email messages (let's say some of the messages are urgent).

Firstly reported on 4th Dec 2007 and this issue has not been resolved after so many years...

TB version 115.4.3 64bit.

Wayne Mery (:wsmwk)

Updated

•

2 years ago

Flags: needinfo?(vseerror)

Wayne Mery (:wsmwk)

Updated

•

2 years ago

Comment 49

•

2 years ago

Addendum to my comment above: I had complained to my mail provider (DomainFactory) that sending mails with large attachments very often failed. The Windows mail client seemed to work without any problems, but working with Thunderbird was a disaster. The mail provider escalated my complaint and after a few days I received a message that "a patch" had been applied to the mail server so that the problem should no longer occur with Thunderbird - which was indeed the case! Sending mail with Windows' own mail client still seems to be a bit faster, but working with my beloved Thunderbird is possible again. Thunderbird seems to be somehow more sensitive to certain mail server settings.

Wayne Mery (:wsmwk)

Comment 50

•

11 months ago

Andrea, is version 128 better?

Flags: needinfo?(vseerror) → needinfo?(ml)

gene smith

Comment 51

•

10 months ago

(In reply to dxtr80 from comment #48)

This issue is blocking user activity randomly while sending email messages (let's say some of the messages are urgent).

Thanks for your reply over at Bug 1508649 where you referenced this bug report.
Can you be more specific as to what the problem you are having is?

Firstly reported on 4th Dec 2007 and this issue has not been resolved after so many years...
TB version 115.4.3 64bit.

Lots of work has been done to improve the "save to Sent" functionality since then. If it fails for some reason (e.g., server timeout while appending the message to imap mailbox as shown in comment 47 above), you should be able to retry the append or save the message to Local Folders. So a message composed and then sent should never be lost.

Mitra Ardron

Comment 52

•

10 months ago

That still seems strange behavior .... if I am offline, I can "send Later" and it will resend when connected; and I can also append a message to a folder (such as Sent) and have the synchronization occur when I go back online.

Shouldn't failure to send be handled similarly, i.e. yes warn me, but it shouldn't explicitly saving to some specific Local Folder, the default should be to save locally to Sent and synchronize once connectivity is restore.

Generalizing this, I'm often working in low connectivity environments - cafe's, airplanes, developing countries, etc etc, TB does a fairly good job when online, or when offline, it has historically done a poor job of handling things when it thinks it is online but an operation fails (because in reality something in the internet is down)

gene smith

Comment 53

•

10 months ago

Shouldn't failure to send be handled similarly, i.e. yes warn me, but it shouldn't explicitly saving to some specific Local Folder, the default should be to save locally to Sent and synchronize once connectivity is restore.

I think you mean "failure to save to Sent folder". That sounds like a good idea. I'll look to see if something like that is possible.

Mitra Ardron

Comment 54

•

10 months ago

I meant both actually - failure to send should queue for later, and failure to save should append the the box and send later.

gene smith

Comment 55

•

10 months ago

Failure to send results in an error dialog suggesting you make sure your network is good and your SMTP server info is configured correctly. When you click OK on this dialog (the only option) it returns you to the "compose" window. Here you can try to send again or optionally queue to "Send Later". So your suggestion for "failure to send" is already implemented.
But maybe you are suggesting that "failure to send" results in automatic "send later" queuing and that the message be auto-sent when access to SMTP becomes good. This would require periodic retry of the send to SMTP server using the message stored in Local Folders/Outbox.

... failure to save should append the the box and send later.

Just to be, hopefully, clear, there is no attempt to "save to Sent folder" unless the send to SMTP server actually successfully occurs. So there is no reason to "send later" when the save fails.
Maybe you are suggesting that when save to sent there are now 4 options (one new option):

Retry save to Sent Mail folder and Sent Mail imap mailbox
Save to Local Folder
Save only to Sent Mail folder (new)
Don't save at all

So if "Save only to Send Mail folder" is selected, the message would have to be stored to the mbox/maildir offline store file and then imap appended to the Sent Mail mailbox when the imap server becomes accessible. If the user doesn't use offline store, it would have to be kept in a temp file. In either case, the server would have to be "polled" to know when it has become accessible again so the message can be imap appended.

and I can also append a message to a folder (such as Sent) and have the synchronization occur when I go back online.

That doesn't currently always work (especially when offline store is not in use) when the message is to be imap appended which uses a different URL, "appendmessagefromfile" vs. "copyonline" URL when you just copy/move an existing messages within an account. So probably not easy to make what you suggest actually work, but it may be possible (and require more research).

Mitra Ardron

Comment 56

•

10 months ago

Hi Gene - fair points.
A dialogue once makes sense for this kind of issue - however it comes up on every message sent - unless you tell TB its offline, in which case no messages get sent until you remember to manually tell it to go online again. Maybe a checkbox "don't ask again" would be good, as seen on many repetitive dialogues. It could also be don't ask again until its been online and sent all the messages waiting, or until a TB restart (which might not be as good, since I guess many people like me leave TB running all the time, especially given the multi-minute startup times on Macs).

Note that the point about automatic retrying i don't believe is valid, because I'm pretty sure it does this check anyway if there are "Send Later" messages, and then sends them all automatically.

I agree - if the message hasn't been sent it shouldn't be saved in Sent folder, only once a Send occurs.

For the case where sending is successful, but "Save to Sent" failed - which is surprisingly common, I am NOT suggesting two options: "Save to Local Folder" and "Save to Sent", I am suggesting that Save to the local Sent folder (and automatic synchronization) is what you always want. This means that this temporary failure is no different (in final result) from a normally successful "Save to Sent". In fact, I can't see why any of the other options exist, or why the user even needs to know, since this behavior is exactly what happens if I move messages around folders when in a poorly connected environment, i.e. the background synchronization of client and server happens automatically.

You could also go one step further - in a message send there are two potentially length dialogues - the Sending process itself which is reasonable, and the "Save to Sent" which I would suggest does not need to be a dialog, just save locally to the Sent folder and synchronize in background like for all other folders.

I'm not sure what you mean by "when offline store is not in use", I've only ever used TB with full local copies of remote folders, and AFAIK that synchronization process works for all other IMAP folders, or at least should do. Am I understanding you right, that
a: its not the folders that get synchronzied, its the set of imap commands to move messages, and
b: putting a message into the Sent folder - the first time (after a successful send) - is different from moving messages between folders (or deleting messages) which is what other interactions with the Folders do.

gene smith

Comment 57

•

10 months ago

I'm not sure what you mean by "when offline store is not in use"

TB allows you to just let the server do the full messages body storage and TB just stores locally important headers, Subject, Data, Sender etc. The headers are encoded in TB's .msf files. Only if offline store is wanted for a folder is the full message stored in TB's mbox files (E.g., Sent). Of course, the default setup is what you are using where all the folder have offline store, but many users (for example, me) mostly just leave everything on the server and don't store many folders locally in "offline store" mbox (or optionally, maildir) files.

You can set individual folder to have or not have offline store using right-click/properties/synchronization or you can using Settings/Sync & Storage/Message Synchronization to set all folders to have storage or not and then Advanced button to select individual folders.

So it still would be necessary (or at least good) to provide an option to save to Local Folders when the user has no "Sent Mail" mbox file to save the sent message into.

gene smith

Comment 58

•

10 months ago

•

Edited

I'm not exactly sure how this works but I think when you move or copy a message inside the same imap account and you have offline store for the destination folder, TB first copies the message to the destination mbox file and adds the header to the .msf file and tells the server to do an imap copy or imap move. If the imap command succeeds, we are done and the messages in the destination folder does not need to be fetched. (Or maybe the imap copy/move occurs first and the .msf and mbox are not updated unless the imap command succeeds.)

When a message is sent and then saved to Sent, it is just imap appended to the Sent folder using imap append command. It is not also written to mbox or .msf file until the Sent folder is accessed by the user where the header and message body are fetched and stored in .msf and mbox (provided the user has an mbox for Sent folder).

When messages are copied or moved between accounts, the message is obtained from offline store (if present) or fetched from the server. It is then imap appended to the mailbox/folder in the destination account. No imap header and message fetch at destination and write to destination .msf or mbox occurs until the destination folder in the destination account is accessed.

When you do these thing with TB offline (or with a server, imap or smtp, offline) is when it get really complicated and I'm not sure how it really works.