If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Sending Message hangs using SMTP/SSL

VERIFIED FIXED in mozilla0.9.1


MailNews Core
Networking: SMTP
17 years ago
9 years ago


(Reporter: kinmoz, Assigned: John G. Myers)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta1+])


(3 attachments)



17 years ago
So I launched my 04/02/01 debug build this morning and noticed that I couldn't 
send mail. I kept getting a send message failed error dialog.

On IRC, someone pointed out that the SMTP settings on the Mail/News Account 
Settings dialog were munged ... and sure enough mine were too. The Username 
textfield was displaying (null) instead of "kin" and the "When Available" radio 
button was checked under Use SSL.

Typing in "kin" and checking "Never" use SSL allowed me to send mail again.

Did someone touch the mail prefs lastnight? Several people on IRC are reporting 
the same problem (Solaris, Win32, Linux).

Not sure if this should be a smoketest blocker or not since there is a work 
around. So feel free to remove the smoketest keyword.

Comment 1

17 years ago
I forgot to mention that this is with a Mozilla debug build, *not* commercial 
Keywords: smoketest

Comment 2

17 years ago
*** Bug 74465 has been marked as a duplicate of this bug. ***

Comment 3

17 years ago
This happened to me also, very frustrating.
I'll take a look as kin did and see what got munged.

Comment 4

17 years ago
This is related to another one of our bugs.  We should probably disable "When
available" if it's going to cause mail to not work.

Comment 5

17 years ago
*** Bug 74635 has been marked as a duplicate of this bug. ***

Comment 6

17 years ago
yes I think it was the ssl-when-available bug that bit me.
I agree with putterman, we should disable this pref if
it's gonna be flakey for mail-send.
*** Bug 74964 has been marked as a duplicate of this bug. ***

Comment 8

17 years ago
I can send normal mail, but no attachments with version of Mozilla from 0.8.1
I doublechecked using Outlook Express if it was my ISP, but it wasn't. OE sent
my mail with attachments without a hitch.

I haven't seen a build afterwards where it was fixed. Not that it matters much
as mailzilla won't start at all now. But that's a seperate bug.


Comment 9

17 years ago
I disagree with mcafee and putterman.  Do we disable inline images when imglib 

Track down the problem and fix it.  Don't just throw out the test coverage.

Comment 10

17 years ago
But we do give serious thought to backing the changes to image lib out if they
make the product unuseable. We were going to do that until I figured out a way
to get libpr0n working with inline images very quickly. Switching back to smtp....

I think the problem is that our code isn't ready for tsl support yet =). It
looks a little fishy to me. 

When we go to create a socket connection to the server it looks like we are
checking this pref and attempting to create a "tls" socket:
    if (m_prefTrySSL != PREF_SSL_NEVER) {
        rv = OpenNetworkSocket(aURL, "tls", callbacks);
        if (NS_FAILED(rv) && m_prefTrySSL == PREF_SSL_TRY) {
            m_prefTrySSL = PREF_SSL_NEVER;
            rv = OpenNetworkSocket(aURL, nsnull, callbacks);
if we get an error back in OpennetworkSocket, then we try to create a normal
network socket.

Unfortunately opening a network socket is asynch. You won't get an error back in
OpenNetworkSocket if we failed to create a tls connection to the server. It
comes back later in an OnStopRequest call with an error. 

So we never hit the back up code of creating a normal connection. 

Seems like we changed this pref pre-maturely. The code doesn't seem to be there
to support it.

Also, correct me if I'm wrong, but I thought with SMTP you are never supposed to
create an ssl connection to the server immediately. Aren't you supposed to make
a clear text connection, query the server capabilities and if it supports tls
then "step up" your connection into a tls connection?

Keywords: nsbeta1
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9

Comment 11

17 years ago
A "tls" socket is a normal socket which is upgradable to TLS.  It does not 
matter at this point whether we can create a connection to the server.  The 
error it is handling by falling back to a normal network socket is the absense 
of the psmglue component.

The code is there to support this option and it has been tested and found to be 
working.  The code may well have regressed in recent builds.  It is also 
possible that some testers have out of date (as opposed to missing) psmglue 

Comment 12

17 years ago
ahh okay, we'll the problem I see is that the creation of this "tls" socket
fails. I am up to date in psm. 

We try to open a tls connection and we immediately get an OnStopRequest call
with an error result (NS_ERROR_FAILURE) I believe. 

Comment 13

17 years ago
Does https: work for you?

Comment 14

17 years ago
https is working great. 

Comment 15

17 years ago
Using a build from yesterday, sending mail works for me using psm2, but I'm 
getting assertions due to the fact that nsMsgComposeAndSend::DeliverfileAsMail() 
is passing a null callbacks to smtpService->SendMailMessage().  Perhaps this 
lack of callbacks is horking PSM 1.

Comment 16

17 years ago
Perhaps this is caused by bug 71351?

It would help to know who is sending the OnStopRequest and why.
I'll switch my build to PSM 1 and try reproducing.

Comment 17

17 years ago
I am unable to reproduce this.

Comment 18

17 years ago
yes, I think this was the ssl pref set to 1 problem for me.

Comment 19

17 years ago
*** Bug 74978 has been marked as a duplicate of this bug. ***

Comment 20

17 years ago
I'm going to back out the change to always try tsl when the tree opens this
afternoon. We are losing our internal users at an alarming rate because of this
problem. If they can't send mail they aren't going to use the product. They
don't know to turn this pref back to use tsl never. I just got 3 more emails
over the weekend from more people who stopped using the mail client because of
this. It's a one line change to get us back on our feet until we can figure out
a fix.

The problem is that we are failing to find a socket provider for tsl deep down
in nsSocketTransport. This comes back as an error via OnStopRequest.


Comment 21

17 years ago
As I mentioned before, I am unable to reproduce this on a fresh build of PSM 1.  
This is most likely caused by out of date PSM or psm-glue code.

Comment 22

17 years ago
agree with mscott here, it is very frustrating to spend
time composing a message only to have the browser not-send it.
THAT is something that prompts me to shut mozilla down and
start 4.7 up, and spend the rest of the day sending mail with 4.7.
This is a borderline "loss of data" bug, we should be very careful
with the user's data, in this case the mail composition.

Comment 23

17 years ago
Is anyone seeing this with a fresh build of PSM?

PSM 2.0 is likely to land tomorrow, it may make sense to retest then.

Comment 24

17 years ago
If this is indeed caused by out of date PSM code, then we could make a one time 
fix after the Friday PSM 2.0 landing by changing the "tls" socket type to 
"tlsstepup".  The out of date PSM code would fail to create a "tlsstepup" socket 
type and would fallback to a normal socket.  This would have the added benefit 
of making the name of the socket type more descriptive.

This problem will, however, keep recurring if the interfaces keep changing out 
from underneath PSM and developers don't rebuild PSM.

Comment 25

17 years ago
*** Bug 75810 has been marked as a duplicate of this bug. ***

Comment 26

17 years ago
change qa contact
QA Contact: esther → sheelar

Comment 27

17 years ago
Created attachment 30906 [details] [diff] [review]
Patch to rename "tls" sockets to "tlsstepup"

Comment 28

17 years ago
Reassign to check in one-time workaround.  Hopefully PSM2 will be built by 
default soon.
Assignee: mscott → jgmyers

Comment 29

17 years ago
Bug 76101 as well as bug 76084 should be marked dups of this one, making it
almost mostfreq (7 dups)

Comment 30

17 years ago
*** Bug 76101 has been marked as a duplicate of this bug. ***

Comment 31

17 years ago
My description from bug 76101 in case the cause is different:

build 2001-04-14, imap.cs.com, smtp.cs.com, win98

Can't send e-mail. when clicking "send", get error message "sent operation failed"

I (regular user/tester) haven't used a nightly in weeks because of problems like
this :(

Comment 32

17 years ago
*** Bug 76084 has been marked as a duplicate of this bug. ***

Comment 33

17 years ago
r=javi on security/manager changes if necko team approves changes to netwerk.

I'm not sure if this will fix the bug, but it will clear up some confusion with
regards to using the term TLS.  Calling the interface TLS socket provider tends
to imply SSL v3.1, which is what TLS really is, where what is really wanted is a
clear socket that can later initiate an SSL connection, the definition of TLS
that necko uses.

Comment 34

17 years ago
wfm on 2001-04-16, win98

Comment 35

17 years ago
r=darin on networking changes

Comment 36

17 years ago

John, I'm curious why we think changing the progid for the tsl socket is going
to make this problem go away? Was there an impedance mismatch between psm, necko
and mail before? It looked like we changed all 3 of them to use tlsstepup
instead of tls. 

Comment 37

17 years ago
Changing the progid will prevent recent builds from running old psm code.  This 
will eliminate an impedance mismatch as a possible cause of the problem.

From the report of Peter Lairo, it seems possible that this bug was fixed by the 
PSM 2.0 landing last week.

Comment 38

17 years ago
Is anyone still seeing this?

Comment 39

17 years ago
No. Not since PSM2 landed (Win32 installer builds on WinME).
I am using a debug build from this morning and as soon I change the setting of
SLL to when available, I cannot send mail anymore!
How can I check I am using the right PSM?
oops, forget to said that I am on WinNT 4

Comment 43

17 years ago
We haven't added the capability of querying for version to PSM 2, so the only
way to do it currently is to look in the components directory of your install
and look to see that there are pipnss.dll and pippki.dll files in that
directory.  (Make sure there is no psmglue.dll as well)

My debug build doesn't have any of those dll (pipnss.dll, pippki.dll and psmglue.dll).

I've tested also my commercial build from yesterday I have installed using the netscape installer, and it has those 3 
dll. I can send small message without attachment but when I try to send the www.netscape.com page, it stall during 
the send with the following tatus on the compose window: Sending message... Same if i remove the psmglue.dll.

Comment 45

17 years ago
Get rid of psmglue.dll in your installed build.  That will cause all sorts of
whackiness if pip*.dll are installed.

Comment 46

17 years ago
the problem is that PSM (including 2.0) is not built by default for mozilla
developers. And when PSM is not installed this code does not work correctly if
the SMTP setting is set to always try TSL. We go in and attempt to create a tsl
socket. Then asynchronously the socket transport comes back with an error in an
OnStopRequest call cause it wasn't able to create an underlying TSL transport.

We either need to fix the case when PSM isn't installed and make it work with
this default setting of always try tsl or we need to change the default setting
back to never.

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

Comment 48

17 years ago
mscott, aren't we morphing this bug? U believe we should close the bug as
workforsome and open another about the PMS not installed problem
I had made a change, at one time (it got lost in one of the big necko API
landings) that made the call to nsSocketTransport::Init fail if it was unable to
create any of the underlying socket providers.  That way, SMTP would be able to
tell right away that this condition had occurred, and fall back to a regular socket.

Should I reimplement this change?

Comment 50

17 years ago
that would definetly help. I believe the problem here has always been that
people are unable to send mail when psm is not installed. 

If you were able to resurrect that code bryner, I think we'd be in business.

Comment 51

17 years ago
Reassign to bryner.
Assignee: jgmyers → bryner

Comment 52

17 years ago
I propose this be retargeted to 0.9.1.  Mozilla 0.9 will ship with PSM 
installed, so this won't be an issue for that release.
I agree, this is not an 0.9 blocker.
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 54

17 years ago
*** Bug 76196 has been marked as a duplicate of this bug. ***

Comment 55

17 years ago
Unable to send mail from yahoo mail using this build (windows 98:
2001-04-19-06-Mtrunk). Works fine on netscape mails. If you have yahoo
account and log in. Try to send someone the mail, and click the send button,
it just sits there, does not send.
I've verified on Mac and Linux using today's builds (2001-04-19-08-Mtrunk),
it works fine, no problem.

Comment 56

17 years ago
i don't have this problem with today's build (winNT though). aren't your smtp
setting reverted back to username "null"?

Comment 57

17 years ago
On win98, I haven't been able to send attachments for any of the recent builds
(using send page from browser window.)  I have my ssl setting turned off in the
account settings.  My name and email appear correct.  Am I still somehow hitting
this bug?  (I don't find any prefs in my prefs.js that look related to this.  I
don't see the never/when available choices anywhere...?)

Comment 58

17 years ago
*** Bug 76951 has been marked as a duplicate of this bug. ***
*** Bug 77254 has been marked as a duplicate of this bug. ***
This bug start to killing us, we need to fix it asap or at least change the
default setting to "Never" until we fix it! Change severity to critical!
Severity: normal → critical
I have a patch I believe will fix this by causing nsSocketTransport::Init to
fail if the ssl socket provider is unavailable; this should cause the SMTP code
to fallback to non-ssl.
Created attachment 32331 [details] [diff] [review]
patch to check for socket provider in nsSocketTransport::Init
I should note that this will only fix the problem if it's caused by PSM not
being installed.
Created attachment 32332 [details] [diff] [review]
patch #2
This one is a little cleaner, it propagates the return code from
GetSocketProvider (which is NS_ERROR_UNKNOWN_SOCKET_TYPE if no provider exists),
in case someone wants to handle that differently.
Per discussion on irc, there seem to be a couple of different problems here. 
There is one problem that happens when you don't have PSM installed, but
apparently sending mail with SSL can fail even if PSM is installed.  So, I don't
think I am the right owner for this.  Anyone want to take it?

Comment 67

17 years ago
Please land your patch to take care of the PSM-not-present case.

What other problems are there?  People seeing other problems should report them 
in bugzilla.

Comment 68

17 years ago
When Brian's fix goes in we can test this again, but we need to know exactly how
to test his fix.  If we use the installer to do the default installation will we
get PSM?   If so, do we need to install using Custom and deselect PSM then test
his fix? 

All the people I've gone down to help trouble shoot their sending problem, they
had used the defalult install and had to change the Outgoing SSL to "Never" to
get Send Msg to work again.  If this indicates they have PSM installed, then
Brian's fix won't fix their problem, and I have to write a new bug, correct?


17 years ago
QA Contact: sheelar → esther
jgmyers: i'll land the patch if I can get r=/sr= on it.
*** Bug 78716 has been marked as a duplicate of this bug. ***

Comment 71

17 years ago

Comment 72

17 years ago
r=bbaetz on attachment 32332 [details] [diff] [review]
Checked in the patch.

I'm reassigning this bug to the default component owner-- there do seem to be
some remaining problems, but I'm not the right person to track them down.
Assignee: bryner → mscott

Comment 74

17 years ago
What are the remaining problems?

Comment 75

17 years ago
*** Bug 79860 has been marked as a duplicate of this bug. ***


17 years ago
Keywords: mostfreq

Comment 76

17 years ago
What is left to do with this bug?

Comment 77

17 years ago
looks like its still broken for me.  If I go back and set prefs
to "use ssl when available" I start seeing the hang/no message sent
on attempts to send pages with graphics...

possible fixes would be to ignore this pref and never use ssl 
or figure out what is causing the hang and fix the root cause.

Comment 78

17 years ago
chofmann: please report your platform, SMTP server, and whether https: urls work 
for you.  Please set the NSPR_LOG_MODULES environment variable to SMTP:5 and 
report the log output generated on a failed attempt.

Taking bug.
Assignee: mscott → jgmyers

Comment 79

17 years ago
chofmann: please report your platform,


SMTP server, 


and whether https: urls work for you.  

    seem to work fine.   I can log into my etrade account

Please set the NSPR_LOG_MODULES environment variable to SMTP:5 and 
report the log output generated on a failed attempt.

     I haven't checked these logs recently but dialogs show the same thing
     that I was seeing when this problem first occured and I got duped
     to this bug.

Comment 80

17 years ago
Chris are you using a .9 build (which has the problem) or a tip build? Just

Comment 81

17 years ago
tip...  2001050904

I'm trying right now and I'm reproducing.

  set mail
  bring up browser window.
  file | send page
  type in address to send this bug to myself...
  barber pole is spinning and status is "sending message"

here is the  smtp log to this point.   

C:\tmp>tail -f smtp.log
0[7b1ec0]: SMTP entering state: 0
0[7b1ec0]: SMTP Response: 250 Recipient <chofmann@netscape.com> Ok
0[7b1ec0]: SMTP entering state: 7
0[7b1ec0]: SMTP Send: DATA
0[7b1ec0]: SMTP entering state: 0
0[7b1ec0]: SMTP Response: 354 Ok Send data ending with <CRLF>.<CRLF>
0[7b1ec0]: SMTP entering state: 8
0[7b1ec0]: SMTP entering state: 9
0[7b1ec0]: SMTP Send:

after several minutes a dialog pops to say

 An error occured sending mail
 the mail server responded "dredd.mcom.com timing out connection to 
  (my ip address).  Check the message and try again.

then looking in the log this stuff is written out...

0[7b1ec0]: SMTP entering state: 0
0[7b1ec0]: SMTP Response: 421 dredd.mcom.com timing out connection to [208.12.37
0[7b1ec0]: SMTP entering state: 10


Comment 82

17 years ago
then set mail smtp server setting to "never use ssl" and I can send the message
just fine.

Comment 83

17 years ago
Did the client negotiate TLS on the connection or not?

Comment 84

17 years ago
Ok, I was able to reproduce this.  It has nothing to do with images; I was able 
to send a small message containing a small image.  I encountered the problem, 
however, when I tried sending a message with a large attachment over SMTP/SSL.  
It appears to be related to the size of the message being sent.

I suspect this is a bug in the handling of writes that return WOULDBLOCK.  
Should also test appending large messages through IMAP/SSL.



17 years ago
Depends on: 80092

Comment 85

17 years ago
*** Bug 77614 has been marked as a duplicate of this bug. ***


17 years ago
Whiteboard: [nsbeta1+] → [nsbeta1+] blocked on dependent NSS bug

Comment 86

17 years ago
*** Bug 81219 has been marked as a duplicate of this bug. ***

Comment 87

17 years ago
Using 2001050508
Putting SSL to "none" under smtp is a valid workaround
0.9 did not have this problem (i think, i cant confirm if i had ssl to none)
If i leave ssl to "when available" then mozilla crashes when i send mail

Comment 88

17 years ago
Fix to the hang-on-large-messages bug has been applied to the NSS_CLIENT_TAG.

Comment 89

17 years ago
Changing summary and marking FIXED.  This bug now tracks the hanging issue.  
Reopened bug 81219 to track it separately.
Last Resolved: 17 years ago
Resolution: --- → FIXED
Summary: Sending Message fails because of SMTP settings → Sending Message hangs using SMTP/SSL
Whiteboard: [nsbeta1+] blocked on dependent NSS bug → [nsbeta1+]

Comment 90

17 years ago
Using build 2001-05-21 on win, mac and linux:
Creating a new profile, adding an IMAP account
Leaving the Outgoing SSL setting at When Available (which is still the default)
I can send large attachments and do a Send Page of the Netscape Home page and 
abcnews.com   I sent these several times and did not hang up sending.

Used existing account (the one I had to change the SSL setting to avoid this 
bug).  I changed the SSL back to Sometimes and sent msgs with large .jpg 
(475kb), did a Send page 10 times

I also check any differenct scenario listed in the many duplicate bugs.

This bug as originally stated is fixed.  
Note:  per comment on 5-18-2001 bug 81219 is for tracking the existing problem 
with crashing when sending. 

I encourage anyone who commented in this bug or is the reporter of a duplicate 
bug to please try this out.  Those who had to change their SSL setting to Never, 
please try (at least once) changing it back to Sometimes and do a Send Page or 
send with a large attachment. Reopen with specific steps if you still hang.  

Comment 91

17 years ago
Note that the fix to this bug is probably not on the NSS-autoconf branch.

Comment 92

17 years ago
Please note:  in above statment regarding the verification testing, 
correcting the phrasing for the option. "Sometimes" is not the option, it should 
be "When Available". 

Comment 93

17 years ago
I saw this problem again with win32 build on my win98-J system.
Is anybody else seeing this?

Comment 94

17 years ago
I'm running 05-23-06 win32 build.

Comment 95

17 years ago
*** Bug 85338 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.