Closed Bug 135357 (smtps) Opened 23 years ago Closed 21 years ago

Implement Secure SMTP port 465 protocol, using SSL, not STARTTLS

Categories

(MailNews Core :: Networking: SMTP, enhancement)

Product:
MailNews Core
Component:
Networking: SMTP
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: abwillis1, Assigned: ch.ey)

References

(
URL
)

Details

(Keywords: imap-interop)

Attachments

(3 files, 3 obsolete files)

Screen Shot of Patch v2
13.99 KB, image/png
Details
Screenshot of changed UI for Patch v2
8.83 KB, image/png
Details
Patch v3
11.43 KB, patch
Bienvenu
: review+
Details | Diff | Splinter Review
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
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.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
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
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
What it acts like is that it isn't sending the login information and is waiting for the server to request it.
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
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
Confirmed, same problem on win2k machine, 3-28 nightly build.
not OS/2 specific
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: OS/2 → All
Hardware: Other → All
I can create a test id on one of these servers if it is helpful. Andy
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
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.
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.
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
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.
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.
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.
Severity: normal → enhancement
Summary: secure smtp authorization → Support Secure SMTP port 465 protocol
*** Bug 189281 has been marked as a duplicate of this bug. ***
*** Bug 173415 has been marked as a duplicate of this bug. ***
This looks like the same as my report # 132559. Ed
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.
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."
Correct I still am unable to send mail through mail.attbi.com on port 465. It just hangs as before.
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. :(
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.
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.
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.
Summary: Support Secure SMTP port 465 protocol → Implement Secure SMTP port 465 protocol, using SSL, not STARTTLS
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
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.
Also, Keyword nsenterprise per Comment #19?
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
Assigning to self, as I have a patch.
Alias: smtps
Assignee: mscott → kaie
Attached patch Patch v1 (obsolete) — — Splinter Review
Has anyone tried this? If so, what is the proper way to patch the product?
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!
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).
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.
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
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.
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 #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 39: s/Openoffice.org/Ximian/
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
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
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.
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?
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.
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 :-)
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!
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.
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?
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?
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.
I'd be willing to review code. I'm neither the module owner nor their delegate, though.
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.
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".
> 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 51: Outlook Express 6 (which far outnumbers Outlook XP), uses STARTTLS *only* with port 25, which is the opposite behavior.
> 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.
Attached image Screen Shot of Patch v1 (obsolete) —
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.
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 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"
> 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.
Attached patch Patch v2 (obsolete) — — Splinter Review
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
Attachment #115290 - Attachment is obsolete: true
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.
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.
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?
>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?
> 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.
Attachment #125953 - Attachment is obsolete: true
Comment on attachment 125969 [details] [diff] [review] Patch v2 Seth, do you want this patch?
Attachment #125969 - Flags: superreview?(sspitzer)
Attachment #125969 - Flags: review?(sspitzer)
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.
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.
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
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
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.
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.
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.
Just want to confirm that Kai's response eliminated my objection. I'm all for Kai's patch. Seth?
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.
Flags: blocking1.5a?
Flags: blocking1.4.x?
Blocks: 114225
not for 1.4.1 and mozilla1.5a is already released. unsetting blocking request.
Flags: blocking1.5a?
Flags: blocking1.4.x?
Flags: blocking1.4.x-
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.)
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.
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 =)
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.
*** Bug 211426 has been marked as a duplicate of this bug. ***
*** Bug 214660 has been marked as a duplicate of this bug. ***
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.)
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.)
*** Bug 215829 has been marked as a duplicate of this bug. ***
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 .
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: ____
The new UI would work fine for my users
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.
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. :-)
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.
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.
Verified with 1.5b, still does'nt work.
*** Bug 217944 has been marked as a duplicate of this bug. ***
What needs to happen to get this into the path for 1.5 Final, Thunderbird, or something? Is this stalled?
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!
*** Bug 132559 has been marked as a duplicate of this bug. ***
*** Bug 114225 has been marked as a duplicate of this bug. ***
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 ...
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?
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.
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)
Keywords: interop, nsCatFood
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.
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?
*** Bug 219840 has been marked as a duplicate of this bug. ***
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.
URL: http://www.eyrich-net.org/mozilla/pre...
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
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.
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.
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.
> 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
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?
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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
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.
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.
Attachment #125969 - Flags: superreview?(sspitzer)
Attachment #125969 - Flags: review?(sspitzer)
Of course I am. Just tell me to do. (I'm using 1.5RC1 on Windows)
verified with 1.5rc2
Attached patch Patch v3 — — Splinter Review
Patch with simplified UI.
Attachment #125969 - Attachment is obsolete: true
Attachment #132368 - Flags: review?(bienvenu)
Attachment #132368 - Flags: review?(bienvenu) → review+
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
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.
Blocks: 220818
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.
No longer blocks: 114225, 220818
> Kai - sounds like gerv wil sr it if you submit it. Er... I'm not a super-reviewer. Gerv
fix checked in.
Status: NEW → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → FIXED
reopening to reassign to ch.ey@gmx.net
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
->ch.ey@gmx.net, in case of followups, though this fix was basically kaie's
Assignee: kaie → ch.ey
Status: REOPENED → NEW
remarking fixed.
Status: NEW → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
Wonderful. So, when does it show up in a release/build?
It's in the trunk nightlies since October 1st.
This issue does not appear to be resolved in release Mozilla 1.5 . can someone else confirm this and reopen it?
> 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.
*** Bug 223976 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: