Closed
Bug 285869
Opened 20 years ago
Closed 6 years ago
Stall when using TLS with POP3
Categories
(MailNews Core :: Networking: POP, defect)
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
Comment 1•20 years ago
|
||
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
Comment 2•20 years ago
|
||
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.
Updated•20 years ago
|
Assignee: sspitzer → mail
Comment 3•17 years ago
|
||
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
| Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
Comment 4•6 years ago
|
||
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.
Description
•