Closed Bug 285869 Opened 20 years ago Closed 6 years ago

Stall when using TLS with POP3

Categories

(MailNews Core :: Networking: POP, defect)

1.8 Branch
x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: peter, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217

When enabling "TLS, if available" or "TLS" for a POP3 account, Mozilla Mails
stalls during communication with the POP3 server (the actual application does
not stall, but it suddently stops talking to the server, and thus no mails are
downloaded)

Reproducible: Always

Steps to Reproduce:
1. Create new POP3 account
2. Check "TLS, if available" or "TLS" under "Use secure connection:"
3. Uncheck "Use secure authentication"
4. Try fetching mail from that specific server (assuming that the server has TLS
support)

Actual Results:  
The progress indicator in the status bar, stays in "indetermine" state (not
really working as an actual progress indicator, but just moving some angular
lines from left to right in all eternity). No mail is downloadet.

Expected Results:  
It should have downloaded my mails and disconnected from the POP3 server

Doing a network monitor during the transaction reveals the following:

With TLS:

S: +OK POP3 server ready
C: CAPA
S: +OK Capability list follows
S: AUTH-RESP-CODES
S: EXPIRE NEVER
S: IMPLEMENTATION mypop3d
S: PIPELINING
S: RESP-CODES
S: SASL LOGIN
S: STLS
S: TOP
S: UIDL
S: USER
S: .

And then mozilla stops sending anything. It should however have sent "STLS", the
POP3 server would respond +OK, and then Mozilla should initiate TLS, and when
done, send "CAPA" again to check for the new capabilities (They may change when
in TLS)

With "TLS, if available", the result is almost the same, except Mozilla sends
AUTH before CAPA:

S: +OK POP3 server ready
C: AUTH
S: -ERR Invalid command
C: CAPA
S: +OK  Capability list follows
(etc)

So first of all, there must be a problem when checking for the STLS in the
capability string, and second I see no reason why Mozilla should send AUTH with
no arguments as the first thing ever.

Finally, I must confess that this POP3 server is entirely home made by me, and
thus you will not be able to reproduce the failure with exactly that server
software, however I am confident that the data Mozilla receives is correct. The
STLS line exists in the capability list as it should.

References:
 RFC 2449 - POP3 Extension Mechanism
 RFC 2959 - Using TLS with IMAP, POP3 and ACAP
I don't know if Christian ever had a pop3 server to test against. But looking at
this code:

PRInt32 nsPop3Protocol::ProcessAuth()
{
    if (!m_tlsEnabled)
    {
      if(TestCapFlag(POP3_HAS_STLS))
      {


shouldn't that be if (m_tlsEnabled) ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Ah, never mind - m_tlsEnabled means that we've entered TLS, not that the user
has enabled tls. So it looks like it should at least send STLS, as long as PSM
is insalled (and I don't think you can get a seamonkey build w/o PSM, unless you
build it yourself.
Assignee: sspitzer → mail
Can you reproduce with SeaMonkey v1.1.9 ?
Can you reproduce with current SeaMonkey v2.0a1pre ?
Assignee: mail → nobody
Component: MailNews: Account Manager → Networking: POP
Product: Mozilla Application Suite → Core
QA Contact: networking.pop
Version: unspecified → 1.8 Branch
Product: Core → MailNews Core
paul seems to be gone, and 13 years is a very long time
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.