From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 BuildID: 2001080104 When Mozilla is configured to use TLS "when possible", it should handle failures gracefuly, but doesn't. > 220 mail.fibrespeed.net ESMTP < EHLO fibrespeed.net > 250-mail.fibrespeed.net > 250-PIPELINING > 250-STARTTLS > 250-AUTH LOGIN CRAM-MD5 PLAIN > 250 8BITMIME < STARTTLS > 454 TLS not available After receiving that message, Mozilla hangs. Reproducible: Always Steps to Reproduce: N/A Actual Results: N/A Expected Results: Fail gracefully or fall back to normal SMTP.

Michael, is this still happening in recent builds? Sorry it's stayed unconfirmed long enough that the question is necessary.... :(

adding qawanted keyword. Could someone with access to a SSL smtp server please test this? it worksforme on a non-ssl server...

This bug stills exists if you try to contect to a secure server. It does not matter if you select if possible or always.

This bug exists for me when I try to connect to an insecure server on 0.9.9. However, for a properly configured SMTP server it works fine.

I'm seeing Mozilla 1.2a (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910) hangs after getting the response back from a EHLO when configured to use a specific SMTP server for an account with TLS on or optional. With it off, the mail goes through fine. The SMTP server is MS Exchange 2000. A packet sniff shows this traffic (-> indicates Mozilla sent traffic): 220 madonna.advsys.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.5329 ready at Fri, 20 Sep 2002 16:39:41 -0400 ->EHLO advsys.com 250-madonna.advsys.com Hello [192.35.38.110] 250-TURN 250-ATRN 250-SIZE 250-ETRN 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-8bitmime 250-BINARYMIME 250-CHUNKING 250-VRFY 250-TLS 250-STARTTLS 250-X-EXPS GSSAPI NTLM LOGIN 250-X-EXPS=LOGIN 250-AUTH GSSAPI NTLM LOGIN 250-AUTH=LOGIN 250-X-LINK2STATE 250-XEXCH50 250 OK

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

IMHO: Bug 114225 (and perhaps 117640, 132559, 132801) could be marked as a duplicate of this bug; (114225 is mis-categorized as an enhancement, BTW) Unfortunately, these are assigned to someone on sabbatical. Confirmed in Windows XP, Mozilla 1.2b by two people on above bug (114225): The bug is: smtp over ssl doesn't work to port 465 (works to port 25!) in layman's terms; in technical terms, it's that on port 25, the conversation starts unencrypted, and then encyrption is turned on with STARTTLS, with port 465, the SSL/TLS handshaking starts immediately (and due to this bug, fails!), as nelsonb explains in the above bug's (114225's) comments.

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

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

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

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

Esther, can you reassign this bug someone who is not on sabbatical?

Just upping to critical based on comments received by E-mail; http://bugzilla.mozilla.org/bug_status.html#severity defines: Critical: crashes, loss of data ... A hang causes loss of data - e.g. for people who keep lots of windows open. So I think it's critical. 145913 (a duplicate) is marked critical.

This looks to me more like a design flaw than a proper bug - it seems that the designers of Mail never took SSL-encrypted SMTP connections into account. STARTTLS is attempted, but if that fails, Mail defaults back to normal SMTP. Of course, if SMTP is running over an SSL-encrypted port, then neither will work, and Mail hangs waiting for the welcome message from SMTP. The best way to get around this, I think, would be to add another configuration option to control whether you want to use STARTTLS over SMTP or SMTP over SSL, and add another case to nsSmtpProtocol::Initialize() (see line 322 of ~/source/mailnews/compose/src/nsSmtpProtocol.cpp) and other appropriate locations in that class. Of course, this would require minor changes to the GUI, the configuration parser, and possibly other components as well.

I would rather that there be multiple bugs filed for this problem (if there's agreement, I will submit new ones). 1) This bug; if STARTTLS is not accepted (as in my original report), Mozilla should fail gracefully *if* the user has selected TLS-only. If Try TLS Then Normal, then Mozilla should resume where it left off with an EHLO, etc. 2) A new bug w.r.t. starting on the encrypted port as described by Rennie in comment #14. 3) A bug w.r.t. how these options should be presented to the user, dependant on #1 and #2 above, filed under Prefs UI.

I also can't support Rennie's idea of making the UI more complicated. There's no need for the add'l option, or add'l bugs. Why should the user care about which is used? I think they shouldn't; it should just work. (Not important, but I don't see any theoretical reason why use STARTTLS over SMTP and SMTP over SSL couldn't be used together. Paranoid, and useless, perhaps.) Also, some suggested keyword changes - Thanks for the Priority update, Michael. Remove qawanted keyword; this is thoroughly reproducible and reproduced. Add verified1.2, nsCatFood, mozilla1.3, mail2, hang - hope this gets it the attention it deserves; all appropriate, per http://bugzilla.mozilla.org/describekeywords.cgi.

I don't think it would make things more complicated, but it should be a seperate bug if someone feels strongly about it. I do feel that we must consider actual security to be paramount after functionality if we're offering secure connections at all, and therefore default on the side of caution. There's no point in implementing secure protocols and then allowing them to go to an insecure mode without user knowledge.

While the architects debate the merits of whether to have it automagically work or to have a modification in UI design alerting the end user of the product a choice and ultimately informing them of there options, consider this situation that Earthlink.net enforces: Port 25 for SSL fails period. It happens to be that way one for the fact that SPAM is flooding the **** out of their pipes which lead me to have my remote domain's system's engineer who routes our mail via SSL and postfix to with certificates to use Port 465. Until you get a working model implemented, and started through the QA channels no one I know expected 465 to work will update. I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021023 and within Debian I'm using the latest but I only check mail via Squirrel until Mozilla if compliant. Having an interactive options list of either port 25 or 465 with some alert comment that states, "Port 465 is for SSL users so please be sure to check with your Admin before selecting SSL to fetch your IMAP email. If you are sure then please select Okay. If not select Cancel." The result having the Mail settings for SSL now listing Port 465 to fetch your mail. And since we are dealing with how Mail gets configured, explain to me how is it that when you set up a new Profile/Account for email you cannot configure SSL IMAP'd from the beginning so that when you are done Email maps your root directory on the IMAP server and all accompanying sub directories, then fetches any new updates to INBOX after authentication has been verified. Just a few thoughts.

Identifying ports directly should _not_ be done. If any "intelligence" is programmed into the browser, it should be at the prefs level of "You have specified port 443, does your ISP support secure connections?" with a button, perhaps, of "Test for secure connection support" that does a test connection and sets the response accordingly. I get ticked off whenever I try to connect to port 1080 on a server because of this ... (try it).

New bug 185631 filed for auto-detecting TLS support from prefs.

Bug 185662 submitted to cover additional prefs option. Voting should show if anyone is actually interested in this.

Fixing keywords (was asleep at the wheel there I guess).

investigating. to clarify, I'm investigating the hang. I agree with Michael's comment in http://bugzilla.mozilla.org/show_bug.cgi?id=98399#c15, we should split this bug apart. I'm looking into: "This bug; if STARTTLS is not accepted (as in my original report), Mozilla should fail gracefully *if* the user has selected TLS-only. If Try TLS Then Normal, then Mozilla should resume where it left off with an EHLO, etc."

anyone have any suggestions on how I can reproduce the hang? (not luck yet with my debug build from 12-19-2002)

Matthew said: > I got [bug 145913] confused with this > bug and started thinking that both caused hangs, but this bug is NOT > exactly a hang-causing bug; it just waits forever instead of work. These are still two different bugs as well; how it deals with STARTTLS failing on port 25 (this bug) is not the same as how it deals with SMTP over TLS on port 465 (file a new bug).

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

not a hang, according to Matthew Elvey. updating keywords. this sounds related to bug #137570

sorry, I mean bug #158059 matthew tells me: "The "Sending Messages" pop-up just stays up forever, but the other application windows don't freeze, at least for me in 1.2.1, on XP, and I'm the one who had the 'hang' keyword added, so it's not really what I'd call a hang."

I hate to spam the bug, but last time I tested this (when I submitted my bug) the entire application froze if it saw that the server supported STARTTLS, then tried to do a STARTTLS and the server rejected it. Just FYI. This may no longer be the case (I added 'hang' under recommendation of another person).

with help from matthew elvey, I'm able to reproduce this problem. looking into it...

to summarize, there are two problems. 1) if you've configured for "always", it's possible to send over the clear. (bad) 2) if you've configured for "always", and tls isn't supported, the message will never send, forcing the user to cancel. (on win2k, I don't see the application hang, but this might be what the reporter was referring to)

> 1) if you've configured for "always", it's possible to send over the clear. (bad) actually, I not seeing that. the test account I'm using appears to support TLS. so I don't think I'm sending over the clear. nsSmtpProtocol::ProcessAuth() looks like it would do the right thing if I tried set to "always" and tried to send to a server that didn't support TLS. am I missing something?

Seth: Well, keep in mind that the bug is: When Mozilla is configured to use TLS "when possible", it should handle failures gracefuly, but doesn't. (quoted from the initial bug submission; this causes a hang) There is *ALSO* the problem that you list in your "2)" (which doesn't hang, it just doesn't work) (I emailed you (Seth) privately about this to try and clear up some confusion; see my most recent (Jan 12) email.)

Bug 189281 Submitted. It's almost the same as "2)", except that 189281 occurs when TLS *is* supported.

Michael, I haven't read each word within this bug report, but let me avoid some confusion: Mozilla does not support that is usually used with port 465. Mozilla does not support SMTP wrapped in SSL, which could be described as SMTP over SSL. Whatever port number you enter for the configuration, Mozilla will only attempt the STARTTLS extension, which is different from SMTP over SSL. To explain in more detail: SMTP over SSL (which we don't support) works like this: - client connects to server - client immediately initiates a SSL handshake - once the SSL handshake is done, the standard SMTP protocol is spoken over the encrypted channel STARTTLS (what we support) works like this: - client connects to server - client starts the SMTP hello sequence without using any encryption - if Mozilla has "use secure sonnection" in it's SMTP configuration enabled, it should try to find out whether STARTTLS is supported by the server. - if STARTTLS can and should be used, the Mozilla client should send the STARTTLS command to the server - next, client and server will initate a SSL/TLS handshake over the already opened socket. - once the SSL/TLS handshake is done, the SMTP dialog continues over the now encrypted channel Looking at the initial problem report, I would suspect two problems come together. It seems to me, the mail server is configured incorrectly? In its reponse, the mail server claims to support STARTTLS. However, when Mozilla sends the STARTTLS command, the server bails out with an error message. That is a problem on the server, IMHO. But next it is said the Mozilla client hangs. This looks like a problem on the Mozilla client side. I'm not sure if this hang is happening within the generic SMTP code, or whether it happens at the encryption protocol layer. Re how this bug could be reproduced: We might require a misconfigured mail server. I just connected to the mail server that was shown above, mail.fibrespeed.net. However, it does no longer behave as reported, it does not longer report it would support STARTTLS.

thanks for the explanation, kai. I'm not seeing the hang, but I am seeing the compose window "spin forever". I have a patch started to add support for setting the network timeout for tcp connections. that would fix the problem where the compose window spins. (note, OE has this feature and the pref UI for it. see bug #189363 for that.) Is this still critical? clearing target milestone, I won't be able to get to this for 1.3 beta.

kai, do you know if the decision to not support SMTP over SSL a purposeful one? (I can't remember) any objections about spinning up an RFE bug about supporting "SMTP over SSL"? notes: 1) if we were to do that, we'd have to figure out the UI (or to decide to make it a hidden pref, to do STARTTLS or SSL. 2) I don't think we'd be adding support for that any time soon

triaging, nsbeta1-

> do you know if the decision to not support SMTP over SSL a purposeful one? (I > can't remember) I wasn't yet involved in Mozilla at the time this feature was added, so I don't know. But I suspect, SMTP over SSL is only rarely used. I personally know only one public provider that supports it, and couldn't find any other when I researched a while back. > any objections about spinning up an RFE bug about supporting "SMTP over SSL"? No. However, this will most likely require a tricky UI discussion :-) A while back, a feature was added to allow SMTP over an alternate channel. However, it was argued, the configuration for the alternate port should not be filled with "25" by default. It was argued, if Mozilla should ever implement the "message submission protocol", the application should be able to distinguish, whether a user explicitly configured port 25, or whether port 25 is used because that's the default port. That's why the SMTP dialog has an empty port field by default. (The idea is: If the user explicitly configured port 25, we woudln't automatically try the message submission protocol (once supported). If the user has not configured a port explicitly, we were fine to try it). So, up to now, we don't have to deal with automatic port number switching in the smtp dialog, like we are doing it for other mail protocols. However, by supporting SMTP over SSL, we would have to switch from 25 to 465 when the user checks SSL. Of course, a solution can be found, by I predict it will be tricky. cc'ing jgmyers, because he was involved in the discussion at that time. > 1) if we were to do that, we'd have to figure out the UI (or to decide to > make it a hidden pref, to do STARTTLS or SSL. I'm against a hidden pref. A user might also have multiple accounts with multiple SMTP servers, which makes this tricky. In the end, if users really *must* use SMTP over SSL, they can already do so by using external tools like stunnel. Because hidden prefs are for experienced users, and experienced users already can solve this problem by other means, I think we should go for a full solution with UI. > 2) I don't think we'd be adding support for that any time soon ok

If offshoot Bug 189281 isn't a duplicate of this bug, then most of the bugs that are marked as duplicates of this one aren't; they're dupes of Bug 189281. (Anyone want to 'confirm' Bug 189281 for me?) Please comment on this/how this should be handled. I'll move 'em all over in a few days if there are no suggestions otherwise. Perhaps they should be considered as part of this bug (though this isn't what its creator wants.) Kai? Seth?

Matthew, I'd like to get this straight. I believe both this bug and bug 189281 are confusing. We should clearly distinguish between the problems we are trying to solve and possibly have separate bugs for each. Problem 1: A "Mozilla hangs" bug. It is a bug that Mozilla hangs when the user tries to configure a SSL port as a destiation. That bug should only fix the problem we are hanging. That bug should probably get the highest priority, because it is a real problem if the application hangs. Problem 2: A "feature request" bug. A bug that suggests to implement the new protocol "SMTP over SSL". It is not a bug that Mozilla doesn't support this protocol. It's a missing feature.

Changing Summary, was: STARTTLS dealt with wrong

The port 465 protocol is bug 135357

Kai, thanks for piping up. Certainly, this bug has become very confusing. As defined in the original submission, this bug should be a WONTFIX, or P5: we shouldn't care about supporting a SMTP server that provides false information: advertises support STARTTLS when it really doesn't support it (per your Comment #35, above). The other bugs mistakenly marked duplicates have added to the confusion (and that's partly my doing). I don't know why the bug I opened is confusing to you. Bug 135357 is a hang, according to its submitter, Andy Willis. Bug 189281 is not. (One has been marked as a dupe of the other.) Both bugs are due to lack of a SMTP over SSL feature? It seems servers that support STARTTLS on 465 don't work either. (See my simutaneous comment on Bug 13537.) HTH. This stuff is much more complicated than it seemed initially!

Certainly a server advertising STARTTLS but returning a 4xx failure is being stupid, but it is legal protocol.

Err.. I meant "my simultaenous comment on Bug 135357." - Seems like a new bug is in order, per my comment there, which would be: "Secure SMTP protocol *using STARTTLS* broken on port 465". Not sure what the highest priority fix should be - get Secure SMTP working on port 465 with STARTTLS, on port 465 with old-style SSL, on port 443, or on port 587 per RFC 2476. SSL on 465 seems to have the most de facto support currently, but is deprecated. STARTTLS on 465 would probably be a relatively easy fix, but is deprecated. Comments?

I have no idea what you mean by "STARTTLS on 465". The idea, like the idea of running any variant of SMTP on 443, makes absolutely no technical sense.

Since you asked here, I'll reply here. My comment on Bug 135357 should make it clear, and the surrounding discussion shows that others get it. *>telnet mail.attbi.com 465 ehlo foo.com 250-STARTTLS STARTTLS <secure session should start, IMO, but doesn't with Mozilla> Understood? Using 443 doesn't make much sense to me either, but someone suggested it, so I put it in the running. Seems a non-starter/out of the running. Thanks. Posts on ietf-apps-tls indicate that the deprecation and removal of 465 from the IANA list was handled in a hasty and abnormal manner; it was removed based on content in an internet-draft, not on an RFC of any kind. Furthermore, that content is not in the RFC that the internet-draft developed into! I think IANA made a mistake unregistering 465. Please be constructive. What I'm trying to resolve, and asking for suggestions with: 1)465 is a de facto standard port for secure SMTP. When attempted with Mozilla, it fails in a way that leads to unhappy users. 2)Support for an alternative to port 25 is needed for secure, username+password login based SMTP. The reasoning against a separate port falls apart when there is a login over he secure connection, as it implies a prior relationship. Is there support from ISPs and MTA/MSA* makers for port 587*? *described in RFC 2476. I'm still not sure what the highest priority fix should be, and don't know what you think should be the solutions to these problems either.

The port 465 protocol requires the client to immediately start with an SSL handshake initiation packet. The telemetry shown in comment #48 would never happen because the server, expecting an SSL handshake packet, would choke upon receiving a plaintext "EHLO". STARTLS on port 465 makes no technical sense because port 465 by definition always runs SSL from the get-go. Port 465 has no relevance to this bug. Attempts to take this bug off-topic are not constructive.

"STARTLS on port 465 makes no technical sense..." OK, true. Thanks for clarifying. Minor point: "The telemetry shown in comment #48 would never happen" Well, sorry but it does happen. I just verified it again. You can try it yourself. (Though once I had to type the ehlo command twice). c:/> telnet mail.attbi.com 465 ehlo foo.com (not echoed) 220 rwcrmhc51.attbi.com - Maillennium ESMTP/MULTIBOX rwcrmhc51 #2 250-rwcrmhc51.attbi.com 250-7BIT 250-8BITMIME 250-AUTH CRAM-MD5 LOGIN PLAIN 250-DSN 250-HELP 250-NOOP 250-PIPELINING 250-SIZE 10485760 250-STARTTLS 250-VERS V04.50c++ 250 XMVP 2 So, it SHOULDN'T have happened, so "Secure SMTP protocol *using STARTTLS* broken on port 465" isn't a sensible bug. (OTOH, I'm surprised that it doesn't work currently, because I'd expect that given a server that supports STARTTLS on port 25 and 465, as mail.attbi.com does, MozillaMail be able to connect to it.) So a process of elimination continues: 1)465 is a de facto standard port for secure SMTP. When attempted with Mozilla, it fails in a way that leads to unhappy users. a)Mozilla should support SMTP over SSL on port 465 (bug 13537). b)Until that happens, and IF it'll be a long time 'till that enhancement is made, Mozilla should provide an informative error msg (bug #DNE) instead of loop forever. 2)Alternatives a)Comment #39 implies that MozillaMail does not support "message submission protocol" on port 587, so then it's not yet an alternative, but I suspect this does work. *Does* it work? Not with www.fastmail.fm or mail.attbi.com. b)Use port 25, if your ISP doesn't block it. c)Use SMTP over SSL, by using an external tool like stunnel. No comments/action on reassigning the mismarked duplicates or lowering the priority of this bug. Anyone?

I have read this thread about SMTP failing on port 465, and I have come to the conclusion that there is still confusion abou this. I have just installed the latest version, V1.2.1 on a system running XP Pro. I use webmail from my provider, and I *MUST* use port 465. Port 25 is blocked. I get the feeling that the attitude exists that if someone needs to get this to work, they must use stunnel or some other way to get their mail to send using TSL. Yes, it is true that most of the people on this thread and are able to do this, but if we continue with that attitude, IE will continue to be the web explorer of choice, and any Mozilla based product will continue to be viewed as an application for "web-heads" or "geeks". I think it is imperative that the problem be looked at and fixed, if this project ever hopes to gain momentum. We as developers and administrators need to be aware that the reason we exist is for the users, and not in spite of them! Now, getting of my soapbox, I am a Senior System Administrator on Sun and IBM systems. After hours, I run Redhat 8, and also Windoze, but only because the applications I need, do not exist in the Linux/Unix world. I know of several people like this, and I hope it changes soon, for the sake of all of us. Let us not lose sight of our goals and purpose. Respectfully submitted, Dale Edman

This bug has nothing to do with port 465.

Tested against a working STARTTLS server. Don't know of a server that advertises STARTTLS, but for which a STARTTLS command returns failure, so can't test the added code.

Dale, your comments would be appropriate for Bug 135357. You should repost them there. Ditto for Mark's comments. Given all the confusion over what this bug is about, I tried to identify what John fixed. It looks to me like with his fix, we'll get one of the Expected Results in the initial bug report: Fail gracefully or fall back to normal SMTP. This is good, of course. (Yay!) It'll be tough to test, as John points out. I looked at the attachment and code at http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsSmtpProtocol.cpp It won't adress any of the other stuff discussed in this bug thread; it won't fix the many bugs that are marked as duplicates of this bug but are really dupes of Bug 135357. It's fine that it doesn't address these, BUT SOMEONE should re-file them. I just want to point these things out to the other folks on CC, etc.

STARTTLS is typically used nowadays on port 587, with is an RFC-canonized port for Message Submission, and is to be used by MUA's to submit mail. Does this mean that STARTTLS failing on 587 would exhibit this bug, not just port 25 (or for that matter, ANY port other then 25)? Incedentially, port 465 is considered by many to be deprecated now - one of the primary reasons it is still used is that MS Outlook prior to Outlook XP have a bug where if you enable Secure sending, it assumes SSL to start on connection, and doesn't negotiate it. Outlook XP and later fixed this bug, and can now connect to a "standard" TLS-based SMTP agent. Here, we run three mail ports. 25 (for standard MTA traffic), 465 (for outlook < XP) and 587 (for all other MUA's).

STARTTLS failing on port 587 would trigger this bug.

The use of port 465 for SSL-based SMTP (SMTPS) was revoked in November, 1997. The revocation was done in accordance with IETF and IANA standards, which require assigned port numbers to have an Internet Draft or RFC (or other published standard that the IETF could adopt as a standard if they chose to do so) supporting their use. The Internet Draft that revoked the use of port 465 was a revision of a previous draft that had requested the use of that port. After further modifications, the draft became RFC 2487 in January 1999 and was superseded by RFC 3207 in February 2002. There is no other current RFC or Internet Draft supporting the use of port 465 for SMTPS. The members of the Internet Mail Consortium, the folks who developed drafts and RFC's reviewed the use of port 465 last year and decided not to reactivate the port for SMTPS. Unless the IETF appoints some other group to assume responsiblilty for SMTP and Secure SMTP issues and proposals, it is highly unlikely that port 465 will be reinstated for SMTPS. Due to firewall issues, I also offer SMTP connections on three ports: port 25 for connections from other SMTP servers, 465 for connections from pre-XP Outlook users and another port for all other users. I can also confirm that a STARTTLS failure on a port other than 25 will trigger this bug.

Please hurry - I have sendmail with stunnel installed and I have to still use Outlook Thanks in advance

if you have a sendmail server running, why don't you just enable TLS on port 25 or MSA (587)? Then any TLS-enabled client can use SSL/TLS to connect. The only reason one should *intententionally* use port 465 IMHO is if you *have* to support Outlook prior to 2k (Outlook XP corrects the problem of expecting SMTPS on ports other than 25).

For the third time, this bug has nothing to do with port 465. The previous three comments were counterproductive.

*This* bug has a proposed fix, isn't controversial, and hence should make its way into the next alpha, as I see it. Indeed, the previous several comments are irrelevant to this bug. Discussion about supporting secure SMTP on port 465 (using SSL not STARTTLS) - Bug 135357 - should go there - I address the misinformation in the comments regarding the port 465 de facto standard there. (Randy, Ken) (Besides, if this bug gets closed, people will mostly stop mis-posting to it, as it won't pop up after a default search.) FOR THOSE WHO ARE SKIMMING: *DO* *NOT* POST TO *THIS* BUG ABOUT PORT 465! See Bug 135357 instead.

Seth (module owner), please review this patch.

You may want to set a review request flag on the patch asking seth for review... That's more effective than making comments that will be lost in the other bugspam he gets.

Testing and review would be helped if someone could point to an accessible SMTP server which triggers the hanging bug. The SMTP server does not need to permit relay.

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

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

> Testing and review would be helped if someone could point to an accessible SMTP > server which triggers the hanging bug. The SMTP server does not need to permit > relay. To set up a test environment: install an(y) MTA (in my case it's qmail), configure it to use SSL over SMTP, and let the configuration point to a non-existing certificate. That triggers a 400+something response, which in turn causes MailNews to hang. Sorry, but this is as much help as I can give.

For testing: Then someone could try using fastmail.fm's SMTP server with a non-canonical name. mailhaven.com, for example, has an ssl cert set up for it, BUT it's signed for www.fastmail.fm! It is an smtp server for any non-free account user; I'm sure they'd provide a free accout for someone trying to test this bug (mail webmaster@!) Actually, if the "to" is a fastmail user, anyone can use it, I think, even on port 465. I don't have a copy of mozilla with this fix applied, or I'd test myself.

On mailhaven.com's SMTP server, the STARTTLS command returns success (220).

Proposed fix (attachment #1 [details] [diff] [review]) fixes it for me: connection terminates, error message (too generic, though) appears. Add to whishlist: give a more precise error message.

Comment on attachment 114930 [details] [diff] [review] Proposed fix r=bienvenu

Comment on attachment 114930 [details] [diff] [review] Proposed fix r=bienvenu

sebastian: only Mozilla drivers are authorized to set (+) blocking flags. You can request (?) blocking status.

can't see this feature anywhere. why is this allowed then? maybe a bug in bugzilla? this issue exists since nearly 2 years now. it's marked as critical but no one seems to have any interest in fixing it. why is mozilla the only mail software not supporting this? even worse: it pretends to support this but simply fails. any email-software i know supports this properly, even complete **** like outlook'98.

Nohn, just FYI: you probably mean to be groaning about/voting for Bug 135357 (for which I just set the blocking flags to ? - 465 is a de facto standard port for secure SMTP. When attempted with Mozilla, it fails in a way that leads to unhappy users.), and/or Bug 114225. Bug 145913 is related (but not the same) too. This bug seems, due to erroneous comments, to be Bug 135357 but it isn't; the votes for this bug are probably mostly meant for Bug 135357, which has half the votes. Still, this bug's fix is a good fix.

I'm going to be away from my desk for a month, so someone else will have to drive the landing of the fix.

Can we push this along a bit? Mscott (or other superreviewers)?

I asked in #mozdev and #thunderbird yesterday (during PDT biz hours): Any drivers or reviewers around? I'm trying to figure out what it takes to get MailNews/Thunderbird bugs with tested fixes into 1.5, such as http://bugzilla.mozilla.org/show_bug.cgi?id=189289 bug 189289, and http://bugzilla.mozilla.org/show_bug.cgi?id=98399 bug 98399 [edit: and http://bugzilla.mozilla.org/show_bug.cgi?id=135357 bug 135357 ]. They've been sitting around with review (sspitzer@netscape) flags set for a while now. Isn't the timing good now for these kind of fixes to go into the trunk? Several people's pinging of the module owner has been ineffectual. I see thunderbird 0.1 is imminent, per the headline at http://www.mozillazine.org/... A checkin of these fixes into the trunk would not impact this, I think, since it's already branched. ( per mscott's "If we uncover issues such as nasty mozilla trunk instability or regressions, then we'lll re-spin these bits with just those changes. ") The silence was deafening. I guess mailing drivers@mozilla is the next step up the chain. Seems to me that these should get in while the timing is good.

Dilettantish modified Perl script (original at http://bugzilla.mozilla.org/attachment.cgi?id=119963) for simulating an erroneous server to reproduce this bug. But it does what it should do.

I don't recommend to use Johns fix from comment #53 (at least not unmodified). The original code and the fix containing a bug which prevent sending mail when continuing after STARTTLS fails. ProcessAuth() and the fix contain m_flags = 0; which discards all AUTH flags from the initial 250. Reset to the initial state and discard any knowledge from the server is needed if TLS handshake has been completed (chapter 4.2 of RFC 3207). But if we do so even if TLS fails, we'll never try any authentication (we forget what's available) and probably fail because the server requires authentication first. I made a few changes. Removed two of the m_flags = 0, added BackupAuthFlags() to empty the backup too (the old values in the backup shouldn't be a prob but it's cleaner this way I think). Additionally I rearranged the code so that fail of sslControl->StartTLS() doesn't close the connection but continues as the server answered with 454 before. What I suggest further on is to add a special error message if TLS failes but the user insists on SSL always. Currently it fails with "Unable to connect to SMTP server. The server may be down." We should maybe explicitly say that no SSL was available, not wrong things like server not available.

One reason for the confusion of people in believing this bug is related to SSL over port 465 is the fact that the Known Issues points to this bug report when it talks about such problems. Someone might want to update the Known Issues http://www.mozilla.org/releases/mozilla1.5a/known-issues.html#smtp to either describe this bug correctly or (preferably) to point to Bug 135357.

Mabry, good point, I have forwarded your suggestion to Mozilla drivers, and also sent them a blurb that could be used as a replacement.

requesting approval for 1.5b

Comment on attachment 129358 [details] [diff] [review] patch v2 a=asa (on behalf of drivers) for checkin to Mozilla 1.5beta. This needs to land quickly (today or tomorrow) if it's gonna make beta.

Comment on attachment 129358 [details] [diff] [review] patch v2 This patch applies to the 1.4 branch, too. Should we land it there?

fix checked in, thx, Christian.

Comment on attachment 129358 [details] [diff] [review] patch v2 a=mkaply for 1.4.1

request to reopen this one. I just downloaded 1.5 beta Build 2003082704. I tried sending SMTP mail over port 465. My smtp setting is always use ssl. Still hangs... IMAP Is fine over port 993. I cannot use 25 because the port is blocked. I had my security guy check the logs and port 465 is open. I was able to get to it via: openssl s_client -connect services.cse.ucsc.edu:465

Robert, what runs on your servers port 465? SMTP over SSL or STARTTLS? From the port number I guess it's SMTP over SSL, and therefore this is the wrong bug for this. Please go to bug 135357 for this issue.

Christian, Yes, I was using SMTP over SSL and I will follow the other bug, thanks. I also tried port 143 because our server also supports STARTTLS on port 143, that is also giving on error (unable to connect to STMP server) but it doesn't hang. BTW: unencrypted SMTP is working on port 587, so I have the correct password.

Does someone want to get this in 1.4 or should I do it?