Launchpad has imported 161 comments from the remote bug at https://bugzilla.mozilla.org/show_bug.cgi?id=780124.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2012-08-03T12:36:25+00:00 Rob-smeets wrote: User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1 Build ID: 20120713134347 Steps to reproduce: When I send a mail using an incorrect smtp server (e.g. I have stmp.telenet.be configured but I'm at a customer whose ISP only accepts relay.skynet.be), and the server sends an error message instead of just timing out, Actual results: I get an error message (as I used to get), but instead of keeping the composer window open, the composer window is closed and the mail (which has not been sent succesfully) ends up in my SentMail. Expected results: Before the latest update, I would get an error message but the composer window would remain open so: - I would know that sending failed - I could try again with the correct smtp server Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/0 ------------------------------------------------------------------------ On 2012-08-03T13:10:29+00:00 Rob-smeets wrote: Created attachment 648680 An example of an SMTP error message which I refer to Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/1 ------------------------------------------------------------------------ On 2012-08-03T19:53:40+00:00 Lucdischert wrote: Duplicate of bug 780086 ? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/2 ------------------------------------------------------------------------ On 2012-08-04T00:09:35+00:00 M-wada-7 wrote: (In reply to Rob from comment #1) > An example of an SMTP error message which I refer to "relaying denied" is seen in screen shot. "relaying denied" is usually 550 or 5.7.1 from SMTP server o Tb, and mail is rejected by SMTP server. See bug 228198 for it. In that bug, no one referred to phenomenon like "composition window is closed and mail is saved in Sent". And, there similar bugs were opened consecutively. bug 775999, bug 780086, bug 780124(this bug) Perhaps a regression by a Tb release. Setting dependency of those bugs for ease of tracking and analysis. Can you persistently reproduce "relaying denied" from SMTP server? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/3 ------------------------------------------------------------------------ On 2012-08-04T00:20:16+00:00 M-wada-7 wrote: 4-th bug, Bug 780115 for "too many open connections error from SMTP server". "Save to Sent folder" in such case may be a protection from loss of composing mail in case of abnormal termiation of mail composition window. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/4 ------------------------------------------------------------------------ On 2012-08-04T01:00:15+00:00 M-wada-7 wrote: Unable to produce problem in Tb 14.0.0 on Win-XP, by 553 to MAIL FROM: from Yahoo! SMTP server(Yahoo! rejects From: address other than assiged mail address). When error occurred, dialog for the error was opened, and composition window was still kept after close of the dialog. (SMTP log) > 00000022 0.71450758 [6064] 0[210f140]: PLAIN auth > 00000023 0.71459109 [6064] 0[210f140]: Logging suppressed for this > command (it probably contained authentication information) > 00000024 0.80845976 [6064] 0[210f140]: SMTP entering state: 0 > 00000025 0.80857205 [6064] 0[210f140]: SMTP Response: 235 OK, go > ahead > 00000026 0.80865669 [6064] 0[210f140]: SMTP entering state: 18 > 00000027 0.80873466 [6064] 0[210f140]: SMTP Login response, code > 235 > 00000028 0.80880642 [6064] 0[210f140]: SMTP entering state: 3 > 00000029 0.80890781 [6064] 0[210f140]: SMTP Send: MAIL > FROM:<z-01@x.x.x> SIZE=350 > 00000030 0.91729367 [6064] 0[210f140]: SMTP entering state: 0 > 00000031 0.91737914 [6064] 0[210f140]: SMTP Response: 553 From > address not verified - see > http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html > 00000032 0.91746324 [6064] 0[210f140]: SMTP entering state: 5 > 00000033 6.38465023 [6064] 0[210f140]: SMTP Send: QUIT > 00000034 6.38476753 [6064] 0[210f140]: SMTP entering state: 0 > 00000035 6.57907629 [6064] 0[210f140]: SMTP entering state: 0 > 00000036 6.57912779 [6064] 0[210f140]: SMTP Response: 221 Service > Closing transmission > 00000037 6.57919836 [6064] 0[210f140]: SMTP entering state: 11 > 00000038 6.58548069 [6064] 0[210f140]: SMTP entering state: 12 > 00000039 6.58557463 [6064] 0[210f140]: SMTP connection error > quitting 80004004, ignoring As seen in log, "error to QUIT" takes 5 seconds. It was probably because I kept dialog open for 5 seconds. Tb looks to issue QUIT after dialog close. And, 221 is normally returned to QUIT after 200 msec from SMTP server. Can you get SMTP log? (see bug 402793 comment #28 for getting log) QUIT sequence is normal when error occurs? Auto-save may be relivant. Do you enable auto-save? If yes, was auto-save invoked before your send operation? (Check "Show confirmation dialog when messages are saved" at Copis&Folders) Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/5 ------------------------------------------------------------------------ On 2012-08-04T01:19:41+00:00 M-wada-7 wrote: Problem was reproduced by 553 to MAIL FROM:, with keep error dialog open for long time. (1) Send, 553 to MAIL FROM: from smtp.mail.yahoo.com (2) Error dialog is opened. Keep it open (3) Wait for while, netstat /n /b /o Confirm "no connection between Tb and smtp.mail.yahoo.com" (4) OK at error dialog => Mail was saved to Sent folder, and composition window was closed Log with SET NSPR_LOG_MODULES=timestamp,smtp:5,MsgCopyService:5 > 00000022 0.50886804 [6064] 0[210f140]: PLAIN auth > 00000023 0.50891578 [6064] 0[210f140]: Logging suppressed for this > command (it probably contained authentication information) > 00000024 0.60844296 [6064] 0[210f140]: SMTP entering state: 0 > 00000025 0.60849607 [6064] 0[210f140]: SMTP Response: 235 OK, go > ahead > 00000026 0.60854828 [6064] 0[210f140]: SMTP entering state: 18 > 00000027 0.60859132 [6064] 0[210f140]: SMTP Login response, code > 235 > 00000028 0.60863435 [6064] 0[210f140]: SMTP entering state: 3 > 00000029 0.60869664 [6064] 0[210f140]: SMTP Send: MAIL > FROM:<z-01@x.x.x> SIZE=350 > 00000030 0.72535086 [6064] 0[210f140]: SMTP entering state: 0 > 00000031 0.72543770 [6064] 0[210f140]: SMTP Response: 553 From > address not verified - see > http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html > 00000032 0.72552711 [6064] 0[210f140]: SMTP entering state: 5 > 00000033 283.92575073 [6064] 0[210f140]: SMTP Send: QUIT > 00000034 283.92584229 [6064] 0[210f140]: SMTP entering state: 0 > 00000035 283.92593384 [6064] 0[210f140]: SMTP Send: QUIT > 00000036 283.93383789 [6064] 0[210f140]: request 50b8b40 DoCopy - src > dest mailbox://x.x.x/Sent numItems 0 type=1 > 00000037 284.00128174 [6064] 0[210f140]: NotifyCompletion - src dest > mailbox://x.x.x/Sent > 00000038 284.00137329 [6064] 0[210f140]: request 50b8b40 Clearing OK > request - src dest mailbox://x.x.x/Sent numItems 0 type=1 Confirming. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/6 ------------------------------------------------------------------------ On 2012-08-04T02:30:33+00:00 M-wada-7 wrote: *** Bug 775999 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/7 ------------------------------------------------------------------------ On 2012-08-04T02:31:54+00:00 M-wada-7 wrote: *** Bug 780086 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/8 ------------------------------------------------------------------------ On 2012-08-04T02:33:02+00:00 M-wada-7 wrote: *** Bug 780115 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/9 ------------------------------------------------------------------------ On 2012-08-06T10:37:06+00:00 Rob-smeets wrote: I have an smtp log: 0[110f140]: SMTP Connecting to: smtp.telenet.be 0[110f140]: SMTP entering state: 0 0[110f140]: SMTP Response: 421 gerard.telenet-ops.be bizsmtp 91.183.175.114 relaying denied 0[110f140]: SMTP entering state: 14 0[110f140]: SMTP Send: QUIT 0[110f140]: SMTP entering state: 0 0[110f140]: SMTP Send: QUIT Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/10 ------------------------------------------------------------------------ On 2012-08-06T10:41:44+00:00 Rob-smeets wrote: Re. auto-save: I don't know, I can't find the menu item you mention (I have a localized version of Thunderbird). Can you post a screenshot? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/11 ------------------------------------------------------------------------ On 2012-08-06T10:49:46+00:00 Rob-smeets wrote: (In reply to Rob from comment #11) > Re. auto-save: I don't know, I can't find the menu item you mention (I have > a localized version of Thunderbird). Can you post a screenshot? Found it. There's no check mark in the 'Show confirmation dialog' box. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/12 ------------------------------------------------------------------------ On 2012-08-16T14:57:21+00:00 Fleandro10415 wrote: I have installed Thunderbird 15 Beta 3 in Windows 7 Professional x86, and the same problem still happens. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/13 ------------------------------------------------------------------------ On 2012-08-30T07:17:04+00:00 Rob-smeets wrote: Not fixed in TB 15.0 release, and a very, very annoying bug for those of us who need to change smtp servers often when at other customers' sites. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/14 ------------------------------------------------------------------------ On 2012-08-30T08:28:26+00:00 Ludovic-mozilla wrote: Can someone affected follow the instrctions at http://www.rumblingedge.com/2009/02/24/howto-find-regression-windows- through-manual-binary-search/ , so we can figure out what broke this ? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/15 ------------------------------------------------------------------------ On 2012-08-30T08:36:51+00:00 Rob-smeets wrote: Ludovic, I think the bug must be new since Thunderbird 14 (unless the particular mail server which gives the error messages has changed his behaviour recently). Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/16 ------------------------------------------------------------------------ On 2012-09-04T21:04:06+00:00 M-wada-7 wrote: *** Bug 788188 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/17 ------------------------------------------------------------------------ On 2012-09-28T22:01:49+00:00 M-wada-7 wrote: *** Bug 795338 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/18 ------------------------------------------------------------------------ On 2012-09-28T22:17:59+00:00 M-wada-7 wrote: A relevant change : patch for bug 758878(status-thunderbird14: fixed) Was problem exposed by the patch? I can't think so, because the patch merely added following code, and because "SMTP connection error quitting ..." was not logged when this bug occurred although it was logged when this bug didn't occur... > + // ignore errors handling the QUIT command so fcc can continue. > + if (m_sendDone && NS_FAILED(aStatus)) > + { > + PR_LOG(SMTPLogModule, PR_LOG_ALWAYS, > + ("SMTP connection error quitting %lx, ignoring ", aStatus)); > + aStatus = NS_OK; > + } Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/19 ------------------------------------------------------------------------ On 2012-09-28T22:41:05+00:00 M-wada-7 wrote: nsSmtpProtocol.cpp is only module changed by bug 758878, and file revisions is following. > http://hg.mozilla.org/comm-central/log/45ccb6afce84/mailnews/compose/src/nsSmtpProtocol.cpp Affected by change such as "Switch comm-central from using nsnull to nullptr", "Change types to nsresult", "Make more nsSmtpProtocol methods return nsresult"? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/20 ------------------------------------------------------------------------ On 2012-09-29T00:37:32+00:00 M-wada-7 wrote: Regression window: (checked by thunderbird-14.0a1.en-US.win32.zip) (a) Good : /pub/mozilla.org/thunderbird/nightly/2012/04/2012-03-19-03-00-43-comm-central (b) Bad : /pub/mozilla.org/thunderbird/nightly/2012/04/2012-03-20-03-01-27-comm-central Changes pushed after 2012-04-19 00:00:00, before 2012-04-20 06:00:00 > http://hg.mozilla.org/comm-central/pushloghtml?startdate=2012-04-19+00%3A00&enddate=2012-04-20+06%3A00 Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/21 ------------------------------------------------------------------------ On 2012-09-29T01:08:04+00:00 Bugzilla-tf wrote: *** Bug 795529 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/22 ------------------------------------------------------------------------ On 2012-09-29T01:09:54+00:00 Bugzilla-tf wrote: *** Bug 792930 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/23 ------------------------------------------------------------------------ On 2012-09-29T01:10:18+00:00 Bugzilla-tf wrote: *** Bug 792803 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/24 ------------------------------------------------------------------------ On 2012-09-29T01:11:19+00:00 Bugzilla-tf wrote: *** Bug 793154 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/25 ------------------------------------------------------------------------ On 2012-09-29T03:40:56+00:00 M-wada-7 wrote: Correct Regression window: (checked by thunderbird-14.0a1.en-US.win32.zip) (a) Good : /pub/mozilla.org/thunderbird/nightly/2012/03/2012-03-19-03-00-43-comm-central (b) Bad : /pub/mozilla.org/thunderbird/nightly/2012/03/2012-03-20-03-01-27-comm-central Correct Changes pushed after 2012-03-19 00:00:00, before 2012-03-20 06:00:00. > http://hg.mozilla.org/comm-central/pushloghtml?startdate=2012-03-19+00%3A00&enddate=2012-03-20+06%3A00 Sorry for mistake. Regression by patch for bug 554044(Target Milestone: Thunderbird 14.0)? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/26 ------------------------------------------------------------------------ On 2012-09-29T03:58:08+00:00 M-wada-7 wrote: To see "Copy to Sent" and "Socket close" by NSPR log, use following parameter. NSPR_LOG_MODULES=timestamp,smtp:5,MsgCopyService:5,nsSocketTransport:5 No connection between Tb and SMTP server can be observed by "netstat /n /b /o". It usually has "CLOSE_WAIT" status intead of "ESTABLISHED" after "Socket close" by Tb. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/27 ------------------------------------------------------------------------ On 2012-09-29T06:35:08+00:00 M-wada-7 wrote: cc-ing to Mark Banner who is ownwer of bug 554044. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/28 ------------------------------------------------------------------------ On 2012-09-30T18:23:56+00:00 Rob-smeets wrote: Happy to see something move here. Sorry that I couldn't find the time to do the regression test myself. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/29 ------------------------------------------------------------------------ On 2012-11-09T07:26:34+00:00 Rob-smeets wrote: If necessary, I can test nightly builds to see if this is solved. Just let us know. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/30 ------------------------------------------------------------------------ On 2012-11-23T15:45:27+00:00 Rheras wrote: I frequently receive this error in my laptop at work when I send an email. However, at home: the same Exchange account (through IMAP), same operating system (Windows 7 x64) and same Seamonkey version 2.13, but this error doesn't happen here at home. I don't understand the reason, what's happening it in my laptop at work and not in my pc at home, maybe the intranet environment? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/31 ------------------------------------------------------------------------ On 2012-11-29T06:20:45+00:00 M-wada-7 wrote: *** Bug 797814 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/32 ------------------------------------------------------------------------ On 2012-11-29T06:35:45+00:00 David Lechner wrote: *** Bug 813537 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/33 ------------------------------------------------------------------------ On 2013-02-08T05:13:38+00:00 M-wada-7 wrote: *** Bug 783352 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/34 ------------------------------------------------------------------------ On 2013-02-12T18:25:58+00:00 L-jay-4 wrote: Smtp Yahoo: resources temporarily unavailable Thunderbird moves to sent folder as if everything is fine. Message did not go through. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/35 ------------------------------------------------------------------------ On 2013-02-20T09:38:25+00:00 Ace0401 wrote: I confirm I have this problem and is VERY annoying. Thunderbird 17.0.3, Yahoo smtp smtp.mail.yahoo.com port 465 SSL/TSL Normal password, but with a weird scenario: I get this "The mail server responded: Resources temporarily unavailable" error only when trying to send to a yahoo mail. If I send to other servers it goes fine, if I send to yahoo mail accounts it fails every time with this error, message going into Sent folder but doesn't get actually sent. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/36 ------------------------------------------------------------------------ On 2013-02-22T19:25:03+00:00 Iongigixx wrote: I cna also confirm this behavior of thunderbird and I have found what is causing it. I'm using qmail mail server and the message is copied to sent folder on error when the mail server responds with a 550 error and immediately close smtp connection. This occurs when SMTP550DISCONNECT is activated in tcpserver. SMTP550DISCONNECT Disconnect the SMTP session if a 5xx is produced by the sender Default: off Affects: qmail-smtpd Example: "" (any value will do) Note: This is useful if you have a spammer trying different senders or recipients in the same session separated by rset's. Be aware of the fact that this option "breaks" RFC 2821 and may cause problems with legitimate SMTP traffic. When is not activated, Thunderbird acts as expected on such errors. I'm using 17ESR and I can confirm that 10ESR worked ok. As far as I know yahoo also is using qmail Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/37 ------------------------------------------------------------------------ On 2013-02-25T10:47:58+00:00 Rob-smeets wrote: How can you tell which mail server is being used? Anyway, since many smtp servers seem to use this or similar functionality, maybe it's worth programming around it in Thunderbird? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/38 ------------------------------------------------------------------------ On 2013-02-25T11:43:25+00:00 Iongigixx wrote: http://qmail.omnis.ch/top.html A number of large Internet sites are using qmail: USA.net's outgoing email, Address.com, Rediffmail.com, Colonize.com, Yahoo! mail, Network Solutions,... And I remember I received a message from yahoo's mailer-daemon saying ..this is qmail-send at ... I've been using TB from version 1 to 10esr with no issues with SMTP550DISCONNECT. Until now. I strongly believe that Thunderbird guys must correct this, better said to revert to what was before. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/39 ------------------------------------------------------------------------ On 2013-03-09T02:47:38+00:00 M-wada-7 wrote: *** Bug 849368 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/40 ------------------------------------------------------------------------ On 2013-03-12T12:50:07+00:00 Rsx11m-pub wrote: *** Bug 850162 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/41 ------------------------------------------------------------------------ On 2013-03-15T12:16:52+00:00 M-wada-7 wrote: By bug 554044, which is a change seen in regression window, parameter was added to SendQuit(). > -PRInt32 nsSmtpProtocol::SendQuit() > +PRInt32 nsSmtpProtocol::SendQuit(SmtpState aNextStateAfterResponse) And, m_nextStateAfterResponse value was changed from solid SMTP_DONE to parameter value of aNextStateAfterResponse. > m_nextState = SMTP_RESPONSE; > - m_nextStateAfterResponse = SMTP_DONE; > - return(0); > + m_nextStateAfterResponse = aNextStateAfterResponse; > + > + return SendData("QUIT" CRLF); // send a quit command to close the > connection with the server. However, not all call of SendQuit() is not changed to SendQuit(NextStateAfterResponse). http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsSmtpProtocol.cpp#1675 > 1675 nsresult nsSmtpProtocol::SendMessageResponse() > 1689 return SendQuit(); > http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsSmtpProtocol.cpp#562 > 562 nsresult nsSmtpProtocol::SendHeloResponse(nsIInputStream * inputStream, > uint32_t length) > 587 return SendQuit(); Is default of aNextStateAfterResponse SMTP_DONE? Is this relevant to this bug's problem? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/42 ------------------------------------------------------------------------ On 2013-03-21T03:34:57+00:00 Rsx11m-pub wrote: *** Bug 853233 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/43 ------------------------------------------------------------------------ On 2013-03-27T07:52:30+00:00 Rob-smeets wrote: Oh boy, this bug is driving me crazy. I will be forever endebted to the one who solves it. Come to Belgium and I'll buy you beers until you drown. (sorry for spamming the list) Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/44 ------------------------------------------------------------------------ On 2013-04-10T21:10:40+00:00 Radim Kolář wrote: If SMTP server returns 4XX error on greeting (throttle limit) then Thunderbird still considers mail sent okay and moves it to Sent Mail folder. Its really very annoying bug. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/45 ------------------------------------------------------------------------ On 2013-04-11T04:51:01+00:00 M-wada-7 wrote: As already written in comment #37, one of major causes is intentional RFC 2821 violation at SMTP server side. Such option means that the SMTP server considers "a login failure of ordinal SMTP client due to old password" as an "attack by spammer". Because many ordinal/normal SMTP servers accept From: mail address of other provider, and because Tb's SMTP setting is independent from mail account setting, simplest/easiest available workaround is "use ordinal/normal SMTP server in your daily mail sending", "stop using SMTP server who considers you spammer when old password is used". Gmail SMTP is an such ordinal/normal SMTP server, and Gmail provides free account anyone can use. So, "use Gmail's SMTP" can be a workaround. - Get free Gmail account. - Register your From: mail address as "mail address which can be used to send mail" at Gmail's setting. - Add Gmail's SMTP server to Tb's SMTP server definitios, Select Gmail's SMTP server at each Tb's Identity setting, Or set Gmail's SMTP server as "deafault SMTP" and use "always use defailt (SMTP) server" option for each Identity. - View sent mail copy via Web mail, or enable Gmail IMAP and define Gmail IMAP account in Tb. Note: Yahoo!'s SMTP can not be called "normal/ordinal" in this context even thouh Yahoo! doesn't kill connectin immediately, because Yahoo! forces Yahoo!'s mail address in From:, as seen in commemt #6. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/46 ------------------------------------------------------------------------ On 2013-05-20T15:15:52+00:00 Reese-ml wrote: 1) I can also confirm this bug -- it appears with a timeout or a typo in the password. And as the reversion test indicated, older versions of thunderbird did not have this behavior. 2) re: WADA -- the gmail workaround is fine for people who need a single account, but those of us with multiple accounts who cannot change their account (e.g. a corporate or university account that is for work), the workaround is not a viable solution. This bug hits me almost daily, and is quite annoying (and means I've missed responding to important emails as I have no way of knowing which got sent). In any case, regardless of what value is returned by the SMTP server, Thunderbird clearly knows that it hasn't sent the mail correctly; it gives an error message saying as much. Why not change the logic of 'save to send/maintain open; save to draft' to occur concurrently with the dialog popup of the captured error rather than basing it on an error code that many servers to which many servers clearly do not conform. Thanks for the help! Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/47 ------------------------------------------------------------------------ On 2013-05-21T11:32:06+00:00 M-wada-7 wrote: (In reply to Michael from comment #47) > Why not change the logic of 'save to send/maintain open; > save to draft' to occur concurrently with the dialog popup of the captured > error > rather than basing it on an error code that many servers to which many > servers clearly do not conform. Current behavior of Tb is never by design, as seen in older Tb's behavior. It's different from design, and it's simply a bug of Tb, which is perhaps regression by unknown change. Please note that adding complaints to bug of bugzilla.mozila.org won't help resolving Tb's bug by developer. As I wrote in comment #26, a regresion window in the past is already found. If you want to help developers, please add comment like next, instead of merely adding complaints. (Note: Here is bugzilla.mozilla.org.) - report of duplication test result to know the regression widow written in comment #26 is correct or wrong. - trace data such as Socket log which may help problem analysis by developer. By the way, another workaround is available if this bug is so critical for you. - Send mail via Web mail using Browser. Note: Even if it works well technically, it may be violaton of law in your organization. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/48 ------------------------------------------------------------------------ On 2013-05-21T18:51:31+00:00 Reese-ml wrote: My apologies, I appreciate the hard work of the developers and people trying to chase down any and all bugs. I definitely didn't mean to be merely complaining with nothing positive to add. (In reply to WADA from comment #48) > window in the past is already found. If you want to help developers, please > add comment like next, instead of merely adding complaints. (Note: Here is > bugzilla.mozilla.org.) > - report of duplication test result to know the regression widow > written in comment #26 is correct or wrong. > - trace data such as Socket log which may help problem analysis > by developer. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/49 ------------------------------------------------------------------------ On 2013-05-22T09:37:49+00:00 viric wrote: There is a lot of text about the SMTP server implementation. But this problem happens when the very SMTP server is *unreachable* (as with temporary network problems). Someone mentioned that it happens "if the connection is closed before the error dialog is acknowledgedby the user". This is also the case when the server is *unreachable* (connection refused, ip unreachable, or whose DNS name can't be resolved, etc.). I'm surprised how this hasn't blocked any release from 14 to 17! Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/50 ------------------------------------------------------------------------ On 2013-05-22T10:13:02+00:00 M-wada-7 wrote: (In reply to viric from comment #50) > This is also the case when the server is *unreachable* (connection refused, > ip unreachable, or whose DNS name can't be resolved, etc.). If problem occurs even in first step of connection, step of "DNS name can't be resolved", and if it's consistently reproducible, can you attach NSPR log? See bug 402793 comment #28. Following parameter is perhaps useful for first log check. > Win example : > SET NSPR_LOG_MODULES=timestamp,smtp:5,nsHostResolver:5,,MsgCopyService:5 If timing of "connection failure or loss" is important, add ",nsSocketTransport:5" and check socket level flow, please. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/51 ------------------------------------------------------------------------ On 2013-05-22T16:20:34+00:00 viric wrote: hm I tried to reproduce it in linux, and I couldn't; I've seen the issue in Windows (coworker's computer), and I could reproduce it simply unplugging the ethernet cable and trying to send a letter. By this latter, I wrote as if it were trivial to reproduce. I'll try again tomorrow specifically on the Windows machine, and grab the log if possible. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/52 ------------------------------------------------------------------------ On 2013-05-23T04:51:26+00:00 M-wada-7 wrote: *** Bug 833222 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/53 ------------------------------------------------------------------------ On 2013-05-23T05:21:50+00:00 M-wada-7 wrote: (In reply to viric from comment #50) > I'm surprised how this hasn't blocked any release from 14 to 17! This bug was found in Tb 14 after release of Tb 14 and after released Tb 14 was used by many many users. - We can't withdraw already released Tb 14 without finding cause and solution of this bug. - Even newer release of Tb is shipped with this bug, nothing worse than this bug won't occur in any newer release. As for this bug, it's absolutely same as Tb 14, Tb 15, ..., Tb x which was already released and used for long time. What is reason to block release of Tb(x+1), Tb 1(x+2), ... , Tb (x+n) because of existent of this bug, even though Tb 14 to Tb x was already released and many many users who never experience this bug? What is reason to add such comment to bug of bugzilla.mozilla.org long the way? Do you say "Mozilla messaging company should have released Tb 13 as Tb 15 again due to this bug" and "Mozilla messaging company shouldn't have released newer Tb releases due to this bug"? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/54 ------------------------------------------------------------------------ On 2013-05-23T06:15:16+00:00 M-wada-7 wrote: (In reply to viric from comment #52) > I'll try again tomorrow specifically on the Windows machine, > and grab the log if possible. If you get NSPR log, try following parameter. > SET > NSPR_LOG_MODULES=smtp:5,nsHostResolver:5,MsgCopyService:5,DOMLeak:5,DocumentLeak:5,nsDocShellLeak:5 "Dialog open/close" is also logged by DocumentLeak:5, so "when error dialog is opened and closed" is also seen in log. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/55 ------------------------------------------------------------------------ On 2013-05-23T07:00:16+00:00 M-wada-7 wrote: To Mark Banner who is ownwer of bug 554044: Do you have answer to my question of comment #42? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/56 ------------------------------------------------------------------------ On 2013-05-23T07:25:06+00:00 viric wrote: Created attachment 753133 Reproduced on 17.0.6 windows, disconnecting the ethernet cable I started 17.0.6 with the log flags proposed, went to write a letter, disconnected the ethernet cable, and clicked "Send". After a while trying to connect to the smtp server, an error message appear, the composer window closed, and the message got stored into the Sent folder. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/57 ------------------------------------------------------------------------ On 2013-05-23T07:27:10+00:00 viric wrote: (In reply to WADA from comment #54) Sorry for the confusion; my comment on how this issue wasn't a blocker was based on my experience in Windows, that I could reproduce this issue very easily all the time. I didn't understand that it was any hard to reproduce, then. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/58 ------------------------------------------------------------------------ On 2013-05-23T07:55:17+00:00 M-wada-7 wrote: (In reply to viric from comment #57) > Created attachment 753133 > Reproduced on 17.0.6 windows, disconnecting the ethernet cable Log. > 0[120f140]: SMTP Connecting to: mail.aqsense.com > 9056[120f530]: Resolving host [mail.aqsense.com]. > 9056[120f530]: Using cached record for host [mail.aqsense.com]. > 9056[120f530]: Checking blacklist for host [mail.aqsense.com], host record > [e1acbf0]. > 0[120f140]: SMTP entering state: 0 > 0[120f140]: SMTP Response: 421 Cannot connect to SMTP server 212.49.179.72 > (212.49.179.72:25), NB connect error 1460 > 0[120f140]: SMTP entering state: 14 > 0[120f140]: SMTP Send: QUIT > 0[120f140]: SMTP entering state: 0 > 0[120f140]: request 4b51940 DoCopy - src dest > mailbox://rpa...@mail.aqsense.com/Sent numItems 0 type=1 > 0[120f140]: NotifyCompletion - src dest > mailbox://rpa...@mail.aqsense.com/Sent > 0[120f140]: request 4b51940 Clearing OK request - src dest > mailbox://rpa...@mail.aqsense.com/Sent numItems 0 type=1 For Tb, following Greeting is returned from "your SMTP server, mail.aqsense.com, 212.49.179.72:25), after normal connection establishment with your SMTP server. SMTP Response: 421 Cannot connect to SMTP server This case is already reported by comment #45. Do you use proxy server for SMTP? (In reply to viric from comment #58) > I didn't understand that it was any hard to reproduce, then. As known by commeny #6, reproducing of "error response to SMTP command" case is pretty easy, because Yahoo! IMAP always rejects From: mail address other than Yahoo!'s one. However, "4XX error on greeting" case is hard to reproduce in ordinal environment. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/59 ------------------------------------------------------------------------ On 2013-05-23T08:26:51+00:00 viric wrote: (In reply to WADA from comment #59) > Do you use proxy server for SMTP? No, I don't. But I understood your suspicion, and dig into this thing; I suspected it could be the fancy antivirus. We are using Avast here. After tweaking all options, I tracked down this to the options "Anti-SPAM" and "Mail protection: Check SMTP connections". If I disable both (one of them is not enough), thunderbird behaves normally. So, here Avast (and maybe other AVs) get into the SMTP connection causing this behaviour. No wonder that I couldn't reproduce this in Linux. :) Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/60 ------------------------------------------------------------------------ On 2013-05-23T09:45:30+00:00 M-wada-7 wrote: Because no timestamp in your log, it's hard to know "time between events". However, because "44x error response greeting" case, it's simplest case. It looks next. See following for SMTP state in log, and Tb's action when a SMTP states. > http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsSmtpProtocol.h#21 > > http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsSmtpProtocol.cpp#1861 (1) Greeting is error response. Because similar to "too many connections" or "server too busy", server uually kills connection immediately after this kind of response. In your case, because Avast! is used, Avast! perhaps acts as if SMTP proxy to do virus check of outgoing message. Because actual server connection is impossible, "connection with SMTP server for Tb" is lost just after this response. > 0[120f140]: SMTP Response: 421 Cannot connect to SMTP server 212.49.179.72 > (212.49.179.72:25), NB connect error 1460 (2) Tb goes to 14 = SMTP_EXTN_LOGIN_RESPONSE (same as login failure) > 0[120f140]: SMTP entering state: 14 (3) Because it's not "actual login failure", error dialog is simply shown. > 0[120f140]: DOCUMENT 4b48800 created > 0[120f140]: DOCUMENT 4b48800 ResetToURI about:blank > 0[120f140]: DOCUMENT 6048800 created (4) By OK reply, error dialog is closed. > 0[120f140]: DOCUMENT 4b48800 destroyed (5) As a step of "state: 14", "send of QUIT" is reuested, and waits for response to QUIT. > 0[120f140]: SMTP Send: QUIT > 0[120f140]: SMTP entering state: 0 (5) However, connection is already lost, so "response to QUIT from server" never occurs. And, SMTP_PAUSE_FOR_READ perhaps terminates because connection is already lost. (6) Because it's not expecting "Error in SMTP send process => QUIT => OK to QUIT => End of SMTP process" status, Tb wrongly considers "Normal end of SMTP send". Then "Save in Sent" is invoked, and composition windw is closed. > 0[120f140]: request 4b51940 DoCopy - src dest > mailbox://rpa...@mail.aqsense.com/Sent numItems 0 type=1 > 0[120f140]: NotifyCompletion - src dest > mailbox://rpa...@mail.aqsense.com/Sent > 0[120f140]: request 4b51940 Clearing OK request - src dest > mailbox://rpa...@mail.aqsense.com/Sent numItems 0 type=1 We now know an prety easy way to reproduce "4XX error on greeting" case in prety ordinal environment : Simply utilize "Outgoing mail scanner" of anti-virus software such as Avast!, and inrtefere virus scanner's SMTP server connection. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/61 ------------------------------------------------------------------------ On 2013-05-23T11:33:13+00:00 Westburne04 wrote: Comment 61 accords with my experience I use Avast Sending progress bar on for prolonged time. When it closes message goes to sent folder and error message shows for a short time. If sending cancelled before the progress bar closes there is no problem. Problem happens different times with different servers but only when I am in a location with a less reliable internet connection. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/62 ------------------------------------------------------------------------ On 2013-06-09T22:22:43+00:00 M-wada-7 wrote: *** Bug 831936 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/63 ------------------------------------------------------------------------ On 2013-06-10T19:39:32+00:00 Standard8 wrote: (In reply to WADA from comment #42) > Is default of aNextStateAfterResponse SMTP_DONE? Yes, see the .h change in attachment 607175 > Is this relevant to this bug's problem? Without in-depth re-investigation to get all the context back in my head, I can't say. It is conceivable that it could be. Trying a build from before then may help if you're looking for a regression range. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/64 ------------------------------------------------------------------------ On 2013-07-08T05:08:03+00:00 M-wada-7 wrote: *** Bug 890281 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/65 ------------------------------------------------------------------------ On 2013-07-08T05:55:07+00:00 M-wada-7 wrote: (In reply to Mark Banner (:standard8) from comment #64) > Trying a build from before then may help if you're looking for a regression > range. See comment #26 for regression window, please. Do you see other change than bug 554044 which may be relevant to this bug in check-ins during the regression window? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/66 ------------------------------------------------------------------------ On 2013-07-23T05:35:12+00:00 Rvanderplas wrote: NOT using Avast and still having the same problem, for almost a year now. With good or poor internet connection there is no difference. Irregularly the message fails to send but ends up in the sent box anyhow. Using System Mechanic Professional System Shield. The only way to make sure that the message actually was sent is to keep watching the screen when the SEND button is pressed. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/67 ------------------------------------------------------------------------ On 2013-07-23T06:26:20+00:00 Peter-ashford-l wrote: I always BCC my emails to myself now. If they come back to me I know that sending actually succeeded. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/68 ------------------------------------------------------------------------ On 2013-07-23T08:50:07+00:00 M-wada-7 wrote: Workarounds of this bug: (a) If you experienced this bug, do Comment #68 : BCC: to yourself always. (b) If you experienced this bug with a SMTP server several times, never use unreliable mailer named Thunderbird with the problematic SMTP server. (b-1) Use other reliable mailer when you mail send. There is no need to use unreliable mailer in your mail send. (b-2) Use other SMTP server for used Identity(From: address), if and only if mail send using Tb is mandatory for you. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/69 ------------------------------------------------------------------------ On 2013-08-27T00:10:28+00:00 M-wada-7 wrote: *** Bug 909438 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/74 ------------------------------------------------------------------------ On 2013-09-27T07:55:52+00:00 viric wrote: WADA, I'm not sure I understood your comments in #61. You write "error dialog is simply shown", and "By OK reply, error dialog is closed". In my situation, there is no visible error dialog, or any user clicking an OK button. Thunderbird shows the SMTP sending dialog (with a bar), and then it disappears and the outgoing letter goes to the Sent folder. From the user, there is no difference from a properly sent letter. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/75 ------------------------------------------------------------------------ On 2013-09-27T08:55:14+00:00 viric wrote: I would like to understand the status of the issue. Specifically: - Is there any developer considering that the bug exists in Thunderbird and should be fixed? - Is there any developer working on it? - What is required next, to get a fix? - In my opinion, the bug exists, it has very important consequences: the SMTP conversation clearly ended in *will not send the letter*, and thunderbird tells the user *letter sent*. Solutions of the kind "fix your server" do not look any appropiate. WADA solutions of "use BCC" or "stop using thunderbird" look to me either as temporary solutions, or jokes. But it's broken since TB 10 or 14, so I think I don't understand how to proceed next to help in the solution. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/76 ------------------------------------------------------------------------ On 2013-09-27T11:04:07+00:00 M-wada-7 wrote: (In reply to viric from comment #71) > WADA, I'm not sure I understood your comments in #61. > You write "error dialog is simply shown", and "By OK reply, error dialog is > closed". In my situation, there is no visible error dialog, or any user > clicking an OK button. It depends on "at which step error is returned" and "when SMTP server closes conection after error response to Tb. Please read SMTP log in comments in #6 well. Because Yahoo! SMTP server doesn't kill connection immediately after "SMTP Response: 553 From address not verified", dialog of "SMTP send error" is normally shown as expected. If dialog is closed within short period, Tb coorectly process send error, and composition window is kept open due to SMTP send error(this is coment #5). Comment #6 is to reproduce this bug. If dialog of "SMTP send error" is keopt open for long time, Yahoo! SMTP server or Tb closes connection. If connection is lost while dialog of "SMTP send error" is kept open, this bug is reprduced. If SMTP server closes connection immediately after "error response like 553" or "4xx greeting", "SMTP send error dialog" is perhaps not shown by Tb. Have you gotton NSPR log with timestamp,smtp:5,MsgCopyService:5 and checked log content by Text Editor? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/77 ------------------------------------------------------------------------ On 2013-09-27T15:09:54+00:00 viric wrote: I think that the other end of tcp closes the connection just after giving a "4xx greeting". I imagine that's how the antivirus proxy notifies the failing connection. I'll have access to the machine of the user with Avast next week, for the log. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/78 ------------------------------------------------------------------------ On 2013-09-30T13:16:25+00:00 viric wrote: Created attachment 812010 The logs with the issue, with timestamp I finally could reproduce the issue; I had to reenable the SNMP check in Avast, and reboot the Windows OS to get it effective. Avast didn't tell me that it wasn't effective, but I saw that the analysis counter didn't increase. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/79 ------------------------------------------------------------------------ On 2013-09-30T13:24:01+00:00 Rob-smeets wrote: For those with difficulty reproducing this with antivirus proxies, I think it's rather easier to reproduce when you're at an ISP which doesn't allow sending from different e-mail addresses. Here in Belgium, there's Belgacom Skynet (the biggest ISP) who gives such an error message when you try to send using the smtp server of another service provider (we have to use relay.skynet.be and the bug happens if we use, e.g., smtp.telenet.be) Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/80 ------------------------------------------------------------------------ On 2013-10-01T07:23:42+00:00 viric wrote: Oops, now I see that I wrote SNMP where I meant SMTP, in #75. Notice that the attachment has two letter sends: one succesful, and at the end, one unsuccesful. No dialog appears telling about any error; the sending bar dialog simply stays for a while, until it disappears and the letter goes to the Sent box, as if all was successful. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/81 ------------------------------------------------------------------------ On 2013-11-20T09:31:30+00:00 viric wrote: Is there anything else I can do to help solve this issue? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/82 ------------------------------------------------------------------------ On 2013-11-20T16:52:58+00:00 Irving-o wrote: The most valuable next step for this bug would be if someone can build a Mozmill test case (https://developer.mozilla.org/en- US/docs/Mozilla/Thunderbird/Thunderbird_MozMill_Testing) that uses the SMTP fake server (https://developer.mozilla.org/en- US/docs/MailNews_fakeserver) to reproduce the bug. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/83 ------------------------------------------------------------------------ On 2013-11-27T00:21:28+00:00 M-wada-7 wrote: *** Bug 943280 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/84 ------------------------------------------------------------------------ On 2014-04-29T09:38:06+00:00 M-wada-7 wrote: (In reply to :Irving Reid from comment #79) > The most valuable next step for this bug would be if someone can build a > Mozmill test case As written in comment #6, this bug is 100% reproducible with pretty simple test procedure, with pretty popular Yahoo! SMTP server. i.e. Any developer can see this bug by his hand. "Mozmill test case" is step after code analysys/patch implementation, isn't it? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/85 ------------------------------------------------------------------------ On 2014-09-08T13:40:06+00:00 Davidbrito wrote: Hello, Version 31.1.0 and still that problem. Send e-mail, get 421 smtp message to many concurrent... e-mail not sent and moved to sent folder. Any news??? thanks David Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/86 ------------------------------------------------------------------------ On 2014-09-29T19:30:57+00:00 M-wada-7 wrote: *** Bug 1074243 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/87 ------------------------------------------------------------------------ On 2015-02-16T14:42:33+00:00 Rob-smeets wrote: Still exists in version 31.4.0 Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/88 ------------------------------------------------------------------------ On 2015-04-09T16:43:02+00:00 dkg wrote: Still seeing this error in icedove (debian's unbranded version of thunderbird) version 36.0~b1-2. log info (gathered with `NSPR_LOG_MODULES=smtp:5,timestamp`): > 2015-04-09 16:23:41.422817 UTC - -313727168[7f53ec0445c0]: SMTP entering > state: 16 > 2015-04-09 16:23:41.422848 UTC - -313727168[7f53ec0445c0]: SMTP > AuthLoginStep1() for redac...@redacted.org@P½êS > 2015-04-09 16:23:41.422873 UTC - -313727168[7f53ec0445c0]: LOGIN auth > 2015-04-09 16:23:41.422888 UTC - -313727168[7f53ec0445c0]: Logging suppressed > for this command (it probably contained authentication information) > 2015-04-09 16:23:41.477716 UTC - -313727168[7f53ec0445c0]: SMTP entering > state: 0 > 2015-04-09 16:23:41.477770 UTC - -313727168[7f53ec0445c0]: SMTP Response: 334 > UGFzc3dvcmQ6 > 2015-04-09 16:23:41.477799 UTC - -313727168[7f53ec0445c0]: SMTP entering > state: 18 > 2015-04-09 16:23:41.477815 UTC - -313727168[7f53ec0445c0]: SMTP Login > response, code 334 > 2015-04-09 16:23:41.477828 UTC - -313727168[7f53ec0445c0]: SMTP entering > state: 17 > 2015-04-09 16:23:41.477844 UTC - -313727168[7f53ec0445c0]: SMTP AuthLoginStep2 > 2015-04-09 16:23:41.477855 UTC - -313727168[7f53ec0445c0]: PLAIN/LOGIN auth, > step 2 > 2015-04-09 16:23:41.477871 UTC - -313727168[7f53ec0445c0]: Logging suppressed > for this command (it probably contained authentication information) > 2015-04-09 16:23:42.385595 UTC - -313727168[7f53ec0445c0]: SMTP entering > state: 0 > 2015-04-09 16:23:42.385641 UTC - -313727168[7f53ec0445c0]: SMTP Response: 421 > 4.3.2 Service not active > 2015-04-09 16:23:42.385662 UTC - -313727168[7f53ec0445c0]: SMTP entering > state: 18 > 2015-04-09 16:23:42.385670 UTC - -313727168[7f53ec0445c0]: SMTP Login > response, code 421 > 2015-04-09 16:23:42.385678 UTC - -313727168[7f53ec0445c0]: marking auth > method 0x100 failed > 2015-04-09 16:23:42.385685 UTC - -313727168[7f53ec0445c0]: SMTP auth: server > caps 0x10114, pref 0x300, failed 0x100, avail caps 0x0 > 2015-04-09 16:23:42.385693 UTC - -313727168[7f53ec0445c0]: (GSSAPI = 0x800, > CRAM = 0x2000, NTLM = 0x4000, MSN = 0x8000, PLAIN = 0x200, LOGIN = 0x100, > EXTERNAL = 0x400) > 2015-04-09 16:23:42.385701 UTC - -313727168[7f53ec0445c0]: no auth method > remaining > 2015-04-09 16:23:42.385707 UTC - -313727168[7f53ec0445c0]: SMTP: ask user > what to do (after login failed): new password, retry or cancel > 2015-04-09 16:25:20.023784 UTC - -313727168[7f53ec0445c0]: cancel button > pressed > 2015-04-09 16:25:20.023821 UTC - -313727168[7f53ec0445c0]: SMTP Send: QUIT > 2015-04-09 16:25:20.023839 UTC - -313727168[7f53ec0445c0]: SMTP entering > state: 0 After i press the "cancel" button, the mail composition window disappears, and the message gets placed in the Sent mail folder. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/89 ------------------------------------------------------------------------ On 2015-04-09T18:06:46+00:00 dkg wrote: I note that the server's response of "421 4.3.2 Service not active", according to https://tools.ietf.org/html/rfc3463 is: * 4.XXX.XXX Persistent Transient Failure * X.3.XXX Mail System Status * X.3.2 System not accepting network messages The host on which the mailbox is resident is not accepting messages. Examples of such conditions include an immanent shutdown, excessive load, or system maintenance. This is useful for both permanent and persistent transient errors. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/90 ------------------------------------------------------------------------ On 2015-04-22T11:24:53+00:00 Bugzilla-mozilla-org-u wrote: Confirming the existence of this issue on Thunderbird 31.5.0 (Linux). This issue has been irking me for years! The two situations I see it in is when my SMTP server (exim) returns a 4xx due to excessive load or excessive SMTP connections. TB shows the server's error message, but files the message as sent and closes the message window. I've also seen other uses of TB who had this, and assumed that their message was sent (because of it being filed in the 'sent' folder), and who have then asked me why their email didn't arrive at its destination. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/91 ------------------------------------------------------------------------ On 2015-04-22T12:31:27+00:00 viric wrote: After more than one year waiting for a fix, we moved the Windows users of the office to Outlook because of this bug. It caused too many troubles in the office to be acceptable. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/92 ------------------------------------------------------------------------ On 2015-04-22T12:54:40+00:00 Vseerror wrote: It seems like there is plenty of data here that this could be fixed by someone (comment 42, comment 46, etc). wada, my reading of the comments is the cause is bug 554044. If this is incorrect please give us an update. THanks. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/93 ------------------------------------------------------------------------ On 2015-04-22T12:55:45+00:00 Rob-smeets wrote: I also don't understand why the status of this bug is still 'New'. I reported this 3 years ago. I know, we should solve it ourselves if we're so bugged by it, but I can't do it. If I could I would have. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/94 ------------------------------------------------------------------------ On 2015-05-27T13:24:29+00:00 Vseerror wrote: *** Bug 1067180 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/95 ------------------------------------------------------------------------ On 2015-09-25T12:46:52+00:00 Ludovic-mozilla wrote: Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/96 ------------------------------------------------------------------------ On 2015-10-23T18:28:57+00:00 Mkmelin+mozilla wrote: (In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #89) > It seems like there is plenty of data here that this could be fixed by > someone (comment 42, comment 46, etc). Hard to say, but that would seem like a good place to start debugging. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/97 ------------------------------------------------------------------------ On 2015-10-25T11:06:01+00:00 Vseerror wrote: Daniel, thanks for that great info. Rob, Daniel, ..., do you agree with comment 26 (please test)? p.s. (Rob) I know you are trying to be helpful, but no need to be posting in the bug that the problem still exists - the bug is open, so it is obvious the problem continues, and everyone knows, so these comments do not add value Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/98 ------------------------------------------------------------------------ On 2015-10-25T12:26:26+00:00 Rob-smeets wrote: Hi, - I won't 'bump' anymore, sorry 'bout that. - is it possible to install nightly builds without affecting the main install? Otherwise I'll have to find another pc to install the nightlies on. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/99 ------------------------------------------------------------------------ On 2015-10-25T13:12:23+00:00 Vseerror wrote: https://support.mozilla.org/en-US/kb/using-multiple-profiles describes how to set up additional profiles. Safest approach I think is to set up a test pop account on the same zimbra server. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/100 ------------------------------------------------------------------------ On 2015-10-25T13:20:54+00:00 Rob-smeets wrote: Hi Wayne, Comment 26 is the one about the regression window. Testing that will require me to have several nightlies installed, so I asked how to do that without getting into trouble with my own installation. I know how to reproduce the issue, but I'm leery about installing multiple instances of thunderbird together on my (productive) pc. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/101 ------------------------------------------------------------------------ On 2015-10-25T13:27:19+00:00 Vseerror wrote: You will want to create a test pop account. Then, using your current version of Thunderbird create a new test profile to use that test pop account. Next, install the builds mentioned in comment 26 one at a time, and using the TEST PROFILE and attempt to reproduce the problem. After testing is done, reinstall Thunderbird release from http://getthunderbird.com/ and return to your production profile. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/102 ------------------------------------------------------------------------ On 2015-10-25T17:01:33+00:00 Reuben Thomas wrote: Thanks for the User Story update. Could someone edit it for language? I find the English pretty hard to follow at present. Also, the Workaround only works for one particular error (relaying denied). There are other possible causes of this bug in which there's nothing wrong with the SMTP server. Perhaps this could be clarified? Thanks again to all those working to fix this problem. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/103 ------------------------------------------------------------------------ On 2015-10-25T17:04:32+00:00 M-wada-7 wrote: (In reply to Reuben Thomas from comment #99) > Could someone edit it for language? Ask it to Wayne, please. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/104 ------------------------------------------------------------------------ On 2015-10-25T17:19:02+00:00 Vseerror wrote: I don't see great room for improvement in terms of language - just many technical aspects listed. If there is something specific you don't understand please point it and describe what is difficult. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/105 ------------------------------------------------------------------------ On 2015-10-25T17:29:14+00:00 Reuben Thomas wrote: I think the best way is to show by example. Here's a rewritten version, according to my best understanding of the current version. I added some notes in square brackets where something seems to be missing. The phenomenon itself is already analyzed and well understood, so additional reports or logs are not needed. What is needed is data [what sort of data?] to create a correct patch for this bug, or such a patch. Regression window: See comment #26 Possibly relevant change : bug 554044 The problem may not be in the code that was changed; the changes may have merely exposed a problem elsewhere. Workaround ["for users who are getting errors about relaying"; perhaps specify the exact codes?]: It may be that your ISP's SMTP server refuses From: addresses other than those of your ISP. This contravenes RFC [add number], so use an RFC-compliant SMTP server. (Thunderbird allows any SMTP server to be used by any identity.) 1. Set "Outgoing (SMTP) server" [preferably give the full route to this preference] to an RFC-compliant SMTP server, and set it as "Default SMTP server". 2. In the settings for the Identity which is having problems, choose "use default SMTP server". Caveats: 1. Not all SMTP servers accept any From: address. Example: Yahoo! [Is there some way a user can tell whether an SMTP server will relay?] 2. Some servers require additional set-up to relay. For example, Gmail requires registration of addresses from which you want to send. 3. Some receiving servers may reject relayed mail the domain of whose From: address does not match the domain of the sending SMTP server. If you cannot get a different SMTP server to work, and this bug is critical for you, you should consider using a different mail client. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/106 ------------------------------------------------------------------------ On 2015-10-25T17:35:48+00:00 M-wada-7 wrote: (In reply to Reuben Thomas from comment #99) > Also, the Workaround only works for one particular error (relaying denied). > There are other possible causes of this bug in which there's nothing wrong > with the SMTP server. > Perhaps this could be clarified? "Relaying denied" by whom? Error code from who/when? Once all mail data is transfered to SMTP server and OK response(250) is returned from SMTP server, email client can do nothing. All is up to SMTP server. This bug is for "any error from greeting by SMTP server to just before OK response from SMTP server", as easily known by already reported phenomena and SMTP logs in this bug. And, cause of this bug is "connection loss after the error", instead of "the error itself", as easily known by already reported phenomena and SMTP logs in this bug. So, error code itself is absolutely irrerevant to problem of this bug. "Good SMTP server" in this context means "SMTP server who doesn't close connection after he returns error code, as defined by RFC". "4xx in bug summary" is too misleading for you? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/107 ------------------------------------------------------------------------ On 2015-10-25T17:46:10+00:00 M-wada-7 wrote: [Off-Topic] (In reply to Reuben Thomas from comment #102) "Caveats" is too techinical for general users and non-English speakers like me. So, I want to reject it :-) By the way, this bug is mystery for any user, and is pretty annoying for almost all users as known by many dup'ed bugs and many reports in QA forum etc. But I can do nothing, because I don't know Tb's SMTP code well... Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/108 ------------------------------------------------------------------------ On 2015-10-25T17:53:42+00:00 M-wada-7 wrote: [Off-Topic] > If you cannot get a different SMTP server to work, (snip) Anyone can get free account of Gmail and use Gmail's SMTP server at any place except some places or some countries. And, if corporate environment, "SMTP server who violates RFC" should be corrected first usually. Therefore, this is rejected by me :-) . Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/109 ------------------------------------------------------------------------ On 2015-10-26T14:40:47+00:00 M-wada-7 wrote: (In reply to Reuben Thomas from comment #102) > Workaround > It may be that your ISP's SMTP server refuses From: addresses other than > those of your ISP. > This contravenes RFC, so use an RFC-compliant SMTP server. This is never RFC violation by SMTP server such as SMTP server of Yahoo!. This is based on Spam Policy of Yahoo!. Gmail has different Spam Policy. If From: address other than Gmail' mail addr which is assigned to the used UserID of Gmail account, Gmail replaces mail address in From: by "mail addr which is assigned to the used UserID of Gmail account". This is design of Gmail. If you want to use other than "mail addr which is assigned to the used UserID of Gmail account" in From:, you need to register it to Gmail as "mail address which can be used as From:". This is same on "mail addr which is assigned to UserID of other Gmail account". In this case, Gmail doesn't alter From:, and adds "Sender: Gmail's mail addr" or something to mail. This is also design of Gmail. "Relaying denied" is also based on Spam Policy of ISP. Please avoid selfish interpretation. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/110 ------------------------------------------------------------------------ On 2015-10-26T14:45:35+00:00 Reuben Thomas wrote: I did not make a "selfish interpretation", I merely tried to make the original user story easier to understand. This sort of issue is precisely why I asked for clarification in the first place; it would have been better done by someone who understands the issues better, but since no-one offered, I volunteered. Clearly, there is room for further improvement; I hope that will be made. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/111 ------------------------------------------------------------------------ On 2015-10-26T15:00:12+00:00 M-wada-7 wrote: (Off-Topic) (In reply to Reuben Thomas from comment #107) > I volunteered. Clearly, there is room for further improvement; I hope that > will be made I'm also a volunteer. Because "User Story" was not used by bug opener, I merely wrote a quick summary to User Story for bug reader's convenience, with incorrect description as less as possible. "User Story" can be replaced if comment poster can change a field of this bug such as bug summary. Please freely update "User Story" for bug readers, not for you, as far as your description is correct. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/112 ------------------------------------------------------------------------ On 2015-10-26T15:03:27+00:00 viric wrote: There are plenty of ISP servers available, all with their peculiarities. The issue is very clear: the server answers with an error code (4XX, permanent error, it doesn't matter which one), and Thunderbird considers it "OK,Sent". The suggestion regarding change of From address is just to help some people reproduce one of such sending errors. Another way is to use Avast (MITM-antivirus for SMTP), and set up a connection to a non-working SNMP server. Avast will translate the connection error to a SMTP 4XX error that Thunderbird will consider as "OK,Sent". Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/113 ------------------------------------------------------------------------ On 2015-10-26T15:04:44+00:00 Reuben Thomas wrote: (In reply to WADA from comment #108) I've already updated the story to the best of my understanding. I don't understand what it means to update it "for bug readers, not for you, as far as your description is correct". I did not try to correct the story you wrote, merely make it easier to understand. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/114 ------------------------------------------------------------------------ On 2015-10-26T15:08:09+00:00 Reuben Thomas wrote: (In reply to viric from comment #109) > The suggestion regarding change of From address is just to help some people > reproduce one of such sending errors. I'm not sure what suggestion you are referring to. The user story suggests changing one's SMTP server, not one's From: address. Again, if someone with a better technical grasp of the situation could update the user story, that would be very helpful. (My perspective is one of trying to advise users who encounter this problem what they should do.) Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/115 ------------------------------------------------------------------------ On 2015-10-26T15:38:26+00:00 M-wada-7 wrote: (In reply to Reuben Thomas from comment #111) > > The suggestion regarding change of From address is just to help some people > > reproduce one of such sending errors. It's because "change From:" is not essentially workaround of this bug. It may be a workaroud of issue like "Relaying Denied" if From; is cause of the "Replayng denied". Workaround of "Relaying denied" may be "use SMTP-AUTH(login with userID/password)" instead of "SMTP send without login" in some environment or situations. If such error is not returned from SMTP server, this bug doesn't occur. In cntrast to it, error code such as "server is temporaary unavailable" can not be avoided. (Off-Topic) Update of User Story" for "better expression for bug readers" by you is wellcome, because User Story in this bug is for bug reder's convenience(bug opener didn't use it). Rejecttion of "Caveats" is a kind of joke. Please see "History" of this bug before your update of "User Story". Because User Story is a field of a bug(similar to bug summary), if big change is done frequently, History is fiiled by log for User Story update. Log for User Story update seems diff. So, small change is safe. Please avoid frequent modification of entire User Story. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/116 ------------------------------------------------------------------------ On 2015-10-26T16:44:12+00:00 viric wrote: Ah I see. I don't understand much from the User Story, neither how it is related to this bug. Along the comments there are different "user stories" that trigger server errors as the title of the bug says. The bug is so wide (interpreting any server error as OK) that it spans many "user stories". In my situation, it was having the Avast antivirus installed that triggered all the problems. The bug is one and clear, and so it says the 1st line of the User Story: server errors should be interpreted as errors in Thunderbird, and never consider a letter sent if the server said that it has not been sent. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/117 ------------------------------------------------------------------------ On 2015-10-26T17:03:36+00:00 M-wada-7 wrote: (In reply to viric from comment #113) > In my situation, it was having the Avast antivirus installed that triggered > all the problems. Avast! case is best for problem analysis because Avast! immeditely closes connection. Can you create debug build for analysis? (e.g. hook at many places which can berelevant to issue, and put trace log) Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/118 ------------------------------------------------------------------------ On 2015-10-27T16:11:29+00:00 Rob-smeets wrote: On thursday I'll be again at a customer where I can test this (most ISP's time out if there's a non permitted mail server, but I remember getting the error at customers which use Skynet). By the way, I no longer experience this issue because all my ISPs now allow encrypted and password authenticated smtp sending (and I experienced this bug only because I was constantly switching between default smtp servers and when I forgot switching, I lost my mail) Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/119 ------------------------------------------------------------------------ On 2015-10-27T17:35:45+00:00 dkg wrote: I'm sorry, the SMTP server i had this problem on is no longer exhibiting the 4.3.2 response (there was a bug on their end), so i'm not able to test this easily. I could test it if someone is willing to set up an SMTP server that always returns 4.3.2 responses to mail submission and let me know where it is, but i don't have the bandwidth to set that server up myself. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/120 ------------------------------------------------------------------------ On 2015-10-27T17:39:57+00:00 dkg wrote: fwiw, the current user story seems to imply that this is only a problem with certain SMTP servers that are deliberately configured to reject mail. while that's true, the scenario i ran into the problem with was a server that was one that was seeing what it perceived as a "persistent transient failure" -- so it was declining traffic intermittently. So the issue is not just an issue for people with (arguably) misconfigured thunderbird instances -- it's a problem for any thunderbird instance that talks to any SMTP server that may occasionally fail in this way. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/121 ------------------------------------------------------------------------ On 2015-10-29T09:49:11+00:00 Rob-smeets wrote: (In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #94) > Daniel, thanks for that great info. > > Rob, Daniel, ..., do you agree with comment 26 (please test)? Hi all, I'll attach my test report. Suffice it to say that YES, I've found WADA's comment 26 to be correct and the bug was first there in the version from march 20. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/122 ------------------------------------------------------------------------ On 2015-10-29T09:51:28+00:00 Rob-smeets wrote: Created attachment 8680540 Thunderbird Bug 780124.pdf The test report requested in comment 94 Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/123 ------------------------------------------------------------------------ On 2015-10-29T15:04:29+00:00 M-wada-7 wrote: (In reply to Rob from comment #118) > I've found WADA's comment 26 to be correct (snip) Does it mean that you were distrustful about my comment #26 until you did duplication test :-) Thanks for your dupliction test. As known by comment #26, I did mistake in cooment #21. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/124 ------------------------------------------------------------------------ On 2015-10-29T15:09:07+00:00 Rob-smeets wrote: (In reply to WADA from comment #120) > (In reply to Rob from comment #118) > > I've found WADA's comment 26 to be correct (snip) > > Does it mean that you were distrustful about my comment #26 until you did > duplication test :-) > Thanks for your dupliction test. As known by comment #26, I did mistake in > cooment #21. *points at Wayne Mery* *points at comment 94* *winks suggestively* Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/125 ------------------------------------------------------------------------ On 2015-10-29T15:17:34+00:00 M-wada-7 wrote: (Off-Topic) Oh, who were distrustful of it was Wayne :-) Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/126 ------------------------------------------------------------------------ On 2015-10-29T15:42:06+00:00 M-wada-7 wrote: By the way, it looks for me; - Before some changes : Ｗhen QUIT was issued due to error while Tb tries to send mail data to SMTP server, Tb went to "send QUIT step" again with keeping "error staus", in case of that some error occurs while sending QUIT after original error. This can be a Quirks for bypassing hard-to-resolve problem. - After some changes : According to some comments arround change which was done in the regression window, it seems for me that a reason why such change was made is to resolve "QUIT loop" problem, which may be caused by the Quirks. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/127 ------------------------------------------------------------------------ On 2015-10-29T15:51:14+00:00 M-wada-7 wrote: Without co-operation of who did changes around SMTP code during the regression window, I can say/do nothing. But ... Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/128 ------------------------------------------------------------------------ On 2016-10-17T22:42:24+00:00 Alex Henrie wrote: I'm having the same problem. The SMTP server at my work only works when I'm at work or connected through a VPN. When I am not on the right network, the server refuses to accept any outgoing mail. Thunderbird displays an error message, but copies the unsent message to the Sent folder anyway. I poked around and discovered that this is what's happening: 1. Thunderbird connects to smtp.umail.utah.edu. 2. Before Thunderbird sends anything, the server sends "554 ipo4smtp.cc.utah.edu". 3. nsSmtpProtocol::ExtensionLoginResponse sees the error and alerts the user "An error occurred while sending mail: The mail server sent an incorrect greeting: ipo0smtp.cc.utah.edu." 4. nsSmtpProtocol::ProcessProtocolState sees the error, sends "QUIT", and queues the SMTP_ERROR_DONE state. 5. The server hangs up without acknowledging the QUIT. 6. nsSmtpProtocol::OnStopRequest stops the SMTP state machine without ever running nsSmtpProtocol::ProcessProtocolState in the SMTP_ERROR_DONE state. 7. Thunderbird thinks the message was sent and copies it to the Sent folder. This is very similar to bug 200647. The server (which is a Microsoft SMTP Server) is transgressing RFC 5321 section 3.1, but for the sake of the user, Thunderbird should gracefully handle the abrupt hangup. I agree with WADA that https://hg.mozilla.org/comm- central/rev/6a883737262a from bug 554044 is to blame. That revision set m_sendDone to true in step 4. Previously m_sendDone was false if there was an error, which triggered the error handling code for bug 200647 in step 6. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/129 ------------------------------------------------------------------------ On 2016-10-17T22:44:27+00:00 Alex Henrie wrote: Created attachment 8801912 [PATCH] Gracefully handle SMTP servers that send a bad greeting and hang up. This patch fixes the problem. It was really hard for me to wrap my head around this code, so feedback is appreciated. Right now m_sendDone == m_nextStateAfterResponse == SMTP_DONE || m_nextStateAfterResponse == SMTP_ERROR_DONE, and I decided to not change that. Keeping the existing m_sendDone semantics allowed me to fix (without duplicating code) the related case where there is a network failure (not a clean hangup) while sending QUIT after an error. Instead of showing a second error dialog for NS_ERROR_NET_INTERRUPT like in old versions of Thunderbird, I chose to set NS_ERROR_BUT_DONT_SHOW_ALERT because one error dialog is enough, and the NS_ERROR_NET_INTERRUPT dialog was not helpful: "The message could not be sent because the connection to Outgoing server (SMTP) smtp.umail.utah.edu was lost in the middle of the transaction. Try again." Users will still get an NS_ERROR_NET_INTERRUPT dialog as long as the interruption didn't happen while trying to gracefully shut down after a previous error. https://treeherder.mozilla.org/#/jobs?repo=try-comm- central&revision=bf65cbeb6018 Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/130 ------------------------------------------------------------------------ On 2016-10-19T18:02:38+00:00 Rkent-3 wrote: Comment on attachment 8801912 [PATCH] Gracefully handle SMTP servers that send a bad greeting and hang up. If Magnus does not get to this, I'll look at it. It would be great to get this fixed. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/131 ------------------------------------------------------------------------ On 2016-10-26T23:09:20+00:00 Rkent-3 wrote: Comment on attachment 8801912 [PATCH] Gracefully handle SMTP servers that send a bad greeting and hang up. I spent a few hours looking at this today, getting to the point where I could also reproduce and view the problem and proposed solution. So I'll do the review of this. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/132 ------------------------------------------------------------------------ On 2016-10-27T08:02:51+00:00 Rkent-3 wrote: Created attachment 8805031 Don't claim we are done when we failed Here's my recommendation. When I looked at this, I asked myself "Why are we relying on complex tests of protocol state to see if we succeeded? There should be a variable that makes it clear!" Well actually there is such a variable, but it is set to succeeded in QUIT when QUIT is also used to close the connection after a failure. This patch just moves the test to the points where we know that we succeeded. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/133 ------------------------------------------------------------------------ On 2016-10-27T20:01:06+00:00 Alex Henrie wrote: Comment on attachment 8805031 Don't claim we are done when we failed Review of attachment 8805031: ----------------------------------------------------------------- Hi Kent, thanks for looking into this. If we are going to change the semantics of m_sendDone, it would be better to pass an aSendDone parameter to SendQuit and set m_nextStateAfterResponse based on aSendDone. However, there is still the problem of popping up 2 dialogs when only 1 of them has useful information. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/134 ------------------------------------------------------------------------ On 2016-10-28T08:29:15+00:00 Rkent-3 wrote: Comment on attachment 8801912 [PATCH] Gracefully handle SMTP servers that send a bad greeting and hang up. Review of attachment 8801912: ----------------------------------------------------------------- As a general statement, you are trying to fix two problems here. One is a really important problem, which is the fact that TB claims it sent when it did not. The other is not so important, too many error messages. The solution to the first is being held up by discussions of how to handle the second. Let's not try to solve the second here but in a different bug. So, where do we go from here? Unfortunately all of the core people are really frazzled at the moment getting ready for an impending release, so I'm going to have to short circuit this process to move it forward, as we would really like to get this fix landed. (It could also backport to TB 45). So I'm going to give additional comments on my approach, and bring in another reviewer to evaluate where we are at. I'm happy to give you credit for this bug regardless of what approach that we take, but if you are not happy with my approach (as indicated by a feedback-), and we end up going that way, then I'll probably need to reassign the bug to myself rather than land something in your name that you do not approve of. In any case, you've played a critical role in getting this bug to be fixed, so I want to sincerely thank you for being the catalyst to get this fixed. ::: mailnews/base/util/nsMsgProtocol.cpp @@ +39,5 @@ > #include "nsAlgorithm.h" > #include "mozilla/Services.h" > #include <algorithm> > #include "nsContentSecurityManager.h" > +#include "nsComposeStrings.h" You should not include a file from a specific protocol in this file which is used for a generic protocol. ::: mailnews/compose/src/nsSmtpProtocol.cpp @@ +422,5 @@ > MOZ_LOG(SMTPLogModule, mozilla::LogLevel::Info, > + ("SMTP connection error %lx while quitting", aStatus)); > + if (m_nextStateAfterResponse == SMTP_ERROR_DONE) > + // if we were going to abort fcc even if the QUIT had succeeded, abort > it > + aStatus = NS_ERROR_BUT_DONT_SHOW_ALERT; On the issue of too many error messages, actually the protocol code is supposed to handle this using m_urlErrorState, which is set to NS_ERROR_BUT_DONT_SHOW_ALERT after the alert shows that is the primary error message. So the existing code already had a mechanism to try to handle this. Trying to also fix it here is really a kludge. If you want to fix this, you need to figure out why the existing method is not doing what you want. I also really dislike having protocol state information being used outside of the tight protocol state machine. Yes they did it above, but I also dislike it there. @@ +445,5 @@ > + // for example, see bug 780124 > + MOZ_LOG(SMTPLogModule, mozilla::LogLevel::Info, > + ("SMTP connection dropped while attempting graceful failure")); > + nsMsgAsyncWriteProtocol::OnStopRequest(nullptr, ctxt, > + NS_ERROR_BUT_DONT_SHOW_ALERT); Again, this is not the right place to fix this. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/135 ------------------------------------------------------------------------ On 2016-10-28T08:31:12+00:00 Rkent-3 wrote: Comment on attachment 8805031 Don't claim we are done when we failed Jorg, could you look at this? I could make the changes suggested by Alex if you want, but I'm not sure that I see the point. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/136 ------------------------------------------------------------------------ On 2016-10-28T08:47:42+00:00 Jorg K wrote: (In reply to Kent James (:rkent) from comment #132) > Jorg, could you look at this? I could make the changes suggested by Alex if > you want, but I'm not sure that I see the point. We're talking about this, right? === Quote from copmment #130? If we are going to change the semantics of m_sendDone, it would be better to pass an aSendDone parameter to SendQuit and set m_nextStateAfterResponse based on aSendDone. === Would that be hard to do and then we've got two solutions to chose from and comment on? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/137 ------------------------------------------------------------------------ On 2016-10-28T09:35:43+00:00 Jorg K wrote: Comment on attachment 8805031 Don't claim we are done when we failed Review of attachment 8805031: ----------------------------------------------------------------- I've looked at this now and I think Kent's solution to separate the setting of m_sendDone from SendQuit() is simple and transparent. Alex, where did you plan to set 'm_nextStateAfterResponse'? ::: mailnews/compose/src/nsSmtpProtocol.cpp @@ +606,5 @@ > NS_ENSURE_SUCCESS(rv, rv); > bool verifyingLogon = false; > smtpUrl->GetVerifyLogon(&verifyingLogon); > + if (verifyingLogon) { > + m_sendDone = true; // We did what we were attempting. Please move the inline comment above the line like this: // Just verifying the ability to logon was done/succeeded(?) // so we pretend the send (which we didn't do) was // a success. m_sendDone = true; Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/138 ------------------------------------------------------------------------ On 2016-10-28T19:01:49+00:00 Alex Henrie wrote: Created attachment 8805631 change-m_sendDone-semantics.diff Kent, this is how I would improve upon your patch. But my fear is that if we change the m_sendDone semantics, it will require complicated code to fix the two-dialogs problem, and so the two-dialogs problem will never be fixed. > You should not include a file from a specific protocol in this file which is > used for a generic protocol. We can avoid referencing NS_ERROR_BUT_DONT_SHOW_ALERT in nsMsgProtocol::OnStopRequest by simply deleting the NS_ASSERTION from nsMsgProtocol::OnStopRequest. We'd have to do this anyway if we change the m_sendDone semantics. > On the issue of too many error messages, actually the protocol code is > supposed to handle this using m_urlErrorState, which is set to > NS_ERROR_BUT_DONT_SHOW_ALERT after the alert shows that is the primary error > message. So the existing code already had a mechanism to try to handle this. > Trying to also fix it here is really a kludge. If you want to fix this, you > need to figure out why the existing method is not doing what you want. The protocol code is okay except that it has no way to tell the rest of the mail-sending code that an alert should not be shown for a network error following another error. The only solution I can see is to make nsSmtpProtocol::OnStopRequest change the error to NS_ERROR_BUT_DONT_SHOW_ALERT if m_nextStateAfterResponse == SMTP_ERROR_DONE. Don't get me wrong; I am really happy to see movement on this bug, and I agree that pretty much anything would be better than what we have now. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/139 ------------------------------------------------------------------------ On 2016-10-28T19:10:45+00:00 Rkent-3 wrote: Comment on attachment 8805631 change-m_sendDone-semantics.diff I don't want to lose track of the need for me to look at this. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/140 ------------------------------------------------------------------------ On 2016-10-28T21:43:13+00:00 Jorg K wrote: Comment on attachment 8805031 Don't claim we are done when we failed Cancelling this for now since there is an alternative patch. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/141 ------------------------------------------------------------------------ On 2017-02-01T16:54:53+00:00 Vseerror wrote: *** Bug 941101 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/142 ------------------------------------------------------------------------ On 2017-02-01T17:04:37+00:00 Vseerror wrote: *** Bug 1270425 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/143 ------------------------------------------------------------------------ On 2017-03-31T20:52:55+00:00 Lfreitas34 wrote: This problem is happening to me with frequency. My company uses a Microsoft Exchange cloud based server and it frequently replies with a 4.4.2 error and the message is not sent, instead of being queued. People using other mail clients dont experience any problems. Does setting mailnews.sendInBackground to true will have influence in this problem? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/144 ------------------------------------------------------------------------ On 2017-05-03T12:55:47+00:00 Vseerror wrote: *** Bug 1299129 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/145 ------------------------------------------------------------------------ On 2017-05-03T13:03:37+00:00 Vseerror wrote: *** Bug 1304987 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/146 ------------------------------------------------------------------------ On 2017-07-09T23:25:57+00:00 Vseerror wrote: *** Bug 1088558 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/147 ------------------------------------------------------------------------ On 2017-10-03T12:15:44+00:00 Westburne04 wrote: Any progress on this? I have not had this problem for a very long time until last Friday when TB 52.03.00 gave "An error occurred while sending mail. The mail server responded: 5.2.1 : AOL will not accept delivery of this message.. Please check the message and try again. Delivering mail 100%" The error message stayed open until cancelled (a major improvement on before), on closing the error message the unsent message closed and was moved to sent folder, the message was not sent. The problem still ocurred with message content "test" but only ocurred whilst using a Hull Trains wifi connection. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/148 ------------------------------------------------------------------------ On 2017-10-03T12:23:31+00:00 Jorg K wrote: Comment on attachment 8805631 change-m_sendDone-semantics.diff All I can say is that the review request does not show up in Kent's review queue. Strange. So that's why this has fallen trough the cracks. So let me cancel the request and request it again. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/149 ------------------------------------------------------------------------ On 2017-10-03T12:24:16+00:00 Jorg K wrote: Now it worked: https://bugzilla.mozilla.org/request.cgi?action=queue&type=review&requestee=rkent%40caspia.com&group=type Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/150 ------------------------------------------------------------------------ On 2017-10-30T06:52:44+00:00 gds wrote: Created attachment 8923289 780124-gds-review-changes0.patch In conjunction with Bug 1390442 and Bug 1409678, which are closely related to this bug (maybe duplicates, at least in terms of the resulting fix), I have a proposed modified patch that fixes these problems: The following activities have a similar result: A network stream error occurs while sending email. A fatal SMTP reply errors occur while sending email. A password is requested when sending and is entered incorrectly. Cancel button is clicked on the 3-button login dialog before re-entering the correct password. A password is requested when sending and Cancel button is clicked instead of OK. A password is requested when sending and is entered incorrectly. Then on the password re-entry prompt, just click cancel instead of OK. Account A configured to use, e.g., yahoo's smtp server. Yahoo doesn't like this. Send an email from account A and take some time to read the error message while the connection times-out. (This is the cause of this bug.) The message is not sent but the message appears in the Sent folder. This has a different result: When sending, enter bad password on 1st prompt. On next password re-entry prompt enter bad password again. Then cancel on login 3-button screen. Leaves "Sending messages - ..." with Connected to smtp.mail..... box with progress bar moving left to right. Cancel "Sending Message--..." and progress bar remains. Then cancel progress bar window. Write (compose) window still present but read only! Send button and menus gray (disabled). In this case, message is not moved to Sent and Write window can only be dismissed. The attached patch does basically what the previous patch did in addition to fixing the read-only write window problem. I have also done a lot of testing to diagnose the problem and verify the fixes. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/151 ------------------------------------------------------------------------ On 2017-10-31T09:28:54+00:00 Jorg K wrote: Comment on attachment 8923289 780124-gds-review-changes0.patch I don't know how I inherited this. Let's see whether Kent responds within a month. Looking at comment #131, he knows a whole lot more about this than I do. Kent: What's the story with rkent-allmailn...@caspia.com? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/152 ------------------------------------------------------------------------ On 2017-11-29T22:09:14+00:00 Jacobsj wrote: This problem has really been throwing me for a loop. CenturyLink for some reason is frequently issuing 421 errors. Because of the way Tbird was acting, I thought it was just a warning and since it copied the message to the "sent" folder, I had a record of sending the message, though it never went anywhere. Really awful to tell people you had replied to them and yet you actually had not. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/153 ------------------------------------------------------------------------ On 2017-12-29T17:37:11+00:00 Alex Henrie wrote: Comment on attachment 8923289 780124-gds-review-changes0.patch Review of attachment 8923289: ----------------------------------------------------------------- Like Kent's patch, Gene's patch fixes the major problem and would be OK to commit to Thunderbird, although it pops up two error dialogs when one is enough. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/154 ------------------------------------------------------------------------ On 2018-03-30T08:25:38+00:00 Vseerror wrote: *** Bug 1390442 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/155 ------------------------------------------------------------------------ On 2018-03-30T08:26:02+00:00 Vseerror wrote: *** Bug 1409678 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/156 ------------------------------------------------------------------------ On 2018-07-01T20:40:47+00:00 Vseerror wrote: *** Bug 1469179 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/157 ------------------------------------------------------------------------ On 2018-08-22T06:00:12+00:00 Vseerror wrote: *** Bug 1002598 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/158 ------------------------------------------------------------------------ On 2018-10-08T20:11:23+00:00 Jorg K wrote: *** Bug 1488017 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/160 ------------------------------------------------------------------------ On 2018-10-09T19:56:35+00:00 Jorg K wrote: Comment on attachment 8805631 change-m_sendDone-semantics.diff Ben, here comes another hard one. As you can see, many votes, many duplicates, apparently two problems, the second one is some doubled-up message, different approaches where one party puts r-/f- on the patches of the other. Magnus and I decided to give you the honourable task to cut though it and favourise one patch or tweak it into shape. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/161 ------------------------------------------------------------------------ On 2018-10-09T19:57:30+00:00 Jorg K wrote: Comment on attachment 8923289 780124-gds-review-changes0.patch And this one. Most likely the patches have bitrot. Enjoy ;-) Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/162 ------------------------------------------------------------------------ On 2018-10-09T20:15:53+00:00 Benc-q wrote: Sure thing. The fixes don't look too complex, so I guess the trickiness is understanding the larger context and side effects. A good excuse to dive into another part of the code I've not looked at much yet! Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/163 ------------------------------------------------------------------------ On 2018-10-09T20:30:10+00:00 Jorg K wrote: Looks like Kent's patch (attachment 8805031) is the base upon every one agrees. Then we have to improved versions. Gene does a lot of testing, see comment #147 (!!) and even Axel agreed that it might be the way forward (comment #150). Maybe you can work out what the "two dialogue" problem is and move it to a new bug/patch. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/164 ------------------------------------------------------------------------ On 2019-02-26T23:23:42+00:00 Benc-q wrote: Created attachment 9046887 badsmtpd.py A little script to implement a badly-behaving smtp server which responds to MAIL commands with "554 Go away!", then disconnects. Usage: Run it locally, then set your outgoing STMP server to localhost:6502 (with this script I can confirm the copy-to-sent-mail-after-an-error behaviour, so I'm looking at the fixes now). Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1215882/comments/165 ** Changed in: thunderbird Status: Unknown => Confirmed ** Changed in: thunderbird Importance: Unknown => Critical -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1215882 Title: Emails are silently discarded on 554 reply to STARTTLS To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1215882/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
