To reproduce: 1. Alias a secure SMTP host to something other than what its certificate indicates 2. Set your SMTP settings to "When Available" or "Always" and use the host from #1. 3. Enable Norton Anti-Virus Outgoing E-Mail scan 4. Try sending a sample message. Symptoms: All open Mozilla windows (Browser, mail) hang and are unresponsive. Process usage for MOZILLA.EXE grows to 99%. Process must be killed and Talkback doesn't fire. I realize this is probably an issue with NAV rather than Mozilla, but it seemed like Mozilla should have failed gracefully in this case. Thanks! You guys rock.
Reporter, could you specify your build ID?
Severity: normal → critical
Build ID is 2002051006. I'd upgraded to see if I could get rid of the problem so it also existed in my previous build, which was something like 200204xxxx. Also, I've noticed this occurs even if the site certificate is valid, ie. you enter the hostname listed in the certificate. Mail seems to hang whenever a secure connection is specified and the NAV Outgoing E-Mail scan is enabled.
I'm using Windows XP Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a+) Gecko/20020702. The whole mozilla app hangs if I set the mail client to send to a host (properly identified by the cert BTW) and select use SSL. If I clear the SSL pref (after restarting Moz), it goes through. I can send to this same host using Mozilla on a Win2k system. I've created a clean, new profile and I get the same behaviour - as soon as I click send, all processes in Mozilla hang (including browse windows, it won't cleanly exit, I have to end task mozilla).
You know, I put my issue as a separate bug - I'm not using NAV and I'm not having the problem with only the non-cert address.
Confirm on win2k, Mozilla build 2002061104 and NAV 2002 Sending works with SSL disabled, but not with "if available" or "always".
*** Bug 154963 has been marked as a duplicate of this bug. ***
Mozilla Build: 2002052306 / Windows XP Using sendmail 8.12.2 with STARTTLS and having installed a correct certificate If Norton Antivirus is enabled to scan outgoing email mozilla crashes as described! If I do a telnet to port 25 and "simulate" the smtp by hand it looks exactlay like this: C:\>telnet xxxxxx.de 25 220 xxxxxx.de ESMTP Sendmail 8.12.2/8.12.2; Fri, 2 Aug 2002 01:34:21+0200 (MEST) EHLO home 250-xxxxxx.de Hello p5087741A.dip.t-dialin.net [188.8.131.52], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN 250-STARTTLS 250-DELIVERBY 250 HELP STARTTLS 500 Nicht unterst³tzter Befehl. The two lines "EHLO home" and "STARTTLS" are typed by hand the others are responses from sendmail. And now attention: The response to the STARTTLS command comes from antivirus and not from sendmail! It is somehow interesting that the text after the 500 is in german! I got crazy about that while checking my sendmail installation until it got me down to doing a search in the sendmail sources after that german phrase (haha). When antivirus answeres with the "500 Nicht unterst³tzter Befehl." to STARTTLS this leaves the following in the logfile of sendmail: Aug 2 01:41:47 xxxxxx sendmail: [ID 801593 mail.info] g71NYLcm019224: p5087741A.dip.t-dialin.net [184.108.40.206] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA Antivirus did not even send a "quit" command to the smtp-server and just terminates the connection! I think it does not matter if the certificate is correct or not. The problem seems to be that mozilla expects an encrypted connection right after the STARTTLS command and does not check if the smtp-server did respond with an un-encrpyted 500 error message but this is just a guess. I spent lots of hours with this problem a few months ago while installing a new sendmail version. Then, after I got it working, I did not use antivirus for a few months. Now I just installed antivirus again and right after that mozilla crashed when sending mail. I wanted to look why that was not fixed for so long time and saw this bug here. So I just wanted to post my experiences in hope they are helpful! But I also have a question: >To reproduce: >1. Alias a secure SMTP host to something other than what its certificate indicates Are you really shure that antivirus checks for the validity of the certificate ? I'm using my sendmail installation since months and the only think I did was installing my own ca certificate in mozilla and after that I have not had any problems! Even outlook works great with sending by SSL after installing the ca in outlook! How can I check the correctness of the certificate else ?
Yes, recent versions of Norton Antivirus actually intercept outgoing SMTP streams and apparently play with them.
Keywords: mozilla1.2, nsbeta1
Confirming, marking as NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hi. I hit this bug too. -And the assignee (Scott) won't be back 'till January... Occurs even if NAV hasn't been registered (e.g. on a HP laptop with NAV pre-installed, but not yet registered.) Uninstalling NAV, replacing with Mcafee... (Really, shouldn't crashes in Mail, News and the browser be unable to crash each other?)
Norton AV hang also reported in bug 166867. Dup?
*** Bug 166867 has been marked as a duplicate of this bug. ***
Maybe I'm wrong, but if there is a SSL session opened between Mozilla and the SMTP server, and NAV intercepts the data and tries to rewrite it, or reformat it, it's going to corrupt that data, because it can't decrypt the data. What happens when applications other than Mozilla send e-mail in this way? Does NAV hang them, too?
Keywords: mozilla1.2 → mozilla1.3, qawanted
Confirming two things Wong said: 1)The issue is that Mozilla should have failed gracefully in this case. 2)It is not relevant wheher the cert is valid or not. Andrew: yes, is isn't and *shouldn't* be possible for NAV to filter a secure SMTP session from Mozilla. If it was possible, it would be a man-in-the-middle attack on SSL. (Norton should allow a user to send over regular SMTP but take over and make the Internet (post-filter) part of the connection over secure SMTP.) IIRC, some testing I did a while ago showed that Outlook (2000, 2002) fail gracefully when this (trouble with an SMTP connection) occurs. So the bug, restated, is: Mozilla hangs when there is trouble with a (secure) SMTP session. NAV happens to be a reliable way to cause the trouble, which causes the symptom: the hang. Anyone noticed if the session eventually times out, unhanging Mozilla?
I believe that I can offer a simplified test case I discovered by accidently misconfiguring my outgoing SMTP server causing Mozilla to hang. I cannot confirm if the SMTP server I used (as I am unable to configure my own at the moment) is configured or misconfigured for secure connections. I however do not have Norton AnitVirus installed so this should help clear up the NAV issue as I can reproduce this bug without NAV installed. My build and OS: Build: 2002101612 OS: Windows 98 SE Norton AntiVirus installed: No! Test Case: 1. Identify an SMTP server that does not support secure (SSL) connections 2. In the "Outgoing Server (SMTP) Settings" dialog configure the "Server Name" and under "Use secure connection (SSL): select "Always" 3. Select OK to configure the server. 4. Attempt to send an email using the configured SMTP server The result should be Mozilla hanging. I shall next try to confirm whether Mozilla times out and returns.
The original report is of a hang while trying to contact a secure SMTP host. What you just said sounds like a new, different bug. Please consider filing a bug report for it.
Shane, Andrew: Suggest we not adopt Shane's test case, which is appropriate for existing, different bug 98399: http://bugzilla.mozilla.org/show_bug.cgi?id=98399 The bugs are different - IMO: one is about how Mozilla shouldn't hang, no matter what happens, that is demonstrated by using SSL. MozillaMail shouldn't hang MozillaBrowser just cuz a SMTP conversation takes forever. The other is about a specifig bug in SSL that needs fixing.
Mail triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
First, can we get a log of the SMTP transaction? On a different note, is this problem related to this Symantec knowledge base article? http://service1.symantec.com/SUPPORT/nav.nsf/396b6ccde72d4a4d882569fc006071d4/c723dcecc95de93a88256a6200803e5c?OpenDocument
Summary: Sending a message via secure SMTP causes Mozilla to hang when Norton Anti-Virus is enabled and site certificate is invalid → Sending a message via secure SMTP causes Mozilla to hang when Norton AntiVirus is enabled and site certificate is invalid
I was going to send Symantec tech support e-mail on this, but apparently they only accept e-mail at limited hours between M and F. ??? I just want to drop them an e-mail, and because it's late, I can't do that? Anyway, we should contact them. Maybe they can help.
I never got any error message, so I do not think the Symantec article is useful here.
*** Bug 193869 has been marked as a duplicate of this bug. ***
*** Bug 200617 has been marked as a duplicate of this bug. ***
Sorry that I reported the known bug again in separate thread. I got the problem indeed having Norton AV installed. Is it only NAV related? If not, then since it is so oled bug, I would have expected it to go away with 1.3 or latest 1.4a? BTW: with the same settings 1.3b used to work ok for me. Now it seems just not using encryption ever on SMTP is the only easy way out. Cheers,
I think it hasn't been fixed because, as the new mozilla roadmap states: "Mozilla's integrated mail has many fine features, but it suffers from too many integration points with the other apps, and it remains a complicated front end maintained by too few people, most of whom have different day jobs now." Given the (gasp!) radically new direction for Mail given in the roadmap, perhaps all the coding necessary for the switch to the new Minotaur/Thunderbird will incidentally fix this. Besides there is a workaround. Basically no one submitted a patch. I imagine simply better testing/checking of error codes/timeouts would fix this.
The log in comment 7 shows the problem quite clearly. Norton AV is acting as a proxy for the SMTP server. NAV passes the EHLO response from the real SMTP server (which contains "STARTTLS") through to the email client. The email client sees the STARTTLS and tries to use it. Then NAV responds that it doesn't understand STARTTLS. That's a bug in NAV, pure and simple. NAV should either (a) pass STARTTLS traffic through, or (b) filter out the word "STARETTLS" from the EHLO resonse. Because NAV does neither of those things, it appears to the email client to be a broken server, one that claims to handle STARTTLS, but that actually fails if you try it. Now, I'll agree that the core SMTP code should gracefully handle this failure. But let's look past that to the real solution to this problem. Even if the client's core SMTP code did gracefully handle this failure, and reported to the user that the server is not correctly handling STARTTLS, you still haven't sent your email securely, right? NAV has a way to configure it to NOT filter outgoing SMTP mail. The exact details of how to do that vary in NAV from year to year, and even between their standard and "professional" products, so won't be given here. But the ONLY real solution to this problem is to disable NAV's faulty scanning of SMTP email traffic.
Assignee: mscott → nobody
QA Contact: meehansqa
Summary: Sending a message via secure SMTP causes Mozilla to hang when Norton AntiVirus is enabled and site certificate is invalid → secure SMTP hangs when Norton AntiVirus is enabled
FYI, I've had no trouble getting refunds from Norton/Symantec and Macafee/Network Associates et. al. for unresolved bugs (in my case it was for bugs related to compatibility with WinXP's Limited User accounts). Getting a refund if one of their products can't be made to work with secure SMTP shouldn't be a problem either. I am removing the 'qawanted' Keyword-I see no reason for it; email me or put it back if it should there. Nelson:I disagree regarding the 'ONLY real solution'; a better, correct solution is in my comment #14, in parentheses.
Following up on this bug. It's hard for me to verify as I don't use this set of applications anymore. However, I do seem to remember the problem being fixed at some point.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
Product: Core → MailNews Core
I have not seen this for a long time.
You need to log in before you can comment on or make changes to this bug.