Closed Bug 98399 Opened 23 years ago Closed 21 years ago

hang when STARTTLS returns failure

Categories

(MailNews Core :: Networking: SMTP, defect, P2)

Product:
MailNews Core
Component:
Networking: SMTP
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mbabcock-mozilla, Assigned: sspitzer)

References

Details

(Keywords: fixed1.4.1)

Attachments

(3 files)

Proposed fix
1.19 KB, patch
Bienvenu
: review+
mscott
: superreview+
Details | Diff | Splinter Review
Perl script emulating erroneous smtp server
1.16 KB, text/plain
Details
patch v2
1.26 KB, patch
Bienvenu
: review+
mscott
: superreview+
mkaply
: approval1.4.1+
asa
: approval1.5b+
Details | Diff | Splinter Review 
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.
QA Contact: nbaca → junruh
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...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
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?
Severity: normal → major
Keywords: nsbeta1
OS: Linux → All
Priority: -- → P2
QA Contact: junruh → esther
Hardware: PC → All
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.
Severity: major → 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).
Keywords: qawanted → hang, mail2, mozilla1.3, nsCatFood, verified1.2
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."
Assignee: mscott → sspitzer
anyone have any suggestions on how I can reproduce the hang?

(not luck yet with my debug build from 12-19-2002)
Status: NEW → ASSIGNED
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
Keywords: hang, mail2
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...
Target Milestone: --- → mozilla1.3beta
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.
Target Milestone: mozilla1.3beta → ---
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-
Keywords: nsbeta1 → 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
Summary: STARTTLS dealt with wrong → hang when STARTTLS returns failure
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.
Attached patch Proposed fix — — Splinter Review 
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.
Flags: blocking1.5a+
Flags: blocking1.4.x+
Attachment #114930 - Flags: review?(bienvenu)
Comment on attachment 114930 [details] [diff] [review]
Proposed fix

r=bienvenu
Attachment #114930 - Flags: review?(bienvenu) → review+
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.
Flags: blocking1.5a+
Flags: blocking1.4.x+
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.
Attachment #114930 - Flags: superreview?(mscott)
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.
Attachment #114930 - Flags: superreview?(mscott) → superreview+
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.
Attached patch patch v2 — — Splinter Review 
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.
Attachment #129358 - Flags: review?(bienvenu)
Attachment #129358 - Flags: superreview?(scott)
Attachment #129358 - Flags: review?(bienvenu)
Attachment #129358 - Flags: review+
Attachment #129358 - Flags: superreview?(scott) → superreview+
requesting approval for 1.5b
Flags: blocking1.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.
Attachment #129358 - Flags: approval1.5b+
Comment on attachment 129358 [details] [diff] [review]
patch v2

This patch applies to the 1.4 branch, too. Should we land it there?
Attachment #129358 - Flags: approval1.4.x?
fix checked in, thx, Christian.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Flags: blocking1.5b?
Comment on attachment 129358 [details] [diff] [review]
patch v2

a=mkaply for 1.4.1
Attachment #129358 - Flags: approval1.4.x? → approval1.4.x+
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?
Keywords: fixed1.4.1
Blocks: 224532
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: