Last Comment Bug 135357 - (smtps) Implement Secure SMTP port 465 protocol, using SSL, not STARTTLS
(smtps)
: Implement Secure SMTP port 465 protocol, using SSL, not STARTTLS
Status: RESOLVED FIXED
: imap-interop
Product: MailNews Core
Classification: Components
Component: Networking: SMTP (show other bugs)
: Trunk
: All All
: -- enhancement with 11 votes (vote)
: ---
Assigned To: Christian Eyrich
: Sheela Ravindran
Mentors:
http://www.eyrich-net.org/mozilla/pre...
: 114225 132559 173415 189281 211426 214660 215829 217944 223976 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-04-03 21:20 PST by Andy Willis (abwillis)
Modified: 2009-01-22 10:17 PST (History)
37 users (show)
asa: blocking1.4.1-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Patch v1 (8.36 KB, patch)
2003-02-22 20:05 PST, Kai Engert (:kaie)
no flags Details | Diff | Splinter Review
Screen Shot of Patch v1 (14.09 KB, image/png)
2003-06-18 14:30 PDT, Kai Engert (:kaie)
no flags Details
Patch v2 (11.89 KB, patch)
2003-06-18 16:47 PDT, Kai Engert (:kaie)
no flags Details | Diff | Splinter Review
Screen Shot of Patch v2 (13.99 KB, image/png)
2003-06-18 16:47 PDT, Kai Engert (:kaie)
no flags Details
Screenshot of changed UI for Patch v2 (8.83 KB, image/png)
2003-09-13 12:48 PDT, Christian Eyrich
no flags Details
Patch v3 (11.43 KB, patch)
2003-09-29 13:42 PDT, Christian Eyrich
mozilla: review+
Details | Diff | Splinter Review

Description Andy Willis (abwillis) 2002-04-03 21:20:20 PST
I am attempting to get smtp to work through my ATT high speed cable service when
outside their network.  If I am outside their network they require secure smtp
access through port 465.  They only give instructions for Outlook express but
they are fairly simple.  I have to put my email address in for my email address
and my reply address.  I also have to choose ssl connection and select that
userid and password are required and to put in my full email address for the
userid.  POP access is working fine and I can even post to newsgroups but when I
try to send regular email the transfer just hangs like something is being waited
for.  I tested on outlook express and I got a pop asking for userid/password
field I never get from mozilla.  I tried to test on mozilla on my wintendo98
system but I can't get it to allow me to set the port for smtp, I think I will
have to uninstall netscape6 as it appears to be using its profile and I can't
get it to use its own profile on that platform.
Andy
Comment 1 Vadim Berezniker 2002-04-03 21:27:52 PST
The feature is already present.
The server field does not allow you to use host:port syntax you might be used to.
More recent builds have a port entry box.
Please test with a nightly and reopen if you don't agree.
Comment 2 Andy Willis (abwillis) 2002-04-03 21:48:44 PST
Please reread the problem as your resolution doesn't address the problem.  I
entered the port 465 on this system and I was running a nightly from 3-26(which
had the field which was not the problem reported) and am now running nightly
from 4-3.  When no port is entered or the wrong port is entered then I get an
immediate error, but when the correct port is entered it hangs.  I also put a
new nightly on the wintendo system but it is not allowing me to enter a port on
it cause it is somehow pulling its profile information from the netscape6 and
creating a new profile didn't help but will trace that down as time allows as it
is not a primary system (I knew it should have allowed me to enter a port which
is part of the reason I knew that it was somehow pulling from netscape).  
Andy
Comment 3 Andy Willis (abwillis) 2002-04-03 21:57:38 PST
What it acts like is that it isn't sending the login information and is waiting
for the server to request it.
Comment 4 Andy Willis (abwillis) 2002-04-03 22:49:18 PST
I stated that the wrong port gives an immediate error but I realized I had only
tested port 25 (which is the default apparently) and if I have 25 in the port
field it fails immediately (465 is required) but anything else in the port field
causes the same hang.  Besides the correct 465 I also tried 46 and 995 now. 
Just for the heck of it I did try the address:port both with 465 in the port
field and with the port field blank.  I will try from another installation on
w2k tommorrow that hopefully isn't corrupted like the w98 system.
Andy
Comment 5 Andy Willis (abwillis) 2002-04-03 22:52:27 PST
This is happening on 1 ECS machine and one WSEB machine (2 OS/2 flavors). 
Outlook express confirmed that 465 is indeed the correct port and the server is
indeed working.
Andy
Comment 6 Andy Willis (abwillis) 2002-04-04 08:50:52 PST
Confirmed, same problem on win2k machine, 3-28 nightly build.
Comment 7 Jessica Blanco 2002-04-04 09:04:12 PST
not OS/2 specific
Comment 8 Andy Willis (abwillis) 2002-04-04 11:26:58 PST
I can create a test id on one of these servers if it is helpful.
Andy
Comment 9 Andy Willis (abwillis) 2002-04-05 18:04:03 PST
Just for completeness, I fixed the win98 problem of not allowing me to input a
port for smtp and entered the correct port and it exhibits the same behavior.
Andy
Comment 10 Andy Willis (abwillis) 2002-05-03 14:32:02 PDT
Seems to be working in 5-02 nightly trunk build.  Will test on Monday from
another network to confirm but it looks like this is now working correctly.
Comment 11 Andrew Young 2002-05-14 05:52:25 PDT
I am having the same problem, but with build 1.0RC2.  I have tried on Linux,
Windows ME, and Windows 2000.  Each machine exibits the same symptoms.  I am
running SMTP over SSL on port 465 with authentication.  I have a test account
setup on the machine that can be used to test the problem. (The machine is a
Linux server I run)  I haven't had problems with KMail on Linux or Outlook on
Windows with the same setup.  But with Mozilla it just hangs indefinately
without prompting me for a password.
Comment 12 Andy Willis (abwillis) 2002-05-14 06:02:17 PDT
I haven't been able to reproduce thing working since I posted that it worked
with the 5-02 build, either with the 5-02 build or the ones since it.  Let me
know if having an id on a server that requires the authentication will help and
I will create one.
Andy
Comment 13 Scott Gifford (old account) 2002-07-17 01:03:19 PDT
I'm seeing this in 1.0 on Linux.  tcpdump shows Mozilla connecting to port 465
and then just sitting there.  My suspicion is that it's waiting for an SMTP
greeting, instead of starting SSL/TLS negotiations with STARTTLS.

Everything works fine when I use port 25, where Mozilla uses STARTTLS.

Comment 14 Andy Willis (abwillis) 2002-10-18 13:47:13 PDT
This may be a duplicate of 98399.  If so then 98399 needs to be changed from OS
Linux to All.  Found this while searching for a TLS bug.
Comment 15 John G. Myers 2003-01-28 11:39:10 PST
Changing Summary, was: secure smtp authorization
Changing severity to enhancement.

Mozilla does not support the nonstandard port 465 protocol, it only supports the
internet standards track STARTTLS protocol.

SMTP is a server-talks-first protocol, the nonstandard 465 protocol is a
client-talks-first protocol.  The connection stalls immediately because each
side is waiting for the other to speak first.
Comment 16 John G. Myers 2003-01-28 11:39:46 PST
*** Bug 189281 has been marked as a duplicate of this bug. ***
Comment 17 John G. Myers 2003-01-28 11:40:20 PST
*** Bug 173415 has been marked as a duplicate of this bug. ***
Comment 18 Ed Schaum 2003-01-28 12:51:07 PST
This looks like the same as my report # 132559.

Ed
Comment 19 John Gerth 2003-01-28 22:00:40 PST
Until a month ago I would have considered this a minor enhancement,
but now it has become a significant need.  Here's why.

I've been pushing Mozilla to our faculty as a preferred mail application.
Since the faculty travel extensively, we've had to add encryption
and authentication to our SMTP servers so that they can safely relay
mail when on the road without reconfiguring their outbound servers.
This was all working fine until late this Fall when some connections from
the road started to fail.  It turned out that the reason for this
was that the ISPs being used by some hotels and conferences began
to prevent *all* port 25 SMTP from escaping their domain as a way
of preventing misconfigured subscriber machines from being hijacked as relays
by spammers.  This practice has been spreading and now some major
DSL providers like earthlink also restrict outbound port 25 connects
which has further hit people who carry wireless notebooks from campus to 
home (see http://help.earthlink.net/port25/ ).

The obvious finesse for this is to have people reconfigure mail to
use smtps on 465 (which just negotiates SSL at connect time) and
this is trivial to do on virtually all mail clients (including Mozilla).
But since Mozilla doesn't actually  support smtps on 465, people are frustrated
and making my worst nightmares come true by switching to Outlook.

Bottom-line, this not just a WIBNI enhancement, it's market-share.

 
Comment 20 Matthew Elvey 2003-01-29 04:21:54 PST
Gotta concur; this is a not a minor problem, not only for the reasons John Gerth
specifies, but because many ISPs say that if you want to connect via SMTP
securely, use port 465, and when people follow these instructions with Mozilla,
they don't work, *there's NO error message* and people assume it's a bug in
Mozilla.  

I don't think it's fair to just dismiss secure SMTP over 465 as 'nonstandard';
SSL isn't well-behaved, yes, but it certainly seems to be a de facto standard
(with many ISPs**); I wouldn't be suprised there's an RFC or BCP saying that
consumer ISPs should block port 25 to reduce spam; I'd say it's a near consensus
of spamfighters.  Yet it appears IANA has
revoked port 465 for SMTPS - http://www.iana.org/assignments/port-numbers
suggests this. Dunno why. Ayone know?
It was apparently mentioned in an unavailable internet-draft, but the (i'm
guessing) resultant RFC, http://www.ietf.org/rfc/rfc3207.txt has no mention of
port 465, and nor does the RFC it obsoletes.

Also, mail.attbi.com supports STARTTLS on port 465, (I just asked it*.) but
aparrently Mozilla still doesn't work (Right, Andy? I don't have an attbi
account.) - so this isn't just a "Mozilla should support SMTP over SSL" problem.
 So perhaps there is a bug here, not just an enhancement.  (Should this be
opened as a new bug?  I don't think it belongs here.)

**fastmail.fm, UC Berkely (the B in BSD) and many other Univerities, attbi,
worldnet.att.net,...

*>telnet mail.attbi.com 465
ehlo foo.com
...
250-STARTTLS
...

BTW, here's a comment by Kai indicating a workaround:
"In the end, if users really *must* use SMTP over SSL, they can already do so by
using external tools like stunnel."
Comment 21 Andy Willis (abwillis) 2003-01-29 08:17:18 PST
Correct I still am unable to send mail through mail.attbi.com on port 465.  It
just hangs as before.  
Comment 22 Matthew Elvey 2003-01-29 08:26:23 PST
Thanks, Adam. Are you sure it's "hanging"? Can you cancel or do you have to kill
the process?  When I try (XP, Moz 1.2.1) it keeps trying forever, but I can
cancel, so it's still responsive.

Re. 465 revoked by IANA:
http://archives.neohapsis.com/archives/ntbugtraq/1998/msg00515.html
-provides more info, (From Russ, who runs NTBugTraq) but the water is getting
muddier and muddier.  443?  
The IETF.org website is chock full of broken links. :( 
Comment 23 John G. Myers 2003-01-29 09:51:43 PST
The standard non-25 mail submission port is 587 per RFC 2476.
I thought I had filed a bug asking for mozilla to port-scan by default--if no port was 
specified by the user, mozilla would first try port 587 then try port 25.  I can't find that bug 
now.
Comment 24 Andy Willis (abwillis) 2003-01-29 10:17:49 PST
What I mean by hang is it just sits there, not a hung process.  I can cancel it
or eventually (did not time it but over an hour or 2) it times out saying the
smtp server could not be reached.  I can still set up an account if it is needed
for test.
Comment 25 Kai Engert (:kaie) 2003-01-29 12:56:54 PST
Thanks for the additional details.
Since the application does not deadlock, this is not a critical bug.
While it is undesireable that we don't detect the problem, this is not a fatal
problem.
The user tried to configure something that's not supported by the application,
and we don't detect it.
Please add further comments about this problem in the other bug, that complains
about the hang.
This bug should be for discussing how the implementation of the new protocol
should be done.
Comment 26 John Gerth 2003-01-29 16:59:37 PST
As to whether on should use the deprecated 465, I can only say that
the reassigned 4
In terms of implementation, Outlook and Outlook Express seem to
be able to figure out what to do without additional UI hints beyond
 a) the checkbox that says that SSL is required 
and 
 b)a port number
I'm guessing that they start out with the SSL connect and if the handshake
fails at first, they just use an unencyrpted EHLO to see if
STARTTLS is offered, but I haven't packet-traced that to be sure.

I don't remember exactly but I think Pine+Mutt have more explicit
data in the config file which distinguishes between SSL and
TLS (as in STARTTLS).

Sorry for the fragmentary reply but I've got a family problem
and have to leave right now...back Monday
Comment 27 Matthew Elvey 2003-02-03 01:24:22 PST
Would empowered folks add nsCatFood and helpwanted as keywords, and set the
priority?

IANA erroneously unregistered 465.  Posts on ietf-apps-tls* clearly 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!  Before blocking port 25 and requiring a login
for SMTP access were common/predictable, unregistering 465 made sense, but with
hindsight, it made very little sense.

*ask me for pointers to said posts.
Comment 28 Matthew Elvey 2003-02-04 04:00:33 PST
Also, Keyword nsenterprise per Comment #19?
Comment 29 bzh91n 2003-02-19 19:16:14 PST
The following comments were originally enter on Bugzilla Bug 98399 due to 
confusion on my part as to which of these two bugs is really the correct one to 
resolve the Port 465 problem. (Dale)

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
Comment 30 Kai Engert (:kaie) 2003-02-22 20:05:04 PST
Assigning to self, as I have a patch.
Comment 31 Kai Engert (:kaie) 2003-02-22 20:05:53 PST
Created attachment 115290 [details] [diff] [review]
Patch v1
Comment 32 bzh91n 2003-03-04 08:01:29 PST
Has anyone tried this? If so, what is the proper way to patch the product?
Comment 33 Ken Snider 2003-03-04 19:49:10 PST
Wait a minute! This behavior is *BROKEN!*

The *only* email client that still uses this outdated method of connecting to an
SMTP server is outlook Prior to Outlook XP, (and possibly outlook express,
though one whould hope that if they fix one problem they would fix another).

SMTP has a STARTTLS command for a *reason*, it's to enable TLS, and offer the
server owner some control over the process itself.

This was *not* deprecated hastily - there is a perfectly functional STARTTLS
system in place, that can run on any port, and has no issues. My mailserver has
*three* ports open on it. Port 25 (for obvious reasons), port 587 (MSA or
Message Submission port, also a standard (or at least a draft standard)), and a
hacked version of port 465 that forces sendmail to begin TLS negotiation upon
connect, rather than upon certain credentials being met.

This is *important*! On a server where resources are scarce, you may want
fine-grained control over the amount of crypto that a server should use, or who
can use TLS at all. You *cannot* do this with TLS-before-Auth or
TLS-before-EHLO/HELO, which is what this old broken protocol does.

Microsoft has *corrected* this bug.  *please* do not introduce it into Mozilla
without thinking it through!
Comment 34 John Gerth 2003-03-04 21:30:18 PST
I agree that using SMTPS (ssl on connect) is not a preferred way to go.

As for Microsoft somehow "fixing" this, I just used 465 from WinXP
with Outlook XP (patched through SP2) to qmail and exim servers
here which offer STARTTLS on 25 and SMTPS on 465.  Although I haven't tested
it tonight, Outlook Express up through XP has always worked with both too.

Other popular mail clients also can be configured for smtps. I've done
pine and mutt myself.

My sole contention is that SMTPS is a practical necessity right now because
of the behavior of ISPs that our folks encounter when travelling. 
Certainly the administrators of mail servers who don't want to offer SMTPS
on 465 or indeed anywhere are free to make that choice.  I fail to see
however, that this is an argument for a mail client not to include support.

The way I read the proposed patch it doesn't mandate TLS on connect but
adds SMTPS as an option. If the patch gratuitously did TLS always
that would definitely be wrong and wouldn't work with SMTP on port
25 where the client has to be told that STARTTLS is available (our
servers are configured to offer STARTTLS only to remote users and not
to offer AUTH until after STARTTLS to prevent inadvertent transmission
of passwords over unencrypted connections).

Comment 35 Ken Snider 2003-03-04 22:14:29 PST
Just a quick point of clarification.

I hadn't suggested that MS had removed the SMTPs functionality, but that they
had corrected the bug, so that outlookXP can connect to, say, the MSA port (port
587), and perform normal STARTTLS, while Outlook2000 and before would not. Any
port other than 25 used by earlier Outlook clients will default to SMTPs.
Comment 36 John Gerth 2003-03-05 14:42:15 PST
Thanks for the clarification about what MS did.
I now take your original note to mean that
an acceptable implementation allowing SMTPS should make
sure that the user requests it explicitly.

If that's the case, I think the proposed patch
does that, i.e., the GUI interface requires
the user to select SMTPS versus SMTP/STARTTLS
Comment 37 John G. Myers 2003-03-05 15:04:48 PST
I have several technical issues with the patch as written.

1) It makes unrelated changes, such as renaming "Port:" to "Alternate Port:" and
adding a label "(optional)" after the port field.

2) It changes the "Never"/"When available"/"Always" choice into a confusing mess
of acronyms

3) It gratuitously changes the names of the existing PREF_SSL_* enums.

I see four alternatives:

A) Status quo

B) If the user enters a port value of "465", then grey out the "Use secure
connection" radio buttons and use the port 465 protocol.  This would provide no
way to use the port 465 protocol on ports other than 465.

C) Call the new radio button "On separate port"

D) Issue some sort of diagnostic if the user attempts to enter "465" into the
port field.


Comment 38 Matthew Elvey 2003-03-10 13:24:58 PST
Re. John's last comment:
3) The enum changes make sense, as if the old ones were still used with the new
functionality, they would be readily misinterpreted.  Replacing the vague "SSL"
with STARTTLS or SMTPS enhances specificity.

So we need to decide how the UI will address this enhancement.
Given that the code to implement has been written, option D isn't very
attractive, and it's not per se a fix to this bug anyway; nor is A.

We have to make some UI decisions; this enhancement has to allow the user to
request SMTPS via the UI.  Option B makes sense to me.

Fleshed out:
When "Never", it's plain SMTP (on the specified port (25 if not specified)). 
When "Always", STARTTLS (on the specified port (25 if not specified)) EXCEPT if
port 465 is specified, in which case it's SMTPS.  
When "When available", a timeout should cause fallback to plain SMTP (on the
specified port (25 if not specified))
EXCEPT if port 465 is specified, in which case it *IMHO* should fall back to
plain SMTP on port 25 (other fallback options could be argued for as well).

Simple UI, not hard to implement.  Dox can be modified to let people know what
is going on behind the scenes.  This is option B, based on the assumptions
(valid, IMO) that the user doen't need to know that behind the scenes 465 is
special, and that SMTPs doesn't need to be supported other than on 465, and
certainly no one is going to miss support for STARTTLS on 465.

I don't understand option C)'s meaning.
 
(OT: I'd been thinking that "When available" is a pointless option/opportunity
for UI simplification, but then I noted Bug 97161; once it goes thru, this is a
useful option, so it should be left in.)

ONE-LINE SUMMARY of the REST of this comment: 
More argument for the merits of fixing this bug.

Many ISPs say that if you want to connect via SMTP
securely, use port 465, and when people follow these instructions with Mozilla,
they don't work, *there's NO error message* and people assume it's a bug in
Mozilla.  

Port 465 is and has been the standard for years, used by MANY MUAs, not just
Microsoft's - before 587 was ever considered.  There is no rational argument for
MozillaMail to not support this standard; it's not broken, and the issue I
mention at the beginning of this comment (and many others have concurred on) is
*PRIMARY*: MozillaMail appears to Joe User to be *BROKEN*.

I don't think it's sensible to just dismiss secure SMTP over 465 as 'nonstandard';
SSL isn't ideal, yes, but it certainly seems to be a de facto standard
(with many ISPs**); I wouldn't be suprised there's an RFC or BCP saying that
consumer ISPs should block port 25 to reduce spam; I'd say it's a near consensus
of spamfighters.  The other alternative to SMTPS on 465 (MSA on 587) HAS issues
- it isn't well supported yet by the major MTAs, and doesn't seem to have much
momentum either - so yes, it was hasty and improper for IANA to unregister it -
the proper process was NOT followed, so the fact that it is now unregistered is
an extremely poor reason not to support it.

Despite what Randy says, it's still the case that 
"IANA erroneously unregistered 465.  Posts on ietf-apps-tls* clearly 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!  Before blocking port 25 and requiring a login
for SMTP access were common/predictable, unregistering 465 made sense, but with
hindsight, it made very little sense.

*ask me for pointers to said posts."

I'd be interested in info on the IMC decision - here or via email.

**fastmail.fm, UC Berkely (the B in BSD) and many other Univerities, attbi,
worldnet.att.net,...

NO ONE is suggesting that any port other than 25 default to SMTPs.
Comment 39 Adrian Havill 2003-03-19 09:14:45 PST
comment #35:

The most recent versions of Outlook Express (IE6SP2) do STARTTLS if and only if
the port is 25. If the port is set to 587 or 465, it will do SSL under the SMTP.
(which is correct for 465, incorrect for 587)

Note that the default "port" for secure smtp in later versions (if you check the
"ssl" box under smtp options and leave the port as-is) is 25-- meaning Outlook
Express 6 encourages folks to use STARTTLS over port 25.

Note that MS's clients are not the only clients that do this. Evolution pre
version 1.1.1 (for Linux, haven't tested other clients), the "stock" mail client
for Red Hat Linux 8 and beyond, does NOT use STARTTLS and uses SSL ONLY for ANY
port (which is very wrong for anything other than port 465). Openoffice.org
claims versions 1.1.1 and beyond will support STARTTLS.

Recent versions of sendmail, when compiled with the right options, support both
methods out of the box. To do port 465+SSL is as easy as adding:

DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')

to your sendmail.mc and requires no hacks for many distros.

Despite whether or not Outlook XP "fixes" the problem, there are an awful lot of
Outlook Express 6 clients out there, and the need to securely authenticate with
a "stock out-of-the-box" client is more important than ever thanks to e-mail
spam/abuse. Thus, it's safe to assume there are many office intra/extranets and
perhaps even a few ISPs that offer 465 (SMTP+SSL) and not 587+STARTTLS
(25+STARTTLS is a non-starter for roamers b/c many ISPs intercept 25 to prevent
spam abuse).

It would be nice if Mozilla both "do the right thing" as well as "work with
what's being used in the world right now".
Comment 40 Adrian Havill 2003-03-19 09:19:30 PST
Comment 39: s/Openoffice.org/Ximian/
Comment 41 Andy Willis (abwillis) 2003-04-18 17:55:03 PDT
I finally have a good build environment and tried to apply the patch thus:
patch -p0 <patch-135357
and get:
can't find file to patch at input line 8
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: mozilla/mailnews/base/prefs/resources/content/smtpEditOverlay.xul
|===================================================================
|RCS file:
/cvsroot/mozilla/mailnews/base/prefs/resources/content/smtpEditOverlay.xul,v
|retrieving revision 1.20
|diff -u -r1.20 smtpEditOverlay.xul
|--- mozilla/mailnews/base/prefs/resources/content/smtpEditOverlay.xul  3 Oct
2002 21:16:28 -0000
    1.20
|+++ mozilla/mailnews/base/prefs/resources/content/smtpEditOverlay.xul  23 Feb
2003 03:44:11 -0000
--------------------------
File to patch:

The file does exist so has the source changed to much to apply it or am I using
the wrong syntax?
Thanks,
Andy
Comment 42 Andy Willis (abwillis) 2003-04-18 18:22:47 PDT
Nevermind, I looked at what was happening more closely.  The other patches I
have applied all were from within the mozilla directory.  This one was setup in
its parent directory.
Andy
Comment 43 David 2003-06-04 18:41:40 PDT
Just an additional datapoint on this issue:

My ISP is AT&T DSL, which just switched over to Covad.  As part of
this migration, the switched to using port 465 and SSL for SMTP.
I don't understand the details of the standard or protocol, but
this I know: it works with Outlook Express and it works on my
daughter's iMac (OSX), but it doesn't work with Mozilla.  I also
tried Thunderbird, no-go there as well.  They may all be wrong,
but they are compelling me to switch to Outlook unless Mozilla
supports the feature in the way they do.
Comment 44 Kai Engert (:kaie) 2003-06-04 20:57:34 PDT
David, you might want to try and use the test build available at wamcom.org, who
is based on Mozilla 1.3. Does that work for you?
Comment 45 Matthew Elvey 2003-06-05 08:25:03 PDT
But Kai, at wamcom.org, it says "In a couple of days I will provide compiled
versions of Mozilla 1.3, that will in addition have <this bug>" fixed.  
If your fix is in the ~2003-03-08 build that's there, or you can point me to the
right compiled build, lemme know (reply here or email me at
<firstname>@<lastname>.com). I'm ready and willing to install (on Win32) and
test it to see if it fixes this bug.
Comment 46 Kai Engert (:kaie) 2003-06-05 08:47:42 PDT
Matthew, personal mail to you bounces marked as spam...

Yes, the downloadable test build at that site has the patch from this bug,
that's why I suggested to try it :-)
Comment 47 Matthew Elvey 2003-06-05 11:58:01 PDT
Confirming that the submitted patch fixes the bug:

I installed and ran the build from wamcom.org on XP, and it works over port 465
with www.fastmail.fm.  I suggest folks who need this use the wamcom build for now.

Would love to see this fixed in the trunk.  Unfortunately, as John G Meyers
pointed out:
"[The current patch] changes the "Never"/"When available"/"Always" choice into a
confusing mess of acronyms" - Even with my familiarity with this issue, I had to
think for a bit before realizing that I should choose "Always use as secure
SMTPS connection", not "Always use a secure SMTP/STARTTLS connection".  I doubt
the fix will make it into the main tree until it's impact on the UI is improved
(Implementation of option C (good enough, IMO) or option B (best UI) as fleshed
out in my comment #38 ?)  

John G Meyers (and any likely reviewers): Would you object to implementation
along the lines of option B or option C? 

If there's no objection, I'm willing to code Option C.  Any volunteers to code
Option B?  

(Emailed to Kai: Yes; my bugzilla fullname is /Matthew Elvey (dodging spammers
due to Bug 120030 ; all email will bounce with instructions to override)
<mailto:bugzilla3sd@matthewelvey.f-m.fm> which is why I said email me at
<firstname>@<lastname>.com!
Comment 48 John G. Myers 2003-06-06 17:34:08 PDT
I would prefer option B to option C.  I'm skeptical that users will reliably
figure out how to properly configure option C, even with the simpler wording.
Comment 49 Robert Coup 2003-06-16 02:00:53 PDT
Whats above (use 465 with SMTPS and everythign else with STARTTLS) sounds
reasonable. Make sure though, that editing prefs allow people to do non-standard
things (like SMTPS on port 1234), even though the UI might not. I think this
would be a reasonable compromise (and if a need to add some other UI options
pops up later then its even simpler).

Other option - as commented in #26:
.. start out with the SSL connect and if the handshake fails at first, they just
use an unencyrpted EHLO to see if STARTTLS is offered...
That might be one way to make it the easiest for the end user?
Comment 50 Matthew Elvey 2003-06-18 13:42:28 PDT
Can anyone present a real life (non-hypothetical) case that contradicts the
claim that "SMTPs doesn't need to be supported other than on 465, and
certainly no one is going to miss support for STARTTLS on 465"?  
If not, It's not worth worrying about Robert's concern.
I don't think it's worth worrying about.

John M: So you'd object if I coded C and you reviewed it?
Comment 51 Ken Snider 2003-06-18 13:53:01 PDT
I think the above makes sense. I have yet to see anyone using SMTPS on ports
other than 465, and more specifically, OutlookXP and above default to STARTTLS
if used on a port OTHER than 465. So if even outlook won't support it, and
that's the primary point of using this outdated protocol, then I'm sure it's fine.
Comment 52 John G. Myers 2003-06-18 13:55:29 PDT
I'd be willing to review code.  I'm neither the module owner nor their delegate,
though.
Comment 53 Kai Engert (:kaie) 2003-06-18 14:10:39 PDT
I don't like the idea to "use SMTP/SSL on 465 and STARTTLS on everything else". 

Arguments:
- Nobody troubleshooting the product will ever understand it.
- Only because we don't know of a use, doesn't mean there is no use. It's easy
for us to add to option to use another port, and some users might be happy. If
we think "nobody will ever use other ports", why have we added an alternate port
option in the past at all?
- a real world scenario might be somebody who has to use port forwarding over
SSH to connect to a remote relay, and can not use port 465 because the user does
not have root rights (ports < 1024 are restricted).

Alternate suggestion:
Let's keep the current UI mostly. But in addition, let's add another piece of
information to the dialog. In front of "alternate port" let's add a statement
that says "default port". Whenever the user clicks a radio button, we will set
the default port number accordingly. That is, we'll set 25 for most protocols,
and will show 465 if the user selects SMTP/SSL.
Comment 54 John G. Myers 2003-06-18 14:18:53 PDT
With the suggestion in comment #53, it would be difficult for an ordinary user
to correctly configure use of the port 465 protocol due to confusion between
"SMTP/SSL" and "Always".
Comment 55 Kai Engert (:kaie) 2003-06-18 14:20:49 PDT
> 1) It makes unrelated changes, such as renaming "Port:" to "Alternate Port:" and
> adding a label "(optional)" after the port field.

I think those changes make sense to understand the dialog better, especially
with the new suggested "default port" information addition.


> 2) It changes the "Never"/"When available"/"Always" choice into a confusing mess
> of acronyms

If the user is confused, they should read the help or ask their administrator.
The default will be fine for most users.


> 3) It gratuitously changes the names of the existing PREF_SSL_* enums.

I think it makes the code clearer, I don't understand why this should not be
done in the scope of this bug.


> I see four alternatives:

I personally don't like any of these alternatives.
Comment 56 Adrian Havill 2003-06-18 14:21:51 PDT
Comment 51:

Outlook Express 6 (which far outnumbers Outlook XP), uses STARTTLS *only* with
port 25, which is the opposite behavior.
Comment 57 Kai Engert (:kaie) 2003-06-18 14:23:10 PDT
> With the suggestion in comment #53, it would be difficult for an ordinary user
> to correctly configure use of the port 465 protocol due to confusion between
> "SMTP/SSL" and "Always".

Ordinary users go with the default.

Ordinary users that have to use a special configuration will have received
information from their ISP or administrator which configuration is correct for them.

Advanced users will know what to do or read the help.


Comment 58 Kai Engert (:kaie) 2003-06-18 14:30:04 PDT
Created attachment 125953 [details]
Screen Shot of Patch v1

I'm attaching this screenshot for completeness, it shows the UI that is
implemented by the attached patch.

We could also rename "SMTPS" to "SMTP/SSL" to make it clearer.
Comment 59 John G. Myers 2003-06-18 14:37:34 PDT
The instructions that ordinary users are likely to get from their ISP will
likely be "use port 465".  They will not get any information which will help
them decide between the "SMTP/SSL" and STARTTLS radio buttons because no such
information is necessary to configure Outlook.  Going with the default radio
button setting will then not work.
Comment 60 Adrian Havill 2003-06-18 14:41:01 PDT
comment 58:

it's called "smtps" in most Un*x /etc/service files, and unfortunately,
Microsoft confuses the meaning of SSL with their own programs (clicking on "use
SSL" in Outlook Express while leaving the port as 25 will cause it to use STARTTLS).

sendmail, btw, refers to it as "TLSMTA"
Comment 61 Kai Engert (:kaie) 2003-06-18 16:11:08 PDT
> The instructions that ordinary users are likely to get from their ISP will
> likely be "use port 465".  They will not get any information which will help
> them decide between the "SMTP/SSL" and STARTTLS radio buttons because no such
> information is necessary to configure Outlook.  Going with the default radio
> button setting will then not work.

If they don't clear information from their ISP, and they don't have a clue, they
can just try it out.

If we take the suggestion to display the default port in the UI (see comment
53), the users will see that SMTP/SSL is shown with a default port of 465 and
can find it without trying out.
Comment 62 Kai Engert (:kaie) 2003-06-18 16:47:00 PDT
Created attachment 125969 [details] [diff] [review]
Patch v2

This patch implements my updated proposal.

I don't have a lot of time to work on this, therefore this patch is not merged
to the trunk, but is still a patch against Mozilla 1.3
Comment 63 Kai Engert (:kaie) 2003-06-18 16:47:50 PDT
Created attachment 125970 [details]
Screen Shot of Patch v2
Comment 64 John Gerth 2003-06-18 17:25:39 PDT
For what it's worth, I like the new UI as it seems pretty clear what's
going to happen and how to change it if you need to.  Looks like
the Right Thing to Do.

...and getting this into the trunk is an even more important for
our continued use of Mozilla here bacause, in the wake of a Bugbear.B
virus outbreak, they shut off outbound port 25 at Stanford so now
we look pretty much the same as ISPs like Earthlink.
Comment 65 David 2003-06-18 21:25:03 PDT
The patched version on wamcom.org fixed the problem for me (AT&T DSL).
I had to select "Always use a secure SMTPS connection".  I'm quite
technical, but I am not familiar with any of the standards and issues
relevant to this problem and discussed here.  My ISP just told me "port 465".
(Actually, they only told me that when I called because it didn't work after
they made changes.  Their update script only modified Outlook Express.)

My point is, I have no problem with trial and error, but the correct
choice was not at all obvious, and nothing my ISP told me gave me a clue.

Anyway, I'm glad to have this working, thanks.
Comment 66 Kai Engert (:kaie) 2003-06-18 21:32:32 PDT
David, do you think you would have figured out more easily with the UI in screen
shot 2 that would display "Default port: 465" when you click the "always use
SMTP/SSL" option?
Comment 67 Matthew Elvey 2003-06-20 00:31:40 PDT
>a real world scenario might be somebody who has to use port forwarding over
>SSH to connect to a remote relay, and can not use port 465 because the user does
>not have root rights (ports < 1024 are restricted).
I hate to pipe up after Kai's coded a fine new solution but...  The above is a
_hypothetical_ scenario, not a real life case.  Also, I'm not following what
this scenario's difficulty is.  Isn't 465 only the port # used on the ultimate
server?  The client connecting to a server's port 465 doesn't need root rights
to do so, or access to its own port 465!  Am I confused?  If you're proposing a
hypothetical where there are two levels of encryption that's unlikely to ever be
needed, who cares?  Or are you saying the remote relay that the user is using is
also set up by the user, but can't be on port 465 due to the user not having
root access on this remote system?  If it's a tunnel, it doesn't matter if the
remote system isn't connected to 465; it's just a step on the way to the
ultimate server, which of course can be running on 465 if it needs to support
SSL. This seems to be a hypothetical scenario of no concern, not likely to ever
be a real life case.  Also, the hypothetical scenario could be resolved through
used of STARTTLS instead of the old SSL.  Whatever the case, is there a likely
real life scenario that we need worry about?  The troubleshooting issue of the
simple UI solution can be addressed via documentation, yes?  (Whew!)
I'm fine with Kai's new solution, but wouldn't the simple UI solution be even
better?
Comment 68 Kai Engert (:kaie) 2003-06-20 12:23:37 PDT
> The above is a
> _hypothetical_ scenario, not a real life case.  

I disagree. People in the past asked for the alternate port feature, because
they had to use port forwarding.


> Also, I'm not following what
> this scenario's difficulty is.  Isn't 465 only the port # used on the ultimate
> server?  The client connecting to a server's port 465 doesn't need root rights
>to do so, or access to its own port 465!  Am I confused?  

If one uses port forwarding, using a tunneling tool, our Mail client will
connect to the tunnel's endpoint on the local or a nearby machine. Suppose we
don't make the port number configurable. If we didn't, the user would have to
configure the tunnel to use port 465. Using port 465 might not be possible on
the machine that runs the tunnel, if the user does not have root rights on the
tunnel machine.

I say, let's not give up our current flexibility.


> If you're proposing a
> hypothetical where there are two levels of encryption that's unlikely to ever be
> needed, who cares?  

I disagree it's hypothetical, and I do care.
It's not that two levels are needed, it's that users might be forced to use two
levels, because they don't own the servers, and are required to go through the
tunnels.


> Or are you saying the remote relay that the user is using is
> also set up by the user, but can't be on port 465 due to the user not having
> root access on this remote system?  

On the *tunnel* system access to port 465 is necessary.
 
> If it's a tunnel, it doesn't matter if the
> remote system isn't connected to 465; 

The tunnel process must bind to a local port, and that is what requires root rights.

> it's just a step on the way to the
> ultimate server, which of course can be running on 465 if it needs to support
> SSL. This seems to be a hypothetical scenario of no concern, not likely to ever
> be a real life case.  

Sorry, I think you should not say something is unlikely, just because you think
that you probably will never run into it.


> Also, the hypothetical scenario could be resolved through
> used of STARTTLS instead of the old SSL.  

We are talking about users, that must find a way to connect. Users are not able
to reconfigure the server.


> Whatever the case, is there a likely
> real life scenario that we need worry about?  

I'm staying with my example, and that we had originally been asked to support
alternate ports because of the tunneling needs of users.


> I'm fine with Kai's new solution, but wouldn't the simple UI solution be even
> better?

I don't support the simple UI option, if it means, we don't support
functionality that is easy to implement.
Comment 69 Kai Engert (:kaie) 2003-06-20 12:46:01 PDT
Comment on attachment 125969 [details] [diff] [review]
Patch v2

Seth, do you want this patch?
Comment 70 John Gerth 2003-06-20 12:58:46 PDT
It seems to me that Kai's new UI is both simple and complete.
As someone who's had to talk users through configurations
over phones in hotel rooms, I like the fact the default port
is displayed and that there's a way to override it. The default
display reassures the user about what's going to happen
and gives me a reference point if a change has to be made.

With the spam wars in full bloom, it's also wise to allow
for reconfigurations as there isn't an agreed to solution yet. 
Comment 71 rr_mozilla 2003-07-08 09:56:51 PDT
Confirming that AT&T DSL and now Verizon DSL do not work with 1.4 Mozilla using
port 465 smtp. Just get a short cancelable hang with no error message on send.
AT&T tech support simply says 'we do not support Netscape/Mozilla, switch to
Outlook Express.' The are very diffident about discussion, although one techie
mumbled something about stunnel, but refused to say how to use it. As if to make
a major thing of this, AT&T appears to block access to their part 25 servers
when you come in through DSL (but not when you use 56k modem dial up). So this
is the way the wind is blowing.

Can anyone point me to a link for a temporary fix using stunnel with Mozilla?

Would also be delighted to test a Mozilla fix if you can point me to a win32
build with whatever GUI  (or none) .

As a normal mortal (i.e. not a developer), I hate the idea of being forced to
use Outlook Express. Hate, hate, hate.
Comment 72 Andy Willis (abwillis) 2003-07-08 10:58:27 PDT
I had offered to create an email account for someone working on this bug to test
on.  It doesn't look like that was necessary but I am no longer able to do so as
I was just migrated from attbi to comcast and comcast is not using this method
so I can no longer test any fix.
Andy
Comment 73 Kai 2003-07-08 18:03:40 PDT
rr_mozilla@voicewizard.com:

You could try the build available at wamcom.org

Alternatively:

Using stunnel is possible, but requires using command lines, I know it can work
on Windows and Linux, probably Mac OS X:
- get stunnel from www.stunnel.org
- make sure you are able to start it
- use appropriate command line arguments to bind stunnel to a port on your local
machine, like:
  stunnel -d :25 -r mailserver-hostname:465 -c -f -D 6
              ^^
  This sets up stunnel to listen on your machine at port 25,
  and connect to host mailserver-hostname to port 465, 
  wrapping SSL around the connection
- set up Mozilla to use hostname "127.0.0.1" with port 25
  as your outgoing mail server.
- in Mozilla configure to not use encryption when sending mail
- you'll always have to have stunnel running when sending mail
- when you send mail with mozilla, you should see some activity going on in the
stunnel console window
Comment 74 rr_mozilla 2003-07-09 09:12:36 PDT
Re: comment 73 from Kai-
Thanks for fast response.

Tried the download 1.3.1 from wamcom.org. It did not help the smtp:465 problem
using the Start/SSL option in either 'always' or 'when available' option.
Program stalls after 'send' with barber pole, but can be cancelled :'{

Downloaded stunnel and dll's. Stunnel with command line options started but
complained about need for stunnel.conf file missing. Really didn't have
expertise to know what to put in such a file, but made a one liner
"service=stunnel". stunnel then  complained about needing stunnel.pem file.
Seeing I was getting in deeper and deeper I stopped.

Willing to test further, but need help with some minimalist config files for
stunnel or ideas about 1.3.1 patched prog to try.

Using Home XP, ATT DSL

Tnx again for caring.
Comment 75 Kai 2003-07-09 09:16:26 PDT
rr: sorry, the UI in wamcom is not yet as clear as we have dicussed in this bug.

With the 2003-06-24 build of wamcom, use the "Always use a secure SMTPS
connection" option, and configure it to port 465. This must work.
Comment 76 rr_mozilla 2003-07-09 10:05:33 PDT
Re comment 75 :
'Always use secure SMTPS' worked in patched 1.3.1 from wamcom. UI was a bit
confusing with regard to the discussion in this thread and which option to use.

In any case, a blessing on all your CPU's, may your teeth never decay and may
all your children bring pride and happiness into your life......

IMHO, GET this fix in the main trunk, pronto.

Thanks.
Comment 77 Matthew Elvey 2003-07-09 16:39:53 PDT
Just want to confirm that Kai's response eliminated my objection.
I'm all for Kai's patch.  Seth?
Comment 78 cybermike 2003-07-11 22:53:14 PDT
I think the new UI is very clear as to what the user options are once the issue
is understood.  It also allows the user to tinker with the settings to find a
combination that will work even if all is not understood.  Worked great for me
now that cox.net joined the fray of blocking port 25 to smtp servers other than
their own.

This should get into the trunk right away.
Comment 79 Asa Dotzler [:asa] 2003-07-27 18:44:21 PDT
not for 1.4.1 and mozilla1.5a is already released. unsetting blocking request.
Comment 80 Matthew Elvey 2003-07-27 19:26:43 PDT
This bug is documented in the release notes:
http://www.mozilla.org/releases/mozilla1.5a/known-issues.html#smtp
My understanding of the block tag's purpose is such that the 1.4.1 tag was
appropriate.  I'd love for someone (asa) to provide an explanation for -ing the
block request.  (or for a pointer to better documentation than
http://bugzilla.mozilla.org/flag-help.html and
http://bugzilla.mozilla.org/describekeywords.cgi on their purpose, e.g.
something that would clarify whether 1.5b is appropriate.)
Comment 81 rr_mozilla 2003-07-27 20:57:10 PDT
re comment #80 : This workaround dcoumented in the 1.5s release notes, "use port
25" is useless now on some of the major providers like AT&T or Verizon because
they block ALL access to port 25 to DSL customers. To be honest you really have
to say "switch to dial up and use port 25" (dial up port 25 is not yet blocked)
which statement, of course, will win no poularity contests.
Comment 82 Scott MacGregor 2003-07-30 15:14:23 PDT
Can this patch be minimized to just offer a 
port texbox like we currently do for IMAP and POP in the account manager?

i.e. leave the radio buttons like they were. Add a new text box that says:

Port: XXX

where XXX = 25 and the user can change it.

This keeps the UI consistent with POP and IMAP. 

I can sr this patch if you are interested in doing it that way =)
Comment 83 Kai Engert (:kaie) 2003-07-30 19:15:33 PDT
Scott,

> Can this patch be minimized to just offer a 
> port texbox like we currently do for IMAP and POP in the account manager?

I don't understand your proposal, because our SMTP preference panel already
contains a port textbox.

This bug requests to support a different mechanism to combine SSL with the SMTP
protocol.

The protocol already implemented in Mozilla uses a socket that initially uses
plain text, and later switches to encrypted mode by issueing the STARTTLS
protocol command, usually used on port 25.

The new requested protocol uses SSL wrapped around a SMTP protocol connection
(SMTP over SSL), usually used on port 465.
Comment 84 Christian Eyrich 2003-08-06 13:07:24 PDT
*** Bug 211426 has been marked as a duplicate of this bug. ***
Comment 85 Christian Eyrich 2003-08-06 13:10:03 PDT
*** Bug 214660 has been marked as a duplicate of this bug. ***
Comment 86 Matthew Elvey 2003-08-07 16:27:01 PDT
mscott?  bienvenu?  Perhaps we need to wait 'till Seth is done with the work on
other AOL projects I heard he was shunted to.  An approval -or- a suggestion as
to what should be done that's better is needed.

I didn't understand Scott's proposal either; sent the following 8/3:

There's been a lot of discussion in the bug comments around what you said here
<http://bugzilla.mozilla.org/show_bug.cgi?id=135357#c82>.  Here are some
guideposts to help you:

Please see the comments, particularly Kai's comment 53
<http://bugzilla.mozilla.org/show_bug.cgi?id=135357#c53>, in which he argues
against what *I think* you're proposing (and I supported in comment 38
<http://bugzilla.mozilla.org/show_bug.cgi?id=135357#c38> as option B).
I argued for a simpler UI like what you're proposing, but it appears that I was
out-debated, e.g. see Kai's comment 68
<http://bugzilla.mozilla.org/show_bug.cgi?id=135357#c68> and others.

Please reply (to the bug) restating whether you currently support kai's fix, and
if you don't, further explaining what you support (e.g. "use SMTP/SSL on port
465 and STARTTLS on everything else unless overriden by a hidden preference" or
what?)

-Matthew. (Just trying to help shepherd this bug.) 
Comment 87 Mabry Tyson 2003-08-09 17:27:49 PDT
1)  IMHO, the options as shown in the screen shot of patch v2 are not
user-friendly enough (and most of my users are Computer Science PhDs but not
sysadmins).  A slight wording change would make it much better:  change "Always
use a SMTP/SSL connection" to "Always use a SMTP/SSL connection (usually on port
465)".  This way if a user is only told to use 465, he will likely pick this
option first. (This may satisfy comment #59) 
 

I would also encourage changing the phrase "standard SMTP connection" to
"unencrypted SMTP connection".  (Isn't SMTP/STARTTLS standard?  This also hints
at the risk of plain text SMTP.)


2) FYI, Outlook (< XP) isn't the only MUA that only uses SMTP/SSL on ports other
than 25 for secure mail.  Eudora 5.2.1 (PC & Mac) has the following options
under "SSL for SMTP":  None, Required (TLS), Optional (TLS), Required (Alternate
Port).  The problem for sysadmins is that "Required (Alternate Port)" means port
465 and uses SMTP/SSL. The others use port 25.  So if you are faced with users
using Eudora wanting to send secure mail from, say, a hotel that blocks outgoing
port 25, you need to support SMTP/SSL on 465.   Just like with Mozilla, we don't
want to say to people that we don't support their mailer so we have to support
465 for Outlook and Eudora.  I imagine there are sites that just support SMTP/SSL.

Also, FYI (regarding terminology as used), Apple's Mail application has a
checkbox "Use Secure Sockets Layer (SSL)" which does do STARTTLS (and doesn't
work to a SMTP/SSL on port 465).  

Finally, thanks to those working to get this into Mozilla!  (From a sysadmin who
wants all his users to use secure mail.  We support STARTTLS but I worry about
users using a different mail system because they have some other use requiring
them to use port 465.)
Comment 88 Matthias Versen [:Matti] 2003-08-11 13:49:21 PDT
*** Bug 215829 has been marked as a duplicate of this bug. ***
Comment 89 Julien Pierre 2003-08-11 15:53:35 PDT
Kai,

I think the UI proposed is excellent.

I concur with comment #87 - 1)
I would also replace the word "standard" with "unencrypted" in the name of the
first option.

As far as comment #87 - 2), I don't think the port name belongs in the name of
the option. I'm not aware of a better name for SMTP/SSL . The fact that Apple's
mail program doesn't call its STARTTLS option STARTTLS doesn't mean that Mozilla
shouldn't call apples apples .
Comment 90 Kai Engert (:kaie) 2003-08-12 16:57:08 PDT
I agree "standard" is not perfect, but I think "unencrypted" might be too
difficult to understand?

I personally don't mind to mention the default port number in the radio text, I
agree it might save users a click.

Since STARTTLS is not a very common term, and since you say Eudora uses TLS, I
wonder if we should do the same.


Ok, here is a new proposal:


(x) Do not use a secure connection
( ) If available, use a secure SSL/TLS connection (default port: 25)
( ) Require a secure SSL/TLS connection (default port: 25)
( ) Require a secure SSL connection (default port: 465)

Use Alternate Port: ____
Comment 91 John Gerth 2003-08-12 17:07:54 PDT
The new UI would work fine for my users
Comment 92 Julien Pierre 2003-08-12 17:55:11 PDT
Kai - regarding wording, you could use "insecure" instead of "unencrypted". But
maybe that's being a little paranoid.

I personally prefer the word "encrypted" than secure, as it is a more accurate
description of what's going on when the option is turned on.
As demonstrated through previous attacks on TLS, nothing is truly secure
forever, but the traffic is definitely encrypted with the option on.
Comment 93 Kai Engert (:kaie) 2003-08-12 18:15:06 PDT
I think we should come to and end with change requests, in order to get it
finally landed. I agree your arguments are good, but the initial wording uses
the term "secure" and the latest proposal stays with it.

I think our discussion is futile as long as we don't hear comments from the
module owner or another peer.

I will not work on yet another patch until I hear a statement which UI will be
accepted for checkin. :-)
Comment 94 Jody Kovalick 2003-08-14 10:00:40 PDT
So a few question now that I'm watching this bug as I need it resolved:

1. Is this being included in the path for Mozilla 1.5b or 1.5 final?
2. Is this being included in the path for Thunderbird?
3. Sorry for the ignorance, but how do I install the Patch v2 into my exising
Mozilla/Thunderbird apps?

Thanks.
Comment 95 Matthew Elvey 2003-08-15 08:26:21 PDT
1. Today is the deadline for this to make it into 1.5, I think.  
2. ? Doubt it.
3. You don't, per se.  You can use the build from wamcom.org though (as
mentioned in comments above).  (Or compile your own copy of Mozilla, this is
explained on the mozilla site.)

Kai's frustration is understandable.  Someone empowered please state some
wording that they will approve, e.g.

+<!ENTITY neverSecure.label "Use a standard (unencrypted) SMTP connection">
+<!ENTITY alwaysSecure.label "Require a secure SSL/TLS connection">
+<!ENTITY alwaysSmtpS.label "Require a secure SSL connection (default port: 465)">
+<!ENTITY sometimesSecure.label "If available, use a secure SSL/TLS connection">

Hello, Scott? (re. comment #86)

We're polishing peanuts.  It works, the UI is good.  Let's get it checked in; 
wording improvements can always be addressed in future bugs.
Comment 96 Sebastian Nohn 2003-08-28 02:46:45 PDT
Verified with 1.5b, still does'nt work.
Comment 97 Christian Eyrich 2003-09-02 13:57:41 PDT
*** Bug 217944 has been marked as a duplicate of this bug. ***
Comment 98 Jody Kovalick 2003-09-05 11:59:36 PDT
What needs to happen to get this into the path for 1.5 Final, Thunderbird, or
something? Is this stalled?
Comment 99 Matthew Elvey 2003-09-06 14:10:33 PDT
It's stalled.  I emailed Scott directly on 9/4:

Hi.  You provided some constructive UI criticsm re # 135357 that has been
responded to.  I think your feedback is needed for progress to be made on this bug.

http://bugzilla.mozilla.org/show_bug.cgi?id=135357#c86
http://bugzilla.mozilla.org/show_bug.cgi?id=135357#c95

E.g. Please say I can 'sr' the patch with the wording of comment [90 | 95] / I
can't because _____.

Kai has said: "I will not work on yet another patch until I hear a statement
which UI will be accepted for checkin. :-)"

No response.  Jody, I'd say (you?) emailing drivers @ mozilla . org on Monday or
Tuesday would make sense.  This bug is almost completely squashed!
Comment 100 timeless 2003-09-08 10:26:13 PDT
*** Bug 132559 has been marked as a duplicate of this bug. ***
Comment 101 Matthew Elvey 2003-09-08 10:48:24 PDT
*** Bug 114225 has been marked as a duplicate of this bug. ***
Comment 102 Christian Eyrich 2003-09-13 12:48:22 PDT
Created attachment 131402 [details]
Screenshot of changed UI for Patch v2

Modified UI, only one line for the port stuff and less text. Keeping the
current "Use secure connection:" line is wanted.

An alternative could be to put the whole secure connection stuff between
"Server Name" and  "Use username and password" and the port line behind the
server name box.
So we'd keep the connection between server address and port number.

I'd like to have the port box always filed out. Not to change it automagically
if the user clicks a radio. But always filed out, although it's the default
which is currently used.


To address Scott's objection for consistency with POP3 and IMAP: We've to
change/extend the UI for these two protocols in the next time too because of
bug 218902.
To be really consistent we should consider putting the four radios on two lines
with two each. That's because on the POP/IMAP panel we don't have that much
free space ...
Comment 103 Jody Kovalick 2003-09-13 13:44:41 PDT
I think this UI enchanment in the screenshot updated for patch v2 is excellent. 
How do we appove it and get it implemented into the current update paths?
Comment 104 Christian Eyrich 2003-09-14 02:31:38 PDT
The text is in the style of Eudora 6 and Hamster 2.0.
To save space it would be the best to replace the four radios by one drop-down
menu. I'm not really enthusiastic about this as one can't see all options at a
glance. But it's quite smart.
Comment 105 Matthew Elvey 2003-09-19 16:23:12 PDT
I've tried emailing and IMing Scott, but it appears that he's abandoned interest
in this bug - no response.

Setting keywords interop, nsCatFood.  Refraining from setting helpwanted, polish
though I suspect they're applicable.

The tree is open again for (1.6) checkins.

Anyone able to suggest something, and drive it thru approval, e.g.

"Use secure connection:"

o    	Never (unencrypted)
o    	Always (SSL/TLS)
o    	Always (SSL) (default port 465)
o    	If available (SSL/TLS)
Comment 106 Sebastian Nohn 2003-09-19 18:31:11 PDT
I don't know, what all this SSL/TLS/Whatever-Stuff is about, and i don't care
anyway. I just want this thing to work with Mozilla (and it works fine with any
other mailer including Outlook and even such **** as Outlook Express). With
1.5RC1 it still does NOT work.
Comment 107 John Gerth 2003-09-19 18:58:17 PDT
As more and more ISPs block 25 but allow 465, the lack of this
functionality is making it more and more difficult to use
Mozilla/Netscape especially for people who take their laptops
between home and work or trave a lot.

Would it be possible to accept the current implementation now
and, if necessary, change the UI in a future version?
Comment 108 Jo Hermans 2003-09-21 02:38:16 PDT
*** Bug 219840 has been marked as a duplicate of this bug. ***
Comment 109 Christian Eyrich 2003-09-23 05:18:09 PDT
On the URL on the top I'm providing UIs for the panels of SMTP, POP3 and IMAP.
It's my try to build a simple and single layout for the same feature on
different panels.

It would be great if we could agree on one layout (modifications are possible of
course) with the one for bug 218902.
Comment 110 Gervase Markham [:gerv] 2003-09-23 05:40:47 PDT
That UI seems terribly complicated. What percentage of net users have any idea
what the difference between "SMTP/STARTTLS" and "SMTP over SSL" is? How can they
possibly make that decision?

What are the technical and security issues here? We need to outline the exact
reasons why Mozilla can't just Do The Right Thing without any UI at all. 

Gerv

Comment 111 Christian Eyrich 2003-09-23 07:19:29 PDT
Why terribly complicated?
There are four possibilities and the user must choose one. It's only one more as
in the current UI.

> What are the technical and security issues here? We need to outline the exact
> reasons why Mozilla can't just Do The Right Thing without any UI at all.

Though there are standard (or semi standard in case of SMTP) ports for Protocol
over SSL it's IMO wrong to patronize the user. Port 465,993,995 will be a SSL
connection in the most cases, but not ever.
We can assist the user but not make the decision for him.

> What percentage of net users have any idea what the difference between
> "SMTP/STARTTLS" and "SMTP over SSL" is?

If you don't like the wording, make a suggestion for a better. STARTTLS (resp.
TLS) and SSL are the terms.
Comment 112 Sebastian Nohn 2003-09-23 07:45:53 PDT
I just don't know, what the problem is. I'm a user and I want to:

Fill in the same values in the same fields like in Outlook (Server is Server, 
User Name is User Name, Why isn't Port = Port?) and I want it to work. I don't 
want to think about what my server supports, I don't even care.

If you don't care about user demands, the users will switch to software that 
works for them.

I'm waiting since months for this and I'm sick of waiting. Another Mozilla-User 
has gone.
Comment 113 rr_mozilla 2003-09-23 08:04:10 PDT
re comment #109 - the URL http://www.eyrich-net.org/mozilla/pref_panels.html
variant #3 for all cases is my favorite. I am one of those normal net users who
fits comment #110 "What percentage of net users have any idea
what the difference between "SMTP/STARTTLS" and "SMTP over SSL" is? How can they
possibly make that decision?" OK, so how do I make the decision? I make the
decision because when I call AT&T tech support and complain that I can't get my
DSL mail to work (AT&T is one of those small ISPs where the current Mozilla mail
goes to hell), they tell me what is wrong. They don't know about Mozilla, but
they can tell me about ports and protocols. From Variant 3 I could pick the
right things. If Mozilla can't automagically figure it out or the coding for
such magic is extensive, then variant 3 works just fine for me. I don't _need_
Mozilla to be magic here, though. I do need to have _ALL_ the options, however,
including abitrary port setting as well as protocol selection. You can mark with
the phrase "typical" those options which are for users who don't care about
these things.

I'm just curious how good we will all feel when we realize how easy it is
resolve this solution although that certainly won't happen before the end of
next week. Meanwhile, I am limping with a kludged up old Mozilla. And others
will continue to leave.
Comment 114 Gervase Markham [:gerv] 2003-09-23 08:42:56 PDT
> There are four possibilities and the user must choose one. It's only one more as
> in the current UI.

If it's four more than we actually need, then it's four too many. That's what I
am trying to work out.

For example, if the user were just to give a server name, port (optional) and
username, can Mozilla query the server to find out what security transports it
supports, and just use the best one? It could then alert the user if they had
requested a secure connection (by entering a username) but one could not be
established.

Gerv
Comment 115 Christian Eyrich 2003-09-23 10:03:37 PDT
Sebastian, you just want to pick port 465 and Mozilla should use SMTP over SSL.
That would mean port 465 won't be usable for unencrypted SMTP or TLS. And you
won't be able to do SMTP over SSL on any other port.

And you'll have not four but the three choices you already have. With the
exception that the user won't know or understand that he has to enter "465" and
click "Never". Never, why never if I want SSL?
Ah, yes, have a look into the help - but if you have to look in the help *and*
you have only reduced possibilities, is this solution be better?
Comment 116 Sebastian Nohn 2003-09-23 10:23:06 PDT
What did you want to tell me? How to make my Mozilla work with my Mailserver?
Just like this: http://www.photoalbum.nohn.net/datenmuell/mozilla_ssl_tls?
Mozilla still hangs.
Comment 117 Christian Eyrich 2003-09-23 10:32:09 PDT
Gerv, that's possible. We'd still need one checkbox to ask for secure or not,
but not more.
But it's not easy because there's no way to just ask.
We'd need to test:

if(!connect_using_SSL())
else
  if(connect_using_normal_link())
  {
    if(supports_TLS())
    {
      if(start_TLS())
      {
        code...
      }
      else
        failure
    }
    else
      failure
  }

So it will be not only quite complex but slow to.
To save time we should be able to swap the order for SSL and TLS depending on
the port.
Comment 118 Christian Eyrich 2003-09-23 10:35:09 PDT
Sebastian, no, this doesn't work for now. But that would be what one would have
to set as soon as SMTP over SSL is implemented for the protocol.
Comment 119 John G. Myers 2003-09-23 10:49:07 PDT
The current default, "When available", is intended to be the "do the right
thing" setting.

Unfortunately, "When available" does not do the right thing in the face of an
active downgrade attack, where an active attacker makes it look like the server
doesn't support STARTTLS.  For security minded people who know the server
supports STARTTLS, the "Always" setting will cause the transaction to
(correctly) fail in this case, preserving confidentiality of the user's data.

For cases where the user doesn't care about security of SMTP, the "Never"
setting allows them to avoid the cost of SSL.  (The cost is probably measured in
number of server cert verification error dialog boxes).

As previously mentioned, I am for doing SMTP over SSL only on port 465, greying
out the radio buttons when the port field has the value of 465.
Comment 120 John Gerth 2003-09-23 12:16:52 PDT
Gerv wrote:
 > What are the technical and security issues here?
 > We need to outline the exact reasons why Mozilla can't just
 > Do The Right Thing without any UI at all. 

I'm pretty sure that the discussion in the range of comments 20-40 covered
the technical issues with the vast majority of the next 60 comments about
the UI.  From a purely technical standpoint, port number, encryption,
and authentication are conceptually independent issues even though
in practice they are usually linked.

The algorithm proposed by Christian at Comment #117 seems to me to 
"Do The Right Thing" in 99.44% of actual cases,

But as John Myers points out in Comment #119, care must be taken not to
be fooled in any instance as that's definitely "Not The Right Thing" for a 
security feature.

As John also points out, the culprit is a "When Available" option - which
has been the default.  Christian's implicit removal of "When Available" with
his "Secure" checkbox or your design in which the mere presence of a
username implies required encryption works for most real-world situations,
but there are conceivable configurations which have been laid out earlier
(see the port-mapped stunnel scenarios) that probably can only be handled
with an explicit ability to independently select port, encryption and 
authentication.

Since the world definitely has changed since January, it may now be
reasonable to propose that any server that requires authentication must
only do it under encryption and thus there's no need for a UI. I don't
know and have no idea who has the power to decide that.

For many of us, the current issue are:
  a) increasing numbers of ISPs, hotels, colleges, etc. no longer permit
     port 25 smtp connections to leave their domain. This poses
     tremendous problems for people with notebooks who move across
     domain boundaries and, for whatever reason, the most common solution
     provided is the port 465 (SSL-at-connect).  Even people who don't
     move may now have ISPS that only offer port 465. This has all become
     much more intense than when this discussion began in January.
  b) The developer (Kai) seems to have given up in August (Comment #93)
  c) Matthew Elvey seems not to be able to get a code review (Comment #99)

Most importantly, *all* versions of Mozilla, and for that matter Thunderbird,
just *hang* with no error indication at all when configured for an
SSL-at-connect port like 465. This is so much "The Completely Wrong and
Indefensible Thing to Do" and "Nearly Impossible to Explain to Most Users"
that anything which corrects at least that behavior is now urgent.
Comment 121 Christian Eyrich 2003-09-23 13:01:21 PDT
I'll try again to ask what's so difficult in having a couple of radiobuttons.

New attempt, variant 4 on my page:
"When available" is insecure -> drop it

We now have the answers "No", "Yes, TLS" and "Yes, SSL" for the question "Use
secure connection" - difficult?

What will Gervases typical user want? In case of no secure connection it's
simple: No. And he has heard of SSL and his provider told him of port 465 for
secure connection. Click on "Yes, SSL" and he'll have SSL on port 465 ready.

Everything else is still possible - the experienced user can use any combination
of ports and encryptions (or not) he wants.

I've no clue why e.g. Eudora and KMail users should have no problem with these
options but Mozilla users.

Sebastian, do you really wanna say you don't understand this UI?
Comment 122 Julien Pierre 2003-09-23 13:20:34 PDT
Gerv :

FYI, I think it's partially possible to have Mozilla probe the correct protocol.
If the user selects "secure" and enters a port, then Mozilla can try to do
either SSL with STARTTLS or SSL directly, and then choose the appropriate option.

*however*, doing that probe that requires that the user is online at the time
that he configures his mail server options. That requirement does not exist
today in Mozilla.

Therefore, I think a manual selection of the protocol and port must exist, and
that's what we have today in the proposed UI.

Automatic probing of the protocol would be nice, but it is additional work and
has its own issues (one of which I just mentioned above). Therefore, it should
be a separate bug (or RFE) from this one. Right now people (including myself),
even if they are aware of the issues, are simply unable to use their mail
servers because the protocol support exists in Mozilla - there is no option,
either automatic or manual.
Comment 123 Sebastian Nohn 2003-09-23 13:27:24 PDT
The fact is: It does not work NOW. What I care about is NOW (and was 1.4, 1.3
and so on). Does this going to work in 1.5? I don't think so. When will 1.6
come? 2 Months? 3 Months? 4 Months? Can I be sure, it works for me then? Is this
really just an user-interface-thing?

Remember: Now it does'nt work in any case, no matter what buttons you click and
fields you fill out.

If you want tell me how to configure this in any f*cking textfile, I don't care.
I'm already searching for a new mailer and if i find one that fits my needs I'll
switch over. It's just that simple. The point is: I don't know if and when
Mozilla is going to support this. First the Dev-Team laughed at me (that was in
the end of 2002 I think), then I was put off to the next version, and the next
version and the next version. I don't feel like waiting for this until next
year. By now I have 15 (!) different smtp-servers configured for 3 different
accounts. 4 of these differernt smtp-servers rewrite my From:-header. Just
because of the things that John stated in comment 120. Every time I change my
place I have to change the outgoing mailservers.
Comment 124 John G. Myers 2003-09-23 13:45:39 PDT
One of my suggestions for the SMTP support would be to have the code, when no
value is filled in the port field, first probe port 587 with fallback to port
25.  This would permit easy transition to the standard submission protocol.

This idea could be extended to also try port 465.  The problem with such port
scanning is that firewalls tend to handle connections to unknown ports by
dropping packets instead of returning ICMP errors, requiring the client to wait
for a timeout before trying the next port.

In response to comment 121, the "When available" choice is a much more secure
default than the alternative, "Never".  Without it, the vast majority of users,
who accept the default, will not be able to get the benefit of encrypted SMTP.

Comment 125 Idan Gazit 2003-09-23 13:48:34 PDT
So, I'm normally loath to pipe up on such issues, I've been following this bug
for a long time now, and my vote's been used for it since the day I signed up.

Irregardless of whatever final solution gets picked, sebastian (and the
thousands of people out there who don't understand why their mozilla-mailer
hangs upon connect) is right about one thing: now. Something now. Anything now!

Now, I'm not writing code for this project, so I really don't mean that in a
pressuring way.

However, as a means of boosting this bug's visibility, I think its priority
should be bumped from the feeble "enhancement" to something more along the lines
of "major" or "blocker". People going bug-safari through bugzilla are looking
for these bugs to quash, and none of them are looking at this bug (i'd be
willing to bet).

At the very least, a prominent warning/helpfile in the release notes for 1.5. As
spam ramps up and more ISPs demand encryption/authentication for email,
mozilla-mailer might be left holding the bill at the end of the party because
everybody suddenly wakes up and can't use it to do their email. The urgency
associated with this bug should blare out like a lighthouse, as many
(thousands?) of users *already* experience this, the bulk of whom assume mozilla
sucks and move on to other mailer, without anybody here hearing about it. I
don't think I'm overstating when I state that this is probably the single most
problematic, fixable bug mozilla has today.

As for UI debate et al, I've got nothing to add that finer minds haven't posted
already.

Somebody with the authority to do so mark this bug as something reasonably urgent.
Comment 126 Gervase Markham [:gerv] 2003-09-23 15:56:45 PDT
Chill out, people :-) I'm not proposing that we hold this bug up for another X
months to work out UI issues. I can see that people care strongly, and I don't
want to get in the way.

On the other hand, though, Mozilla contains far too much UI which is
over-complicated and incomprehensible. If it's possible to avoid more of it, I
would like to do so.

The algorithm in comment #117 looks good for the long term plan - and I would
hope it would be possible to try several methods simultaneously. We can then
cache the method used so if we talk to the same SMTP server again (the common
case) we can continue to use it.

The simplest UI I can imagine, which is understandable, would be exactly as it
is now:

Use secure connection:

( ) Always ( ) When available ( ) Never.

If it's "Always", send would fail rather than go insecurely.
It would be good to dispense with the "Never" setting, but I fear some of the
real-world considerations outlined in this bug mean that we need it.

As for port settings, Mozilla should use the standard port (insofar as there is
one) for each type of connection it tries. If (in rare circumstances) the user
needs to specifies the port, they should do it as a host:port pair in the host
box, and Mozilla should try only that port.

Gerv
Comment 127 Jeremy -Q- Manley 2003-09-24 15:03:51 PDT
I too would like some resolution on this bug.  This is the only one that is a
constant annoyance to me daily.  Although I have been using the browser for over
a year now, I just recently switched to using Mozilla as a mail client.  I still
haven't been able to fully switch over because of this BUG.  If we are looking
for voting for the UI as the last hurdle then my vote would be for anything that
worked.  Without any code changes I like the "Screenshot of changed UI for Patch
v2" just fine.  My feelings mirrors those of Comment #126 .  I'm really looking
forward to the changes here.
Comment 128 Matthew Elvey 2003-09-26 22:01:55 PDT
Would someone with r/sr comment on whether they'd be willing to approve a patch
that consists of just the non-UI code changes (temporarily making user.js edits
the interface to the new functionality)?
Seems like a clean solution to me.
The relatively unimportant UI issues are quite complex, and are holding up the
existing fix to this bug.

Gerv - there's discussion way above about whether the UI can be simplified, and
it's not at all clear that it can w/o causing breakage in rare cases, such as
the tunnel example discussed above by Kai in comment # 68.  Please comment.
Comment 129 Sebastian Nohn 2003-09-27 03:15:33 PDT
Of course I am. Just tell me to do. (I'm using 1.5RC1 on Windows)
Comment 130 Sebastian Nohn 2003-09-27 11:36:56 PDT
verified with 1.5rc2
Comment 131 Christian Eyrich 2003-09-29 13:42:25 PDT
Created attachment 132368 [details] [diff] [review]
Patch v3

Patch with simplified UI.
Comment 132 Gervase Markham [:gerv] 2003-09-29 14:40:37 PDT
Matthew: I am not suggesting we remove the ability to alter the port, so comment
68 doesn't apply.

Perhaps checking in the non-UI parts of this patch first, as you suggest, might
be a good way forward. 

I still maintain that the current UI is useless for 99.5% of users who have no
idea what SSL or STARTTLS are. We need to find a way to make it understandable,
preferably by making Mozilla smarter and removing the need for the UI entirely,
but perhaps in some other way.

Gerv
Comment 133 John Gerth 2003-09-29 21:59:53 PDT
It seems to me that if "host:port" is available to override the
default port, then Gerv's minimal UI could, for the 99.44%, case be
reduced to a checkbox labelled "Require Secure Connection" since this 
function is logically independent of the port specification anyway.

Mozilla would then behave as follows:

...Port
   Use 25 unless specifically overridden by host:port

...Encryption 
   Always attempt an SSL connection at the port, but allow
   an unencrytped connection if handshake fails.

   If SSL failed, attempt STARTTLS to converted connection to encryption.
   
   If neither SSL nor STARTTLS succeed and "Require Secure Connection"
   is checked, then outgoing connection has failed; otherwise continue
   on with possible authentication and sending of mail. 

The above would result in encrypted connections whenever they
were available whether asked for or not.  At one time this was
objected to because of the expense of encryption, but that might
no longer be an issue.  The user still has the ability to send
mail through an insecure server and even, however unwise it
might be, to send an id and password over an unencrypted connection,
but as long as "Require Secure Connection" had been checked, 
this algorithm would never send an unencrypted id or password.

  


Comment 134 Matthew Elvey 2003-09-30 11:59:02 PDT
Gerv, Excellent!  

So, let's get the core code checked in ASAP!  (I think Tbird has forked, if so,
it should go there too!)
Kai - sounds like gerv wil sr it if you submit it.

--

Then we can get ambitious about simplifying the UI, without the pressure.

John Gerth's UI: a good start. 

I HAVE CREATED OFFSHOOT Bug 220818: "Implement UI support for SMTPS, and
simplify the SMTP UI at the same time (Secure SMTP port 465 protocol, using SSL,
not STARTTLS)"

LET'S MOVE all UI work (and discussion) there.  This bug's comments are 10%
relevant, tops.

My issues with John Gerth's UI are posted there, instead of here. 
Comment 135 Gervase Markham [:gerv] 2003-09-30 15:59:02 PDT
> Kai - sounds like gerv wil sr it if you submit it.

Er... I'm not a super-reviewer.

Gerv
Comment 136 David :Bienvenu 2003-09-30 20:01:35 PDT
fix checked in.
Comment 137 David :Bienvenu 2003-10-06 08:57:50 PDT
reopening to reassign to ch.ey@gmx.net
Comment 138 David :Bienvenu 2003-10-06 09:12:03 PDT
->ch.ey@gmx.net, in case of followups, though this fix was basically kaie's
Comment 139 David :Bienvenu 2003-10-08 07:48:58 PDT
remarking fixed.
Comment 140 Jody Kovalick 2003-10-08 09:42:33 PDT
Wonderful. So, when does it show up in a release/build?
Comment 141 Christian Eyrich 2003-10-08 09:47:31 PDT
It's in the trunk nightlies since October 1st.
Comment 142 Jody Kovalick 2003-10-17 13:18:21 PDT
This issue does not appear to be resolved in release Mozilla 1.5 . 

can someone else confirm this and reopen it?
Comment 143 Christian Eyrich 2003-10-17 14:09:51 PDT
> This issue does not appear to be resolved in release Mozilla 1.5 . 

That's right.

> can someone else confirm this and reopen it?

Confirm yes, reopen, no.
But maybe the patch will make in a 1.5.1 if it will be nominated.
Comment 144 Jo Hermans 2003-10-28 12:03:11 PST
*** Bug 223976 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.