188384 - doesn't issue STARTTLS command when "Use TLS: Always" selected

Status: VERIFIED INVALID

(Core Graveyard :: Security: UI, defect)

Description

[Steve Huston]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2.1) Gecko/20021130

In testing a TLS-aware sendmail with SMTP AUTH, I can't get Mozilla to issue the
STARTTLS command to the server, even though "Use TLS" is set to always.  I did
get it to work once, but that was it (and I don't remember what was done). 
Tried on Linux and Mac OS X (v 1.2 on both).  I have my username filled in, but
when the RCPT TO: line hits the server, it denys relaying, and Mozilla gives me
an error message that I must authenticate first.  I am connecting on port 25;
SMTP AUTH isn't available until *after* STARTTLS is issued on the server.

Reproducible: Always

Steps to Reproduce:
1. Compose & send message
2. SMTP EHLO sent, then MAIL FROM:, RCPT TO:
3. "Relaying denied. Proper authentication required"

Actual Results:  
Relaying denied via mail server, popup window tells me message failed.

Expected Results:  
STARTTLS, EHLO, AUTH PLAIN, ...

I have not tested to see if Mozilla tries to (incorretly?) not use TLS+AUTH
since I'm on the same subnet as the server.  However, I'm setting this up for
roaming users who will need TLS turned on when they're outside the building, and
*can* use it within the building if they want.  

Here's a logdump from Sendmail, mozilla never issues the STARTTLS:

06022 >>> 220 diomedes.Princeton.EDU ESMTP Sendmail 8.12.5/8.12.5; Thu, 9 Jan 20
03 15:09:47 -0500
06022 <<< EHLO astro.princeton.edu
06022 >>> 250-diomedes.Princeton.EDU Hello prefect.astro.Princeton.EDU [128.112.
25.59], pleased to meet you
06022 >>> 250-ENHANCEDSTATUSCODES
06022 >>> 250-PIPELINING
06022 >>> 250-8BITMIME
06022 >>> 250-SIZE
06022 >>> 250-DSN
06022 >>> 250-ETRN
06022 >>> 250-STARTTLS
06022 >>> 250-DELIVERBY
06022 >>> 250 HELP
06022 <<< MAIL FROM:<[e-mail]>
06022 >>> 250 2.1.0 <[e-mail]>... Sender ok
06022 <<< RCPT TO:<[e-mail]>
06022 >>> 550 5.7.1 <[e-mail]>... Relaying denied. Proper auth
entication required.
06022 <<< [EOF]
06022 >>> 421 4.4.1 diomedes.Princeton.EDU Lost input channel from prefect.astro
.Princeton.EDU [128.112.25.59]

Comment 1

[John Unruh]

Looks like a dupe of bug 98399 

Comment 2

[Mitchell Stoltz (not reading bugmail)]

->PSM

Comment 3

[Steve Huston]

I at first thought it was a dupe also, and was just going to add a comment to
that one.  However, in that case there was a failure when STARTTLS is issued,
and it doesn't work.  In this case, STARTTLS isn't even issued; though they may
be related in the code somewhere.

Comment 4

[Charles Rosendahl]

This is in the client library.

From original message sniff log:
06022 >>> 250-ETRN
06022 >>> 250-STARTTLS
06022 >>> 250-DELIVERBY

So there is a starttls command issued.  It need not be in the order you mention
as long as it is issued beforehand.

I do believe it to be a dup.  You are connecting to which port?  What happens
when you choose 'when possible' instead of 'always'?

Comment 5

[Steve Huston]

Nope, that's the server's response to the 'EHLO'.  Lines starting with <<< are
the client's chatter.

Comment 6

[Steve Huston]

Ugh, brain-dead; must be too cold in the server room today :)  In response to
the rest, port 25, and setting it to "When Possible" does no change.

Also the other bug mentions a crash; I just get a polite "You have to
authenticate first" message and the mail doesn't get sent.

Comment 7

[Steve Huston]

Just tried this using Apple's "Mail" program, here's what Sendmail saw when it
worked (apologies for the length of this)

06562 >>> 220 diomedes.Princeton.EDU ESMTP Sendmail 8.12.5/8.12.5; Thu, 9 Jan 20
03 17:33:35 -0500
06562 <<< EHLO prefect.astro.Princeton.EDU
06562 >>> 250-diomedes.Princeton.EDU Hello prefect.astro.Princeton.EDU [128.112.
25.59], pleased to meet you
06562 >>> 250-ENHANCEDSTATUSCODES
06562 >>> 250-PIPELINING
06562 >>> 250-8BITMIME
06562 >>> 250-SIZE
06562 >>> 250-DSN
06562 >>> 250-ETRN
06562 >>> 250-STARTTLS
06562 >>> 250-DELIVERBY
06562 >>> 250 HELP
06562 <<< STARTTLS
06562 >>> 220 2.0.0 Ready to start TLS
06562 <<< EHLO prefect.astro.Princeton.EDU
06562 >>> 250-diomedes.Princeton.EDU Hello prefect.astro.Princeton.EDU [128.112.
25.59], pleased to meet you
06562 >>> 250-ENHANCEDSTATUSCODES
06562 >>> 250-PIPELINING
06562 >>> 250-8BITMIME
06562 >>> 250-SIZE
06562 >>> 250-DSN
06562 >>> 250-ETRN
06562 >>> 250-AUTH LOGIN PLAIN
06562 >>> 250-DELIVERBY
06562 >>> 250 HELP
06562 <<< AUTH PLAIN (Snipped)
06562 >>> 235 2.0.0 OK Authenticated
06562 <<< MAIL FROM:<[e-mail]>
06562 >>> 250 2.1.0 <[e-mail]>... Sender ok
06562 <<< RCPT TO:<[e-mail]>
06562 >>> 250 2.1.5 <[e-mail]>... Recipient ok
06562 <<< DATA
06562 >>> 354 Enter mail, end with "." on a line by itself

First it says EHLO, gets the response, then issues the STARTTLS; another EHLO to
get started now that the TLS session is established, and now AUTH is available.
 Do the AUTH and send the mail.

Comment 8

[Steve Huston]

(Hope I'm doing this right, don't know if there's a policy for closing a bug)

I seem to have figured out the problem.  Today I tried again, and noticed that
there were three instances of the same outgoing SMTP server listed when you
click the "Advanced" button.  One was set as default, port 25, and "Use SSL
Always".  The other two had no setting for port number, and "Use SSL Never". 
When I deleted the two non-default ones with no SSL settings, it now works fine.

Slightly confused by this, however it states clearly that things can be
unpredictable if you define multiple outgoing SMTP servers.  What gets me is
that I don't recall doing that, but I'm not going to worry about it right now. 
Seems the bug report was invalid to me, so I might as well close it out.

Comment 9

[John Unruh]

Verified invalid.