Bugzilla

Comment 2

•

11 years ago

I've been getting this error message sporadically on various accounts as well for the last 6-9 months. Unfortunately, I didn't record which version of TB was specifically affected, but this happens regularly. The pattern is that for around 1-3 hours, any email I send will get the "error saving message to sent" error. Repeated attempts to save the message to Sent are without result, until the "bad period" is over. I also cannot save the message to Drafts. In most cases, the actual message does get sent, but in a few, it appears not to have been sent. Note that I've experienced this both on Mac and on Linux, so this appears to be a platform-independant bug. Some additional steps: 1) set up an IMAP account 2) have the Sent folder stored on the mailserver, NOT on the local machine 3) use the account to send mail for a couple of weeks 4) eventually, this issue will crop up Given the inconsistency in encountering the issue, I suspect that it's triggered by something happening on the server, such as a slow response in saving the message to Sent, or something else. Note that I've encountered this error with 4 different accounts being stored on 3 different servers using 3 different IMAP software packages. So the issue appears to be server-independant as well. Screen shots of the error cycle attached in a moment.

Status: UNCONFIRMED → NEW

Ever confirmed: true

Updated

•

11 years ago

OS: Windows 7 → All

Comment 3

•

11 years ago

Attached image error saving to sent part one — Details

Comment 4

•

11 years ago

Attached image error saving to sent part two — Details

Comment 5

•

11 years ago

Attached image error saving to sent part three — Details

Comment 6

•

11 years ago

Note that, despite bug 786868, there is no evidence that the IMAP server with the Sent folder is actually unavailable, although it may be responding slowly. I have a suspicion that someone turned down the timeout on "save to Sent/Drafts" to something like 100ms.

Comment 7

•

11 years ago

Hmmm. This isn't just a matter of a timeout. I tried increasing the server timeout to 100, and while TB did spend longer trying to save the message to Sent, it still failed. So something's going wrong with "save to sent" and "save to drafts"

Alex Cabal

Comment 8

•

11 years ago

This has been happening to me too lately. I have email accounts at Rackspace, and one or twice a week there will be spans of several hours where any attempt to save mail to "sent" or "drafts", or even to open the "sent" and "drafts" folders fails. Note opening other folders on the same account, like Inbox, works fine, and sending mail with SMTP works fine--just copying to sent/drafts and opening those folders fails. It's pretty frustrating!

Alex Cabal

Comment 9

•

11 years ago

Note: Using TB 17.0.8 on Ubuntu 12.04 x64, IMAP mail accounts.

Comment 10

•

11 years ago

Actually, increasing the server timeout did have an effect: now, when TB can't save to Sent, it crashes. Typically, TB crashes without invoking Breakpad, so no crash report.

Comment 11

•

11 years ago

This remains broken. Clearly some TB developer hard-coded a very short timeout into "save sent", and nobody wants to look for it ...

Comment 12

•

11 years ago

(In reply to [:jberkus] Josh Berkus from comment #11) > Clearly some TB developer hard-coded a very short timeout into "save sent", (snip) It's not timeout for Sent folder. It's timeout for "OK response after last data chunk send in APPEND command execution". This timeout is not so large but is never too small in ordinal environment, even if it's small for some recent IMAP servers which can be sometimes called not-so-well-configured. A known reason of "delay of OK response after last data chunk send in APPEND" is; virus scan for IMAP mail data by client side anti-virus software. Client side virus scanner hooks Tb's mail data send, and saves mail data in his buffer. And, after last data chunk is sent from Tb, virus scanner checks entire mail data, and send entire mail data to IMAP server. So, even if IMAP server returns OK response wihin reasonable time, it takes sufficiently long for Tb. If IMAPS,(SSL is used), this kind of virus scan is usually done by local proxy server. Tb<-non-SSL->port=143, IMAP proxy server by anti-virus software <-SSL-> actual IMAP server In this case, "actual IMAP server for Tb" is local IMAP proxy server. To bug opener and all problem reporters: Please surely isolate this kind of "interfere of anti-virus software" and "actual delay of OK response from IMAP server", please.

Alex Cabal

Comment 13

•

11 years ago

This is definitely not due to client-side antivirus, as I'm running TB on Ubuntu 12.04 without an antivirus. It may be network-level antivirus or proxy, but I connect to both SMTP and to IMAP using forced SSL/TLS, without any special proxy configuration. Also note that this does not just affect Sent Mail. Whenever this bug occurs, I find that I'm also never able to access Archives, nor Sent Mail, nor various other folders on that same account. (However Inbox always seems to work, as do *some* folders; I can always receive new mail.) This only happens on certain networks, consistently on public wifi in certain libraries. While this might suggest that it's an issue in the network's configuration, as I said I connect using SSL/TLS and without a proxy config, and *some* folders like Inbox do work fine. If it's not TB's fault, then regardless TB should still fail in a more graceful way than "inexplicably cannot save sent mail or access some, but not all, folders, seemingly at random". But the fact that I'm using SSL/TLS, and that some things like Inbox work fine, suggest to me that this has something to do with TB.

Comment 14

•

11 years ago

WADA, Believe it or not, real networks have real network delays. And whenever Thunderbird encounters one, it blows up, as detailed above. Further, this is a new problem, as of 17 ... this problem didn't exist before, so somebody changed something.

Comment 15

•

11 years ago

(In reply to [:jberkus] Josh Berkus from comment #14) > WADA, > Believe it or not, real networks have real network delays. If so, "data such as NSPR log with timestamp" should be provided by problem reporter for problem analysis by developers, isn't it? (please note that here is bugzilla.mozilla.org to report Tb's bug to developers, instead of support forum.) > Further, this is a new problem, as of 17 ... > this problem didn't exist before, so somebody changed something. If timeout relivant problem, both "NSPR log with timestamp before Tb 17" and "NSPR log with timestamp after Tb 17" are needed for developers to analyze problem of this bug, isn't it? (please note that here is bugzilla.mozilla.org to report Tb's bug to developers, instead of support forum.)

Comment 16

•

11 years ago

Wada, Aha, I can see you're taking the tack of "I want to deny that this bug exists, therefore I will attack the reporters and claim that they are idiots". Well, I suppose that's one way to close bugs. Not generally the Mozilla way, though.

scottyg

Comment 17

•

11 years ago

I don't know if this will help anyone but I was getting the same error sporadically over the past few weeks. Turns out that my email server updated some of their settings (namely the way they determine your User Name for your account). The user names used to be username+domain.com (my guess is to avoid the double @ when using the address username@domain.com@server.com) but for whatever reason they updated the user names to be username@domain.com. I had to go into my Thunderbird server settings account (and Outgoing Server) and update the usernames to replace the + with the @ symbols. Hope that helps someone.

Comment 18

•

11 years ago

(In reply to alex from comment #13) > Also note that this does not just affect Sent Mail. Whenever this bug > occurs, I find that I'm also never able to access Archives, nor Sent Mail, > nor various other folders on that same account. (However Inbox always seems > to work, as do *some* folders; I can always receive new mail.) FYI. It sounds similar phenomenon to bug 868041 (bug opener re-opened that bug by bug 8868041 comment #15, because same problem occurred in Tb 17.)

Comment 19

•

11 years ago

(In reply to [:jberkus] Josh Berkus from comment #7) > Hmmm. This isn't just a matter of a timeout. I tried increasing the server > timeout to 100, (snip) AFAIK, default of mailnews.tcptimeout==100(sec). Therefore, "increasing the server timeout to 100" sounds pretty strange for me. I use Tb 17 on Win-XP and I don't know default of mailnews.tcptimeout in Tb 17 on other OS. Is "default of mailnews.tcptimeout" not 100 in Tb 17 on other than Win? Or you used "smaller than 100" as mailnews.tcptimeout then you increased to 100? (IIRC, default was less than 100 in older Tb verions. So, less than 100 might be set.) Or, Josh Berkus, you changed mail.server.serverX.timeout value, which is for IDLE interval in minutes, which should be less than 30 minutes? (In reply to [:jberkus] Josh Berkus from comment #16) Josh Berkus, you don't know "how to get NSPR log"? Even if you do not know "how to get NSPR log", do not be ashamed it. It's special feature for trouble shooting, problem analysis, debugging. So, If you do not know "how to get NSPR log", please ask at any time. By the way, can you surely rule out following case without any log data/trace data? 1. Before Tb 17, Tb sent mail data even when server returned NO while appending data. This is already known behavior of Tb. 2. When server returns NO while Tb is sending data because of "temporary resource shortage", for example, 95% of disk space has been used, Before Tb 17 : Tb continuously sends data with ignoring NO response. Because of "temporary shortage", server accepts entire data from Tb. After Tb 17 : Tb doesn't ignore "NO" response, then Tb termiates append operation. AFAIK, Tb 17(and trunk nightly build) still ignores "NO while appending mail data", so I think above won't occur. However, I believe above can't be surely ruled out without IMAP log.

Comment 20

•

11 years ago

(In reply to alex from comment #13) > Also note that this does not just affect Sent Mail. Whenever this bug > occurs, I find that I'm also never able to access Archives, nor Sent Mail, > nor various other folders on that same account. (However Inbox always seems > to work, as do *some* folders; I can always receive new mail.) FYI. A big diference between Inbox and others is; - Inbox : If max cached connections>1, Inbox is always selected at a cached connection. (on cached connection is dedicated to Ibox) - Other than Inbox : When a MboxA is selected at a cached conections, any other MboxX can be selected at a cached connection, and MboxA bcoes "unseleced". (Any Mbox at a cached conection can be hi-jack'ed by other Mbox) IIRC, problem like "data of previously selected Mbox is not cleared cleanly" exists or existed, and this problem caused "wrong Mbox access". So, following might happen. Sent is opened and Sent is selected at a cached connection. MboxX is selected at the connection, and Sent is de-selected. Sent folder(MsgDatbase) is not closed yet. Upon next access to Sent, the connection where MboxX is currently selected is re-used. Folder is accessed without new "select Sent" at the cached connection due to bug. If this kind of problem, problem can occur on many folders. Sorry but I can't recall bug number, and I don't rememer that was old bug or recent bug. If this kind of problem, problem should disappear by "Go Work Offline, then Go back Work Online", open Sent(click other foler, then click Sent again), and try to copy mail to Sent.

Comment 21

•

11 years ago

WADA, Thanks! That certainly sounds like the behavior I'm observing. To sum up: 1. IMAP server is being sluggish due to load/network issues. 2. Get error saving to Sent. 3. Therefore, every email gets an error saving to Sent (or Drafts, or Templates) until TB is restarted. I will test the offline/online switch the next time it happens and see if it unsticks TB as a diagnosis of the issue.

Brian S. Craigie

Comment 22

•

11 years ago

Please explain how to get the NSPR log because I have the same problem. Thanks

Comment 23

•

11 years ago

See bug 402793 comment #28 for getting NSPR log.

Comment 24

•

11 years ago

@all Hey guys. Solution to this issues is in fact trivial and is purely to settings. The only thing you need to do is to change the authentication method (on SSL/TLS) from normal password to encrypted. I would suggest to do this for both imap and smpt. Hope this helps.

Comment 25

•

11 years ago

Rafael, Nice thought, but no. I've always used only encrypted passwords.

Comment 26

•

11 years ago

(In reply to [:jberkus] Josh Berkus from comment #21) > WADA, > > Thanks! That certainly sounds like the behavior I'm observing. To sum up: > > 1. IMAP server is being sluggish due to load/network issues. > 2. Get error saving to Sent. > 3. Therefore, every email gets an error saving to Sent (or Drafts, or > Templates) until TB is restarted. > > I will test the offline/online switch the next time it happens and see if it > unsticks TB as a diagnosis of the issue. results?

Flags: needinfo?(josh)

Comment 27

•

11 years ago

Right, so if this doesn't help, go to: Account settings -> Copies & Folders -> and at each one of these options, change default to "Other:" and specify where particular email should be stored.

Comment 28

•

11 years ago

(In reply to Rafael from comment #27) > Right, so if this doesn't help, go to: > > Account settings -> Copies & Folders -> and at each one of these options, > change default to "Other:" and specify where particular email should be > stored. this might be a potential workaround but I think the goal here should be to find the cause of the problem and fix it. Anyway, how does this correlate to your suggestion in comment 24?

Flags: needinfo?(rafael)

Comment 29

•

11 years ago

(In reply to Wayne Mery (:wsmwk) from comment #28) > (In reply to Rafael from comment #27) > > Right, so if this doesn't help, go to: > > > > Account settings -> Copies & Folders -> and at each one of these options, > > change default to "Other:" and specify where particular email should be > > stored. > > this might be a potential workaround but I think the goal here should be to > find the cause of the problem and fix it. > > Anyway, how does this correlate to your suggestion in comment 24? It doesn't, it's just another way for getting around that. This fix will work with any settings suggested at comments 24. I would be very interested to get this sorted the proper way + no matter what settings we will use issue is returning from time to time, so it's not like permanent fix unfortunately. Very annoying! :(

Flags: needinfo?(rafael)

Comment 30

•

11 years ago

Wayne, Nothing yet. The couple of times I've had this happen recently has been when I lost connectivity entirely, so no amount of tinkering is going to get Sent back. The thing that makes this bug so difficult is that nobody's found a way to reproduce it under lab conditions.

Flags: needinfo?(josh)

Comment 31

•

11 years ago

FWIW, Zmailcloud reports that they get a lot of issues filed by their customers that the ones on Thunderbird get this issue whenever their servers get busy.

Comment 32

•

11 years ago

(In reply to [:jberkus] Josh Berkus from comment #31) > FWIW, Zmailcloud reports that they get a lot of issues filed by their > customers that the ones on Thunderbird get this issue whenever their servers > get busy. Right I have an idea. I can set you up guys with email account on my server. This should help in reproducing the issue, well I have it on all email account using IMAP on this server so It might be also related to the way server is setup, because as far as I know, there is nothing wrong with settings, but it all changed after we had last big update of TB, if I would go back to the old version, it should be working fine. I guess. Hope this helps. Let me know if you want that email account. I'm more than happy to support you as I can to resolve this ones for all.

Comment 33

•

11 years ago

Wayne, We had a server outage today, and I've confirmed that the Offline/Online switch works. That is, by setting "work offline" and then setting "work online", the Sent folder issue goes away. So looks like your diagnosis is correct.

Mark Eirich

Comment 34

•

11 years ago

Is there any way we can change the timeout? In my tests, it fails after 19 seconds, every single time. I wasn't able to find anything in the configuration that seemed to correspond. In my case, I can make the problem stop by disabling our antivirus/firewall software. I've spent multiple days on this issue and I'm to the point where I either have to change firewall software or change e-mail clients, for the whole organization.

Updated

•

10 years ago

Component: Untriaged → Networking: IMAP

Product: Thunderbird → MailNews Core

shindiggs

Comment 35

•

10 years ago

Is Mozilla doing anything on this issue? I installed Thunderbird recently as a better email tool than Windows Live Mail - but it appears to be just as buggy. I intermittantly receive the "cannot save to sent" error - but that's not the only problem. If I cancel the error the email does not SEND and I need to redo the whole email. It wouldn't be so bad if it was just stored in the outbox until it could send, but the fact that emails are not actually sending and not being saved in outbox when this error occurs is ridiculous.

Comment 36

•

10 years ago

(In reply to shindiggs from comment #35) > Is Mozilla doing anything on this issue? You can be quite sure we volunteers (Mozilla) are extremely busy fixing issues and preparing the next releases of Thunderbird. But as you can see from the bug comments this issue is not near a solution. If comment 0 is correct and the prior version (16) does not have this problem then this issue is a regression. Everyone who has commented here can help by stating whether the problem started for them in a specific version, by testing if necessary a prior version downloadable from http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/

Comment 37

•

10 years ago

Potentially related bug reports https://bugzilla.mozilla.org/buglist.cgi?list_id=11480006&short_desc=error%20sav&resolution=---&query_format=advanced&longdesc=error%20saving&short_desc_type=anywordssubstr&product=MailNews%20Core&product=Thunderbird&longdesc_type=substring

stephen

Comment 38

•

9 years ago

i've also been getting this issue intermittently with thunderbird for the last couple of years, and this bug is still clearly occuring. i am using thunderbird 38.3.0 its quite shocking that this bug has remained in the product for so long

Umberto Tozzato

Comment 39

•

9 years ago

I get a similar message for every message, even when the editor tries to automatically save the thing to drafts. Also, the warning message doesn't specify the folder name. I know that Thunderbird is a dead product, but i have to use it at my office and i keep getting this bug... Can a good soul please fix this annoying bug and call it a day for the whole project?

Siebe Bosch

Comment 40

•

9 years ago

I've found a work-around. Whenever this error pops up, disable your wifi and press <Try again>. Still annoying as hell, but at least you get to save important messages to your sent folder.

Updated

•

9 years ago

Comment 41

•

8 years ago

In my case where I used Thunderbird with office365 I was getting this error because my IMAP settings were broken. So always make sure your mail download works.

Didier

Comment 42

•

8 years ago

I had that message in every mail I sent, solved it changing from "local Folder" to sent folder in my mail account in the following path: Edit>Account Settings> Copies & Folders> Place a copy in

Rob

Comment 43

•

8 years ago

Same problem here guys. However, only occurs if I have attachments. 'Workaround' in description works for me. System: MaxOSX Thunder Ver.:45.3.0