Emails are silently discarded on 554 reply to STARTTLS

[Nikolaus Rath]

It seems that emails are silently discarded when the remote SMTP server replies with an error on STARTTLS. Here is an example smtp log created with NSPR_LOG_MODULES='smtp:5,timestamp':

2013-08-23 11:10:25.548708 UTC - 43480896[7fe10164b370]: SMTP Connecting to: mail.trialphaenergy.com
2013-08-23 11:10:26.513993 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:26.514026 UTC - 43480896[7fe10164b370]: SMTP Response: 220 mail.trialphaenergy.com Microsoft ESMTP MAIL Service ready at Fri, 23 Aug 2013 04:10:25 -0700
2013-08-23 11:10:26.514047 UTC - 43480896[7fe10164b370]: SMTP entering state: 14
2013-08-23 11:10:26.514069 UTC - 43480896[7fe10164b370]: SMTP Send: EHLO [10.11.206.9]
2013-08-23 11:10:27.144751 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144791 UTC - 43480896[7fe10164b370]: SMTP Response: 250-mail.trialphaenergy.com Hello [10.11.10.19]
2013-08-23 11:10:27.144808 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144817 UTC - 43480896[7fe10164b370]: SMTP Response: 250-SIZE
2013-08-23 11:10:27.144828 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144839 UTC - 43480896[7fe10164b370]: SMTP Response: 250-PIPELINING
2013-08-23 11:10:27.144846 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144851 UTC - 43480896[7fe10164b370]: SMTP Response: 250-DSN
2013-08-23 11:10:27.144857 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144862 UTC - 43480896[7fe10164b370]: SMTP Response: 250-ENHANCEDSTATUSCODES
2013-08-23 11:10:27.144868 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144885 UTC - 43480896[7fe10164b370]: SMTP Response: 250-STARTTLS
2013-08-23 11:10:27.144889 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144893 UTC - 43480896[7fe10164b370]: SMTP Response: 250-AUTH NTLM
2013-08-23 11:10:27.144897 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144900 UTC - 43480896[7fe10164b370]: SMTP Response: 250-8BITMIME
2013-08-23 11:10:27.144904 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144920 UTC - 43480896[7fe10164b370]: SMTP Response: 250-BINARYMIME
2013-08-23 11:10:27.144926 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144931 UTC - 43480896[7fe10164b370]: SMTP Response: 250 CHUNKING
2013-08-23 11:10:27.144936 UTC - 43480896[7fe10164b370]: SMTP entering state: 4
2013-08-23 11:10:27.144961 UTC - 43480896[7fe10164b370]: SMTP entering state: 21
2013-08-23 11:10:27.144968 UTC - 43480896[7fe10164b370]: SMTP Send: STARTTLS
2013-08-23 11:10:27.757848 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.757881 UTC - 43480896[7fe10164b370]: SMTP Response: 554 Policy violation. Email Session ID: {521742ED-1-F0B0B0A-FFFF}
2013-08-23 11:10:27.757893 UTC - 43480896[7fe10164b370]: SMTP entering state: 19
2013-08-23 11:10:27.757900 UTC - 43480896[7fe10164b370]: SMTP entering state: 21
2013-08-23 11:10:27.757905 UTC - 43480896[7fe10164b370]: SMTP Send: QUIT
2013-08-23 11:10:27.757915 UTC - 43480896[7fe10164b370]: SMTP entering state: 0

The UI, however, gives no indication of failure and closes the compose window after the apparent successful submission to the smtp server.

If the user has not configured a Sent folder this results in data loss. Even if the user has configured a sent folder, he receives no indication that the email has not been sent.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: thunderbird 17.0.8+build1-0ubuntu0.13.04.1
ProcVersionSignature: Ubuntu 3.8.0-27.40-generic 3.8.13.4
Uname: Linux 3.8.0-27-generic x86_64
AddonCompatCheckDisabled: False
ApportVersion: 2.9.2-0ubuntu8.3
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: nikratio 2425 F.... pulseaudio
BuildID: 20130803220711
Channel: Unavailable
Date: Fri Aug 23 13:05:30 2013
ForcedLayersAccel: False
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2013-07-30 (23 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
MarkForUpload: True
PrefSources:
 prefs.js
 /usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{847b3a00-7ab1-11d4-8f02-006008948af5}/defaults/preferences/enigmail.js
 /usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{847b3a00-7ab1-11d4-8f02-006008948af5}/defaults/preferences/000system.js
Prefs:
 extensions.lastAppVersion: "17.0.8" (prefs.js)
 network.cookie.prefsMigrated: true (prefs.js)
 places.database.lastMaintenance: 1377252192 (prefs.js)
 places.history.expiration.transient_current_max_pages: 104858 (prefs.js)
 privacy.donottrackheader.enabled: true (prefs.js)
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
Profiles: Profile0 (Default) - LastVersion=17.0.8/20130803220711
RelatedPackageVersions:
 icedtea-7-plugin 1.3.2-1ubuntu1.1
 totem-mozilla 3.6.3-0ubuntu6
 rhythmbox-mozilla 2.98-0ubuntu5
RunningIncompatibleAddons: False
SourcePackage: thunderbird
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 02/04/2013
dmi.bios.vendor: LENOVO
dmi.bios.version: G6ET93WW (2.53 )
dmi.board.asset.tag: Not Available
dmi.board.name: 3444F8U
dmi.board.vendor: LENOVO
dmi.board.version: Win8 Pro DPK TPG
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvrG6ET93WW(2.53):bd02/04/2013:svnLENOVO:pn3444F8U:pvrThinkPadX1Carbon:rvnLENOVO:rn3444F8U:rvrWin8ProDPKTPG:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 3444F8U
dmi.product.version: ThinkPad X1 Carbon
dmi.sys.vendor: LENOVO

[Rob-smeets (rob-smeets)]

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

[Rob-smeets (rob-smeets)]

Created attachment 648680
An example of an SMTP error message which I refer to

[Lucdischert (lucdischert)]

Duplicate of bug 780086 ?

[M-wada-7 (m-wada-7)]

(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?

[M-wada-7 (m-wada-7)]

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.

[M-wada-7 (m-wada-7)]

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)

[M-wada-7 (m-wada-7)]

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.

[M-wada-7 (m-wada-7)]

*** Bug 775999 has been marked as a duplicate of this bug. ***

[M-wada-7 (m-wada-7)]

*** Bug 780086 has been marked as a duplicate of this bug. ***

[M-wada-7 (m-wada-7)]

*** Bug 780115 has been marked as a duplicate of this bug. ***

[Rob-smeets (rob-smeets)]

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

[Rob-smeets (rob-smeets)]

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?

[Rob-smeets (rob-smeets)]

(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.

[Fleandro10415 (fleandro10415)]

I have installed Thunderbird 15 Beta 3 in Windows 7 Professional x86, and the same problem still happens.

[Rob-smeets (rob-smeets)]

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.

[Ludovic-mozilla (ludovic-mozilla)]

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 ?

[Rob-smeets (rob-smeets)]

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).

[M-wada-7 (m-wada-7)]

*** Bug 788188 has been marked as a duplicate of this bug. ***

[M-wada-7 (m-wada-7)]

*** Bug 795338 has been marked as a duplicate of this bug. ***

[M-wada-7 (m-wada-7)]

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;
> + }

[M-wada-7 (m-wada-7)]

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"?

[M-wada-7 (m-wada-7)]

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

[Bugzilla-tf (bugzilla-tf)]

*** Bug 795529 has been marked as a duplicate of this bug. ***

[Bugzilla-tf (bugzilla-tf)]

*** Bug 792930 has been marked as a duplicate of this bug. ***

[Bugzilla-tf (bugzilla-tf)]

*** Bug 792803 has been marked as a duplicate of this bug. ***

[Bugzilla-tf (bugzilla-tf)]

*** Bug 793154 has been marked as a duplicate of this bug. ***

[M-wada-7 (m-wada-7)]

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)?

[M-wada-7 (m-wada-7)]

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.

[M-wada-7 (m-wada-7)]

cc-ing to Mark Banner who is ownwer of bug 554044.

[Rob-smeets (rob-smeets)]

Happy to see something move here. Sorry that I couldn't find the time to do the regression test myself.

[Rob-smeets (rob-smeets)]

If necessary, I can test nightly builds to see if this is solved. Just let us know.

[Rheras (rheras)]

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?

[M-wada-7 (m-wada-7)]

*** Bug 797814 has been marked as a duplicate of this bug. ***

[David Lechner (dlech)]

*** Bug 813537 has been marked as a duplicate of this bug. ***

[M-wada-7 (m-wada-7)]

*** Bug 783352 has been marked as a duplicate of this bug. ***

[L-jay-4 (l-jay-4)]

Smtp Yahoo: resources temporarily unavailable

Thunderbird moves to sent folder as if everything is fine. Message did not go through.

[Nikolaus Rath (nrath)]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Firefox/17.0 Iceweasel/17.0.8 (Nightly/Aurora)
Build ID: 20130806234539

Steps to reproduce:

It seems that emails are silently discarded when the remote SMTP server replies with an error on STARTTLS. Here is an example smtp log created with NSPR_LOG_MODULES='smtp:5,timestamp':

2013-08-23 11:10:25.548708 UTC - 43480896[7fe10164b370]: SMTP Connecting to: mail.trialphaenergy.com
2013-08-23 11:10:26.513993 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:26.514026 UTC - 43480896[7fe10164b370]: SMTP Response: 220 mail.trialphaenergy.com Microsoft ESMTP MAIL Service ready at Fri, 23 Aug 2013 04:10:25 -0700
2013-08-23 11:10:26.514047 UTC - 43480896[7fe10164b370]: SMTP entering state: 14
2013-08-23 11:10:26.514069 UTC - 43480896[7fe10164b370]: SMTP Send: EHLO [10.11.206.9]
2013-08-23 11:10:27.144751 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144791 UTC - 43480896[7fe10164b370]: SMTP Response: 250-mail.trialphaenergy.com Hello [10.11.10.19]
2013-08-23 11:10:27.144808 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144817 UTC - 43480896[7fe10164b370]: SMTP Response: 250-SIZE
2013-08-23 11:10:27.144828 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144839 UTC - 43480896[7fe10164b370]: SMTP Response: 250-PIPELINING
2013-08-23 11:10:27.144846 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144851 UTC - 43480896[7fe10164b370]: SMTP Response: 250-DSN
2013-08-23 11:10:27.144857 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144862 UTC - 43480896[7fe10164b370]: SMTP Response: 250-ENHANCEDSTATUSCODES
2013-08-23 11:10:27.144868 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144885 UTC - 43480896[7fe10164b370]: SMTP Response: 250-STARTTLS
2013-08-23 11:10:27.144889 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144893 UTC - 43480896[7fe10164b370]: SMTP Response: 250-AUTH NTLM
2013-08-23 11:10:27.144897 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144900 UTC - 43480896[7fe10164b370]: SMTP Response: 250-8BITMIME
2013-08-23 11:10:27.144904 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144920 UTC - 43480896[7fe10164b370]: SMTP Response: 250-BINARYMIME
2013-08-23 11:10:27.144926 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.144931 UTC - 43480896[7fe10164b370]: SMTP Response: 250 CHUNKING
2013-08-23 11:10:27.144936 UTC - 43480896[7fe10164b370]: SMTP entering state: 4
2013-08-23 11:10:27.144961 UTC - 43480896[7fe10164b370]: SMTP entering state: 21
2013-08-23 11:10:27.144968 UTC - 43480896[7fe10164b370]: SMTP Send: STARTTLS
2013-08-23 11:10:27.757848 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
2013-08-23 11:10:27.757881 UTC - 43480896[7fe10164b370]: SMTP Response: 554 Policy violation. Email Session ID: {521742ED-1-F0B0B0A-FFFF}
2013-08-23 11:10:27.757893 UTC - 43480896[7fe10164b370]: SMTP entering state: 19
2013-08-23 11:10:27.757900 UTC - 43480896[7fe10164b370]: SMTP entering state: 21
2013-08-23 11:10:27.757...

[M-wada (m-wada)]

This problem occurs even when 4XX error on greeting.
Dup of bug 780124.

*** This bug has been marked as a duplicate of bug 780124 ***

[Jorg K (jorgk)]

Now it worked:
https://bugzilla.mozilla.org/request.cgi?action=queue&type=review&requestee=rkent%40caspia.com&group=type

[gds (gds-chartertn)]

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.

[Jorg K (jorgk)]

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 <email address hidden>?

[Jacobsj (jacobsj)]

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.

[Alex Henrie (alexhenrie24)]

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.

[Vseerror (vseerror)]

*** Bug 1390442 has been marked as a duplicate of this bug. ***

[Vseerror (vseerror)]

*** Bug 1409678 has been marked as a duplicate of this bug. ***

[Vseerror (vseerror)]

*** Bug 1469179 has been marked as a duplicate of this bug. ***

[Vseerror (vseerror)]

*** Bug 1002598 has been marked as a duplicate of this bug. ***

[Paul White (paulw2u)]

Updated upstream bug report

[Jorg K (jorgk)]

*** Bug 1488017 has been marked as a duplicate of this bug. ***

[Jorg K (jorgk)]

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.

[Jorg K (jorgk)]

Comment on attachment 8923289
780124-gds-review-changes0.patch

And this one. Most likely the patches have bitrot. Enjoy ;-)

[Benc-q (benc-q)]

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!

[Jorg K (jorgk)]

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.

[Benc-q (benc-q)]

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).

[Lcfiorini-u (lcfiorini-u)]

Hello people, I'm using SeaMonkey in Windows 10, so command lines mean nothing to an end user like me, illiterate in Linux and programming. I wonder if I copy the command lines into a .txt file and save it as .bat or .exe and execute it afterwards. Please give me a clue at it.

[Jorg K (jorgk)]

How does your comment #161 relate to this bug? Please don't post unrelated comments.

[Lcfiorini-u (lcfiorini-u)]

Jorg K, my post is related to the codes pasted here as instructions for command-line based OSs.

[Lcfiorini-u (lcfiorini-u)]

Jorg K, please tell me if there is something I can do with the aforementioned patches, because SM has the option Tools -> Web Development -> Programmer's toolbar.
Maybe there is something I can do in order to make it work in my Windows 10 OS, thank you.

[Jorg K (jorgk)]

In order to make something work, you need to build/compile Thunderbird. There is no easy fix here.

[Lcfiorini-u (lcfiorini-u)]

After giving up Seamonkey, I've taken my backed up data and installed Thunderbird. But the same problem is still there. I thought the greater Thunderbird popularity would be enough to prompt the community to fix this problem.
I've alto tried to Google some possible solution and ended up in an interesting web page with some workarounds which did not work in my case, though:
http://kb.mozillazine.org/Cannot_send_mail

[Lcfiorini-u (lcfiorini-u)]

BTW I've followed the instructions therein to log the events and you can see below the results:

2019-08-08 21:30:15.478000 UTC - [5220:Main Thread]: I/SMTP SMTP Connecting to: xxx.xxx.xxx.xx:110
2019-08-08 21:30:15.525000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 0
2019-08-08 21:30:15.525000 UTC - [5220:Main Thread]: I/SMTP SMTP Response: +OK Hello there.
2019-08-08 21:30:15.525000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 14
2019-08-08 21:30:16.500000 UTC - [5220:Main Thread]: I/SMTP SMTP Send: QUIT

2019-08-08 21:30:16.500000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 0
2019-08-08 21:30:16.519000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 0
2019-08-08 21:30:16.519000 UTC - [5220:Main Thread]: I/SMTP SMTP Response: +OK Better luck next time.
2019-08-08 21:30:16.519000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 11
2019-08-08 21:30:16.530000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 12
2019-08-08 21:30:16.530000 UTC - [5220:Main Thread]: I/SMTP SMTP connection error quitting 80004004, ignoring
2019-08-08 21:30:17.789000 UTC - [5220:Main Thread]: I/SMTP SMTP Connecting to: xxx.xxx.xxx.xx:110
2019-08-08 21:30:17.839000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 0
2019-08-08 21:30:17.839000 UTC - [5220:Main Thread]: I/SMTP SMTP Response: +OK Hello there.
2019-08-08 21:30:17.839000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 14
2019-08-08 21:30:18.812000 UTC - [5220:Main Thread]: I/SMTP SMTP Send: QUIT

2019-08-08 21:30:18.812000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 0
2019-08-08 21:30:18.832000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 0
2019-08-08 21:30:18.832000 UTC - [5220:Main Thread]: I/SMTP SMTP Response: +OK Better luck next time.
2019-08-08 21:30:18.832000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 11
2019-08-08 21:30:18.842000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 12
2019-08-08 21:30:18.842000 UTC - [5220:Main Thread]: I/SMTP SMTP connection error quitting 80004004, ignoring
2019-08-08 21:30:19.852000 UTC - [5220:Main Thread]: I/SMTP SMTP Connecting to: xxx.xxx.xxx.xx:110
2019-08-08 21:30:19.912000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 0
2019-08-08 21:30:19.912000 UTC - [5220:Main Thread]: I/SMTP SMTP Response: +OK Hello there.
2019-08-08 21:30:19.912000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 14
2019-08-08 21:30:20.944000 UTC - [5220:Main Thread]: I/SMTP SMTP Send: QUIT

2019-08-08 21:30:20.944000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 0
2019-08-08 21:30:20.964000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 0
2019-08-08 21:30:20.964000 UTC - [5220:Main Thread]: I/SMTP SMTP Response: +OK Better luck next time.
2019-08-08 21:30:20.964000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 11
2019-08-08 21:30:20.974000 UTC - [5220:Main Thread]: I/SMTP SMTP entering state: 12
2019-08-08 21:30:20.974000 UTC - [5220:Main Thread]: I/SMTP SMTP connection error quitting 80004004, ignoring

[Jorg K (jorgk)]

*** Bug 1584390 has been marked as a duplicate of this bug. ***

[Vseerror (vseerror)]

*** Bug 852607 has been marked as a duplicate of this bug. ***

[Vseerror (vseerror)]

(In reply to Ben Campbell from comment #160)
> 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).

Ben, Did you come up with any further ideas or modified WIP?

[Infofrommozilla (infofrommozilla)]

*** Bug 1630260 has been marked as a duplicate of this bug. ***

[Infofrommozilla (infofrommozilla)]

*** Bug 1630283 has been marked as a duplicate of this bug. ***

[Bernhard Riegler (riegler-b)]

I have the following environment: Europe, Austria, A1 Provider, sending with Thunderbird 78.7.1(64-bit) on GNU/Linux Ubuntu 20.04 LTS
the outgoing configuration is SMTP port 587 with STARTTLS

everything works fine, but sometimes the Provider SMTP Server is BUSY.
I get in thunderbird client a pop up "load too high (#4.3.0)" and then the email is in 'sent' folder.
as I always put myself a CC in every email, I can guarantee that the email was not processed by the SMTP server.
this matches the pop up message.
this is a transient SMTP server error.
thunderbird client knows this and shall not put this failed output into folder 'sent' , but into folder 'draft' for later retry.

[Bernhard Riegler (riegler-b)]

after thinking about the possibilities for this server "transient failure"
I would recommend rescue in the local Filesystem on server status (#4.3.0) independent of config for folder 'sent' and folder 'draft'
make a subdirectory "rescue" in the local File System below local ARCHIVE folder and put the email in here.
this is independent of the server BUSY problem.
the file in 'rescue' folder can now easily retried later and is not 'lost on transit'

[Westburne04 (westburne04)]

The reason that this bug is critical is because a user does not know an email was not sent. The solution that is needed is for the user to know that it has not been sent. A workaround does not help if a user does not know there is a problem. I raised the issue many years ago and have kept an eye that the brief message that sending fails, before the email is put in the sent folder, does not appear. For me the circumstances that originally caused it seem no longer to apply.

[L-stephan (l-stephan)]

In case the server responds with a 550 Thunderbird correctly shows an error message to the user and goes back to the edit window, so you can resend the message.

If it would do the same in the case of a 4XX all would be good.

Should be an easy fix.

[UlfZibis (ulf-zibis)]

Same cause for bug 1656240 comment 11.

[Bernhard Riegler (riegler-b)]

I completely agree with jonwestburne
CRITICAL because the user does not know the email was not sent.

I had again a server BUSY condition.
thunderbird version 78.7.1(64-bit) on GNU/Linux Ubuntu 20.04 LTS platform.
popup "load too high (#4.3.0)" and then the email is in 'sent' folder of my local Filesystem Archive.
my automatic "CC to sender" proves that it was not processed by server. I did not receive my CC.

[Infofrommozilla (infofrommozilla)]

*** Bug 1713077 has been marked as a duplicate of this bug. ***

[Vseerror (vseerror)]

Do we expect this to be gone with smtp-js?

[rns (remotenonsense)]

(In reply to Wayne Mery (:wsmwk) from comment #180)
> Do we expect this to be gone with smtp-js?

Yes, I think so. Compose window is still open in my local test.

[Vseerror (vseerror)]

I just realized Ben has a test script comment 160. Does smtp-js have a test library, and does it cover this?

[rns (remotenonsense)]

We have a [Smtpd.jsm](https://searchfox.org/comm-central/source/mailnews/test/fakeserver/Smtpd.jsm) fakeserver for testing, we don't have a test case for this bug though.

[Jonathan Kamens (jik)]

The other reason this is a critical bug is because if the user does not have Thunderbird configured to save messages in Sent Mail -- which the user *shouldn't*, e.g., if the user is using Gmail, since Gmail saves outbound messages automatically, then this bug causes DATA LOSS by closing the window without saving the message ANYWHERE.

Can believe this bug is still not fixed after nearly a decade. Glad to see it's about to be fixed, but as someone else pointed out in a recent comment, if this is just a matter of changing the status codes that cause Thunderbird to leave the compose window open, then maybe we should make that fix in TB78 rather than waiting until the next major release for it to be fixed?

[Mkmelin+mozilla (mkmelin+mozilla)]

Thunderbird 91 is just around the corner, and any change to 78 could no longer get beta testing, so even with a fix to the old code we would not take it at this point.