POP3 does not automatically download new mail using GSSAPI Authentication

RESOLVED WORKSFORME

Status

Thunderbird
Security
--
major
RESOLVED WORKSFORME
9 years ago
2 years ago

People

(Reporter: Phillip Macey, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [has protocol logs])

Attachments

(6 attachments, 4 obsolete attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)
Build Identifier: 2.0.0.23 (20090812)

I have configured a POP3 account using the following options ('Server Settings' in the 'Account Settings' window):
* Use secure authentication
* Check for new messages at startup
* Check for new messages every _5_ minutes

I find that whenever I have 'Secure Authentication' enabled, Thunderbird does not automatically download new mail. I can confirm that the mail is sitting on the POP server waiting to be collected. If the unread mail is on the server when I start TB, it will be successfully downloaded. Any mail that is delivered to my account after TB starts will not be downloaded - unless I click the 'Get Mail' button. If I turn off 'Secure Authentication', TB will ask me for a password and new messages will be downloaded whenever they are delivered to my account.

I get the same behaviour using both a Windows XP and a Linux (Centos5.2) client.

Reproducible: Always

Steps to Reproduce:
1. Configure POP account to use Secure Authentication
2. Check that the account is configured to 'Check for new messages at startup' and 'Check for new messages every XX minutes'
3. Send yourself an email
4. Wait.. forever while thunderbird silently doesnt notice the new mail
4. Click 'Get Mail' and thunderbird will download all of the mail's that arrived while you were waiting. Alternativly, restart thunderbird and it will download all of the mails when it starts back up again. Return to step 3.
Actual Results:  
Regardless of how long you wait, TB will not download any new mail except when you either 
i) click 'Get Mail'.
ii) restart thunderbird.


Expected Results:  
TB should automatically use my GSSAPI/Kerberos credentials to log in to the POP server and retrieve new mails if they exist. If for some reason it is unable to do that (which it is not - it works when I 'Get Mail') then it should pop up with an error message of some sort.

This was the only logging I got out of thunderbird using NSPR_LOG_MODULES="negotiateauth:5,imap:5,gssapi:5,pop:5"

It doesnt look especially usefull to me.. but what would I know.

-1212844352[a1deeb0]: entering nsAuthGSSAPI::nsAuthGSSAPI()
-1212844352[a1deeb0]: Attempting to load gss functions
-1212844352[a1deeb0]: entering nsAuthGSSAPI::Init()
-1212844352[a1deeb0]: entering nsAuthGSSAPI::GetNextToken()
-1212844352[a1deeb0]:   leaving nsAuthGSSAPI::GetNextToken [rv=0]
-1212844352[a1deeb0]: entering nsAuthGSSAPI::GetNextToken()
-1212844352[a1deeb0]:   leaving nsAuthGSSAPI::GetNextToken [rv=4b0028]
-1212844352[a1deeb0]: entering nsAuthGSSAPI::nsAuthGSSAPI()
-1212844352[a1deeb0]: entering nsAuthGSSAPI::Init()
-1212844352[a1deeb0]: entering nsAuthGSSAPI::GetNextToken()
-1212844352[a1deeb0]:   leaving nsAuthGSSAPI::GetNextToken [rv=0]
-1212844352[a1deeb0]: entering nsAuthGSSAPI::GetNextToken()
-1212844352[a1deeb0]:   leaving nsAuthGSSAPI::GetNextToken [rv=4b0028]
(Reporter)

Comment 1

9 years ago
Oh, and one extra comment: I also was able to reproduce exactly the same behaviour in the TB3 beta as well.
Phil could you cleanup if necessary the log and attach it here. using TB3 beta for the log would be best. Thanks
Component: General → Security
QA Contact: general → thunderbird
(Reporter)

Comment 3

9 years ago
I had one case where TB3 seemed to work ok - it downloaded the new mail automatically. The rest of the time it has not. I dont know what I did to cause it to work that once -  AFAIK I did nothing differently.

If I select (click on) the account name (not the inbox), I found that TB3 does not pick up the new mail. I left it running with new mail on the server for at least 20 minutes and it did not notice the new mail. I will attach the log in a minute. (thunderbird-not-inbox.log)

I restarted Tb3, it picked up the new mail that was waiting on the server. I sent one more test message and then clicked on the Inbox folder. After waiting ~20 minutes, the new mail has not been picked up by TB3. (thunderbird-inbox.log)

When I restart TB3, it picks up the new mail immediately. I send another test email - and then I wait another 20 minutes. Still the mail does not get picked up. I click 'Get Mail'. The mail is recieved. (thunderbird-get.log)

I double checked the account settings in TB. It is set to:
* Check for new messages at startup
* Check for new messages every _10_ minutes
* Automatically download new messages
* Leave messages on server
(Reporter)

Comment 4

9 years ago
Created attachment 396171 [details]
Logs from TB3 after waiting and then clicking Get Mail
(Reporter)

Comment 5

9 years ago
Created attachment 396172 [details]
Logs from TB3 while viewing mails in inbox
(Reporter)

Comment 6

9 years ago
Created attachment 396173 [details]
Logs from TB3 while viewing account
(Reporter)

Comment 7

9 years ago
Created attachment 396174 [details]
Logs from TB3 after restarting with new mail on server
Attachment #396172 - Attachment mime type: application/octet-stream → text/plain
Logs look all the same with :

0[1726140]:   InitSSPI
0[1726140]: Using SPN of [pop/host.example.com]
0[1726140]: entering nsAuthSSPI::GetNextToken()
0[1726140]: entering nsAuthSSPI::GetNextToken()
(Reporter)

Comment 9

9 years ago
Yep they are all quite similar. Are there any extra logging options that I could enable to get more useful info? 
(Last time I checked, at least one of the options that I used was not documented on the MailNews:Logging page so I dont know if there are any others that are not mentioned there. I just happened to bump into the ones I used on a different web page - I cant remember where)
(Reporter)

Comment 10

9 years ago
Is there any extra info I can get that would make this easier to debug/fix?
adding a few people that might know what to ask.
Whiteboard: [has protocol logs]

Comment 12

9 years ago
This could be long standing issue that fixed just yesterday in bug 511806. Could you turn off SSPI and log again? network.auth.use-sspi;false 
Is your KDC Windows AD or MIT Kerberos?

Comment 13

9 years ago
I don't really know of anything that would make gssapi work sometimes and not others - other than we don't force the KDC credentials to be fetched; you have to do that yourself before running TB. You might try today's nightly build and see if it works better.
(Reporter)

Comment 14

9 years ago
(In reply to comment #12)
> This could be long standing issue that fixed just yesterday in bug 511806.
> Could you turn off SSPI and log again? network.auth.use-sspi;false 
I cant see that bug. 
I have just set network.auth.use-sspi to false and am still getting exactly the same behaviour. When I first start up the client, it retrieves whatever mail is waiting for me on the server. Any mail that arrives after that point is not automatically picked up. I sent myself a couple of emails and I could see them arrive on the mail server but after waiting >20 minutes they never appeared in the client. When I explicitly click the Get Mail button, all the mail that has been waiting for me on the server is retrieved.

The logs say:
0[1727140]: entering nsAuthGSSAPI::nsAuthGSSAPI()
0[1727140]: Attempting to load gss functions
0[1727140]: entering nsAuthGSSAPI::Init()
0[1727140]: entering nsAuthGSSAPI::GetNextToken()
0[1727140]:   leaving nsAuthGSSAPI::GetNextToken [rv=0]
0[1727140]: entering nsAuthGSSAPI::GetNextToken()
0[1727140]:   leaving nsAuthGSSAPI::GetNextToken [rv=4b0028]


For what its worth, SSPI is a windows only thing isnt it? I had the same problem in both a Windows and Linux client. Note that I have not tested the latest Beta on Linux. My testing with the Beta's has been limited to windows only.

> Is your KDC Windows AD or MIT Kerberos?
Windows AD

Comment 15

9 years ago
Unfortunately fix for bug 511806 not yet landed. Also do you have Kerberos for Windows installed? If not I wounder how it even works on Windows with SSPI disabled. I dunno anything about POP3, could be this bug in auto checking email, maybe SSPI/GSSAPI involved but I doubt that. I've seen such bugs when people not getting emails automatically after period of time.

Comment 16

9 years ago
I mean MIT Kerberos for Windows
(In reply to comment #15)
> Unfortunately fix for bug 511806 not yet landed.

It has landed in the 3.1 nightly builds that are available from here:

ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-central-trunk/
(Reporter)

Comment 18

9 years ago
(In reply to comment #16)
> I mean MIT Kerberos for Windows

I thought not, but apparently I do. Looks like someone else has installed it at some stage.
(Reporter)

Comment 19

9 years ago
(In reply to comment #13)
(In reply to comment #16)
> You might try today's nightly build and see if it works better.

I tried the build that I found here: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/3.0b3-candidates/build2/win32/en-US/
Is this a different file to the one found in latest-comm-central-trunk?

My results were no different. I got a tcpdump of it all on the server side and interestingly, the only network traffic I saw was when I initially started TB. After that, TB did not even contact the server after 15 minutes.

root@server cur]# tcpdump host client
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
17:39:42.198390 IP client.srdp > server.pop3: S 41249208:41249208(0) win 64240 <mss 1460,nop,nop,sackOK>
17:39:42.230733 IP server.pop3 > client.srdp: S 356530254:356530254(0) ack 41249209 win 5840 <mss 1460,nop,nop,sackOK>
17:39:42.201340 IP client.srdp > server.pop3: . ack 1 win 64240
17:39:42.202142 IP server.pop3 > client.srdp: P 1:21(20) ack 1 win 5840
17:39:42.369961 IP client.srdp > server.pop3: P 1:7(6) ack 21 win 64220
17:39:42.370017 IP server.pop3 > client.srdp: . ack 7 win 5840
17:39:42.370360 IP server.pop3 > client.srdp: P 21:49(28) ack 7 win 5840
17:39:42.485848 IP client.srdp > server.pop3: P 7:13(6) ack 49 win 64192
17:39:42.486072 IP server.pop3 > client.srdp: P 49:140(91) ack 13 win 5840
17:39:42.504976 IP client.srdp > server.pop3: P 13:26(13) ack 140 win 64101
17:39:42.505580 IP server.pop3 > client.srdp: P 140:144(4) ack 26 win 5840
17:39:42.512499 IP client.srdp > server.pop3: . 26:1486(1460) ack 144 win 64097
17:39:42.512505 IP client.srdp > server.pop3: . 1486:2946(1460) ack 144 win 64097
17:39:42.512540 IP server.pop3 > client.srdp: . ack 2946 win 11680
17:39:42.512510 IP client.srdp > server.pop3: P 2946:4024(1078) ack 144 win 64097
17:39:42.519066 IP server.pop3 > client.srdp: P 144:328(184) ack 4024 win 14600
17:39:42.525521 IP client.srdp > server.pop3: P 4024:4026(2) ack 328 win 63913
17:39:42.525981 IP server.pop3 > client.srdp: P 328:400(72) ack 4026 win 14600
17:39:42.553932 IP client.srdp > server.pop3: P 4026:4104(78) ack 400 win 63841
17:39:42.603459 IP server.pop3 > client.srdp: . ack 4104 win 14600
17:39:42.648462 IP server.pop3 > client.srdp: P 400:416(16) ack 4104 win 14600
17:39:42.650777 IP client.srdp > server.pop3: P 4104:4110(6) ack 416 win 63825
17:39:42.651031 IP server.pop3 > client.srdp: . ack 4110 win 14600
17:39:42.651314 IP server.pop3 > client.srdp: P 416:428(12) ack 4110 win 14600
17:39:42.654520 IP client.srdp > server.pop3: P 4110:4116(6) ack 428 win 63813
17:39:42.654759 IP server.pop3 > client.srdp: P 428:504(76) ack 4116 win 14600
17:39:42.656438 IP client.srdp > server.pop3: P 4116:4122(6) ack 504 win 63737
17:39:42.656776 IP server.pop3 > client.srdp: P 504:652(148) ack 4122 win 14600
17:39:42.658721 IP client.srdp > server.pop3: P 4122:4130(8) ack 652 win 63589
17:39:42.660227 IP server.pop3 > client.srdp: P 652:1932(1280) ack 4130 win 14600
17:39:42.848995 IP client.srdp > server.pop3: P 4130:4136(6) ack 1932 win 64240
17:39:42.850202 IP server.pop3 > client.srdp: FP 1932:1950(18) ack 4136 win 14600
17:39:42.851038 IP client.srdp > server.pop3: . ack 1951 win 64222
17:39:42.860564 IP client.srdp > server.pop3: F 4136:4136(0) ack 1951 win 64222
17:39:42.860597 IP server.pop3 > client.srdp: . ack 4137 win 14600

35 packets captured
39 packets received by filter
0 packets dropped by kernel
[root@server cur]# date
Fri Sep 11 17:54:06 EST 2009
[root@server cur]#

Comment 20

9 years ago
This build is 2 months old. I suggest you to tcpdump traffic tcpdump -s 0 -ieth0 -w sample.cap and attach it here. But I suggest to do this after clean reboot of system. You can capture more specific ports only if you wish 110 tcp and 88udp/tcp.
And take a build in the directory pointed in comment #17 as they are different.
(Reporter)

Comment 22

9 years ago
Installed from the URL in comment #17.
Started 'tcpdump -s 0 host client' on IMAP server
Sent email to user@server
Started thunerbird/shredder:
* Environment was set to:
    NSPR_LOG_MODULES=negotiateauth:5,imap:5,gssapi:5,pop:5
    NSPR_LOG_FILE=C:\thunderbird.log
* The email I sent was retrieved immediately on startup

Sent myself another email and waited >20 minutes (double the time that should be required for the mail to be retrieved).
The mail was not retrieved - there was no network traffic.
I clicked 'Get Mail' - the mail was retrieved and I see network traffic. Close thunderbird.

Here is the thunderbird log:
0[1727140]:   nsAuthSSPI::Init
0[1727140]:   InitSSPI
0[1727140]: Using SPN of [pop/server]
0[1727140]: entering nsAuthSSPI::GetNextToken()
0[1727140]: entering nsAuthSSPI::GetNextToken()
0[1727140]:   nsAuthSSPI::Init
0[1727140]: Using SPN of [pop/server]
0[1727140]: entering nsAuthSSPI::GetNextToken()
0[1727140]: entering nsAuthSSPI::GetNextToken()


Here is the tcpdump:
[root@server ~]# tcpdump -s 0 host client
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:55:34.304797 IP client.hermes > server.pop3: S 101243148:101243148(0) win 64240 <mss 1460,nop,nop,sackOK>
11:55:34.306446 IP server.pop3 > client.hermes: S 4247685446:4247685446(0) ack 101243149 win 5840 <mss 1460,nop,nop,sackOK>
11:55:34.306277 IP client.hermes > server.pop3: . ack 1 win 64240
11:55:34.306687 IP server.pop3 > client.hermes: P 1:21(20) ack 1 win 5840
11:55:34.439271 IP client.hermes > server.pop3: P 1:7(6) ack 21 win 64220
11:55:34.439308 IP server.pop3 > client.hermes: . ack 7 win 5840
11:55:34.439608 IP server.pop3 > client.hermes: P 21:49(28) ack 7 win 5840
11:55:34.514004 IP client.hermes > server.pop3: P 7:13(6) ack 49 win 64192
11:55:34.514343 IP server.pop3 > client.hermes: P 49:140(91) ack 13 win 5840
11:55:34.532742 IP client.hermes > server.pop3: P 13:26(13) ack 140 win 64101
11:55:34.533375 IP server.pop3 > client.hermes: P 140:144(4) ack 26 win 5840
11:55:34.537805 IP client.hermes > server.pop3: . 26:1486(1460) ack 144 win 64097
11:55:34.537807 IP client.hermes > server.pop3: . 1486:2946(1460) ack 144 win 64097
11:55:34.537838 IP server.pop3 > client.hermes: . ack 2946 win 11680
11:55:34.537807 IP client.hermes > server.pop3: P 2946:4024(1078) ack 144 win 64097
11:55:34.544353 IP server.pop3 > client.hermes: P 144:324(180) ack 4024 win 14600
11:55:34.577198 IP client.hermes > server.pop3: P 4024:4026(2) ack 324 win 63917
11:55:34.577830 IP server.pop3 > client.hermes: P 324:396(72) ack 4026 win 14600
11:55:34.579383 IP client.hermes > server.pop3: P 4026:4104(78) ack 396 win 63845
11:55:34.619911 IP server.pop3 > client.hermes: . ack 4104 win 14600
11:55:34.706464 IP server.pop3 > client.hermes: P 396:412(16) ack 4104 win 14600
11:55:34.707872 IP client.hermes > server.pop3: P 4104:4110(6) ack 412 win 63829
11:55:34.708154 IP server.pop3 > client.hermes: . ack 4110 win 14600
11:55:34.708443 IP server.pop3 > client.hermes: P 412:424(12) ack 4110 win 14600
11:55:34.712634 IP client.hermes > server.pop3: P 4110:4116(6) ack 424 win 63817
11:55:34.712920 IP server.pop3 > client.hermes: P 424:452(28) ack 4116 win 14600
11:55:34.715766 IP client.hermes > server.pop3: P 4116:4122(6) ack 452 win 63789
11:55:34.716284 IP server.pop3 > client.hermes: P 452:480(28) ack 4122 win 14600
11:55:34.719194 IP client.hermes > server.pop3: P 4122:4130(8) ack 480 win 63761
11:55:34.719674 IP server.pop3 > client.hermes: P 480:1760(1280) ack 4130 win 14600
11:55:34.733761 IP client.hermes > server.pop3: P 4130:4138(8) ack 1760 win 64240
11:55:34.734080 IP server.pop3 > client.hermes: P 1760:1787(27) ack 4138 win 14600
11:55:34.756813 IP client.hermes > server.pop3: P 4138:4144(6) ack 1787 win 64213
11:55:34.758419 IP server.pop3 > client.hermes: FP 1787:1823(36) ack 4144 win 14600
11:55:34.758923 IP client.hermes > server.pop3: . ack 1824 win 64177
11:55:34.768144 IP client.hermes > server.pop3: F 4144:4144(0) ack 1824 win 64177
11:55:34.768184 IP server.pop3 > client.hermes: . ack 4145 win 14600

# This is when I clicked Get Mail
12:27:06.835799 IP client.watilapp > server.pop3: S 1173705037:1173705037(0) win 64240 <mss 1460,nop,nop,sackOK>
12:27:06.835986 IP server.pop3 > client.watilapp: S 1958620613:1958620613(0) ack 1173705038 win 5840 <mss 1460,nop,nop,sackOK>
12:27:06.837285 IP client.watilapp > server.pop3: . ack 1 win 64240
12:27:06.838209 IP server.pop3 > client.watilapp: P 1:21(20) ack 1 win 5840
12:27:06.865357 IP client.watilapp > server.pop3: P 1:7(6) ack 21 win 64220
12:27:06.865389 IP server.pop3 > client.watilapp: . ack 7 win 5840
12:27:06.865791 IP server.pop3 > client.watilapp: P 21:112(91) ack 7 win 5840
12:27:06.870626 IP client.watilapp > server.pop3: P 7:20(13) ack 112 win 64129
12:27:06.871319 IP server.pop3 > client.watilapp: P 112:116(4) ack 20 win 5840
12:27:06.873440 IP client.watilapp > server.pop3: . 20:1480(1460) ack 116 win 64125
12:27:06.873441 IP client.watilapp > server.pop3: . 1480:2940(1460) ack 116 win 64125
12:27:06.873475 IP server.pop3 > client.watilapp: . ack 2940 win 11680
12:27:06.873442 IP client.watilapp > server.pop3: P 2940:4018(1078) ack 116 win 64125
12:27:06.879077 IP server.pop3 > client.watilapp: P 116:296(180) ack 4018 win 14600
12:27:06.888199 IP client.watilapp > server.pop3: P 4018:4020(2) ack 296 win 63945
12:27:06.888910 IP server.pop3 > client.watilapp: P 296:368(72) ack 4020 win 14600
12:27:06.890034 IP client.watilapp > server.pop3: P 4020:4098(78) ack 368 win 63873
12:27:06.929567 IP server.pop3 > client.watilapp: . ack 4098 win 14600
12:27:07.000137 IP server.pop3 > client.watilapp: P 368:384(16) ack 4098 win 14600
12:27:07.018484 IP client.watilapp > server.pop3: P 4098:4104(6) ack 384 win 63857
12:27:07.018824 IP server.pop3 > client.watilapp: . ack 4104 win 14600
12:27:07.019141 IP server.pop3 > client.watilapp: P 384:396(12) ack 4104 win 14600
12:27:07.020770 IP client.watilapp > server.pop3: P 4104:4110(6) ack 396 win 63845
12:27:07.021030 IP server.pop3 > client.watilapp: P 396:424(28) ack 4110 win 14600
12:27:07.021915 IP client.watilapp > server.pop3: P 4110:4116(6) ack 424 win 63817
12:27:07.022323 IP server.pop3 > client.watilapp: P 424:452(28) ack 4116 win 14600
12:27:07.024018 IP client.watilapp > server.pop3: P 4116:4124(8) ack 452 win 63789
12:27:07.024669 IP server.pop3 > client.watilapp: P 452:1732(1280) ack 4124 win 14600
12:27:07.044654 IP client.watilapp > server.pop3: P 4124:4132(8) ack 1732 win 64240
12:27:07.044995 IP server.pop3 > client.watilapp: P 1732:1759(27) ack 4132 win 14600
12:27:07.093426 IP client.watilapp > server.pop3: P 4132:4138(6) ack 1759 win 64213
12:27:07.095190 IP server.pop3 > client.watilapp: FP 1759:1795(36) ack 4138 win 14600
12:27:07.096818 IP client.watilapp > server.pop3: . ack 1796 win 64177
12:27:07.118146 IP client.watilapp > server.pop3: F 4138:4138(0) ack 1796 win 64177
12:27:07.118183 IP server.pop3 > client.watilapp: . ack 4139 win 14600

72 packets captured
78 packets received by filter
0 packets dropped by kernel
[root@server ~]#

Comment 23

9 years ago
Phillip, this tcpdump is useless for me since its not provide any information about data in packets. Please capture data as I suggested and attach it here.
(Reporter)

Comment 24

9 years ago
(In reply to comment #23)
> Phillip, this tcpdump is useless for me since its not provide any information
> about data in packets. Please capture data as I suggested and attach it here.

Can I email it to you directly or can it be locked down in bugzilla so that it is not publicly accessable? I was hopeing to avoid leaking info into the public domain.
(In reply to comment #24)
> (In reply to comment #23)
> > Phillip, this tcpdump is useless for me since its not provide any information
> > about data in packets. Please capture data as I suggested and attach it here.
> 
> Can I email it to you directly or can it be locked down in bugzilla so that it
> is not publicly accessable? I was hopeing to avoid leaking info into the public
> domain.

Email him directly.
(Reporter)

Comment 26

9 years ago
(In reply to comment #25)
> 
> Email him directly.

Done.
(Reporter)

Comment 27

9 years ago
For what its worth, I followed the same procedure to get the cap as I did the last time. The first traffic recorded was when I initially opened TB. It downloaded the mail that was already sitting on the server. Then, I immediately sent another email and waited for over an hour. The mail was not retrieved until I pressed get mail just before the end of the capture.

Comment 28

9 years ago
Phillip, thanks for tcpdump. This looks good for me but just to be sure could you make another one, but start it before you startup TB. Also make sure you do this just after startup. I want see if there no problem with pop/principal while initial getting TGT.
Only problem with Kerberos code currently in TB it doesn't report any problems at all, so you have to check these manually mostly.

Comment 29

9 years ago
I drill down logs from IMAP to understand it more, so from what I see this is correct behavior.

3608[4641380]: 3eb6400:pluto.foxtelecom.ru:NA:CreateNewLineFromSocket: * OK [CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS LOGINDISABLED AUTH=CRAM-MD5 AUTH=GSSAPI] Dovecot ready.

3608[4641380]: entering nsAuthGSSAPI::nsAuthGSSAPI()
3608[4641380]: Attempting to load gss functions
3608[4641380]: entering nsAuthGSSAPI::Init()
3608[4641380]: entering nsAuthGSSAPI::GetNextToken()
3608[4641380]:   leaving nsAuthGSSAPI::GetNextToken [rv=0]
3608[4641380]: 3eb6400:pluto.foxtelecom.ru:NA:SendData: 1 authenticate GSSAPI

As you can see before you could enter negotiate anything you should establish connection to pop/imap server. After that we will try to get Token, from logs I see we can't get token. After we get token it log "leaving nsAuthGSSAPI...".
So that strage for me to see GetNextToken() alone w/o even connection estabilished.
(Reporter)

Comment 30

9 years ago
In (In reply to comment #28)
> This looks good for me but just to be sure could
> you make another one, but start it before you startup TB. Also make sure you do
> this just after startup.
> 
I will do that. I can verify that the kerberos side of things is working. I can see the pop/server.domain principles in my ticket on the client. The ticket is not expired (it works when I click get mail). The cap that I sent you was running before TB was started - it got all the (server side) traffic from the moment TB started til when TB was closed. I will reboot the test box and mail you another .cap after doing that.

In (In reply to comment #29)
> I drill down logs from IMAP to understand it more, so from what I see this is
> correct behavior.
> 
What value were you using for the NSPR_LOG_MODULES environment variable? 

> As you can see before you could enter negotiate anything you should establish
> connection to pop/imap server. After that we will try to get Token, from logs I
> see we can't get token. After we get token it log "leaving nsAuthGSSAPI...".
> So that strage for me to see GetNextToken() alone w/o even connection
> estabilished.

In the first tcpdump that I posted (Comment #22), I noticed that there was no POP3 network traffic between client and server except when TB started up initially and when I clicked get mail. When it was supposed to be checking for new mail every 10 minutes, it did not seem to be doing so. In the tcpdump I emailed to you, there was only POP traffic at the beginning (when TB started) and right at the end (when I clicked get mail). There was nothing other than kerberos stuff in the ~1.5 hours in between.

Comment 31

9 years ago
These caps looks good.
set NSPR_LOG_MODULES=imap:5,negotiateauth:5,timestamp
Could you get log with timestamps as well? 
Marking NEW as we clearly can't get ticket by some unknown reason during email auto checking.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 32

9 years ago
(In reply to comment #31)
> These caps looks good.
> set NSPR_LOG_MODULES=imap:5,negotiateauth:5,timestamp
> Could you get log with timestamps as well? 

Done. I emailed you the corresponding tcpdumps. Here is the TB log with timestamps included. I just noticed that the date in the logs seems to be a month out.. It is definantly set correctly on the machine. Incorrect dates are usually a good culprit for kerberos issues.

2009-08-17 03:46:39.334000 UTC - 0[1727140]:   nsAuthSSPI::Init
2009-08-17 03:46:39.334000 UTC - 0[1727140]:   InitSSPI
2009-08-17 03:46:39.334000 UTC - 0[1727140]: Using SPN of [pop/server]
2009-08-17 03:46:39.352000 UTC - 0[1727140]: entering nsAuthSSPI::GetNextToken()
2009-08-17 03:46:39.460000 UTC - 0[1727140]: entering nsAuthSSPI::GetNextToken()
2009-08-17 03:47:47.424000 UTC - 0[1727140]:   nsAuthSSPI::Init
2009-08-17 03:47:47.424000 UTC - 0[1727140]: Using SPN of [pop/server]
2009-08-17 03:47:47.424000 UTC - 0[1727140]: entering nsAuthSSPI::GetNextToken()
2009-08-17 03:47:47.442000 UTC - 0[1727140]: entering nsAuthSSPI::GetNextToken()
2009-08-17 04:21:23.128000 UTC - 0[1727140]:   nsAuthSSPI::Init
2009-08-17 04:21:23.144000 UTC - 0[1727140]: Using SPN of [pop/server]
2009-08-17 04:21:23.144000 UTC - 0[1727140]: entering nsAuthSSPI::GetNextToken()
2009-08-17 04:21:23.144000 UTC - 0[1727140]: entering nsAuthSSPI::GetNextToken()

Comment 33

9 years ago
I think this has something to do with automatically check for new messages every # minutes. I can't find such bug, but remember there something like that been before. Even when people using non Kerberized POP3 but regular passwords.
(Reporter)

Comment 34

9 years ago
Is there anything more that I can do to help?

Updated

9 years ago
Depends on: 278227
(In reply to comment #35)

Is Bug 24594 relevant to your problem? AFAIK, Bug 24594 still remains on newest Tb 3 build.
(Reporter)

Comment 37

9 years ago
(In reply to comment #36)

It does not seem like the entire 'Check for new mail every XX minutes' thing is broken - it only stops working when Secure Auth is enabled (I just tested it to make sure). Whether that is because of brokenness in the 'XX minutes' or something to do with the Krb/GSSAPI authentication or both, I wouldnt know. I dont know how I can eliminate one or the other. Any suggestions?

If I do not enable 'Secure Authentication', TB correctly asks me for a password when it starts and then checks for (and downloads) messages every XX minutes. As soon as I enable 'Secure Authentication', it stops doing this - the mail is only downloaded on startup or when I click 'Get Mail'. 

My impression of Bug 24594 was that it was only triggered when the 'XX minutes' setting was changed and TB then needed a restart to recover and apply the new settings. Is that correct? I have not been changing that setting in my test environment. It is still set to the default of 10 minutes.
(Reporter)

Comment 38

9 years ago
(In reply to comment #37)
> If I do not enable 'Secure Authentication', TB correctly asks me for a password
> when it starts and then checks for (and downloads) messages every XX minutes.
> As soon as I enable 'Secure Authentication', it stops doing this - the mail is
> only downloaded on startup or when I click 'Get Mail'. 

By "enable 'Secure Authentication'", I mean: I tick the 'Secure Authentication' check box, then close thunderbird. Then I send myself some mail and start TB up again. Once mail has been retrieved, I send myself some more mail and then wait.
(In reply to comment #0)
> This was the only logging I got out of thunderbird using
> NSPR_LOG_MODULES="negotiateauth:5,imap:5,gssapi:5,pop:5"

Is this bug still for POP3? Do you still use above option setting?
If both are yes, could you please get NSPR log for POP3 also.
> https://wiki.mozilla.org/MailNews:Logging
> NSPR_LOG_MODULES="negotiateauth:5,gssapi:5,POP3:5"
See next document for state code of POP3 log.
> http://kb.mozillazine.org/Session_logging_for_mail/news

If "silent connection kill by server after QUIT" occurs if GSSAPI is used, Tb possibly waits for response forever. See Bug 428611 and Bug 429069 for such "wait forever after silent kill of connection".
To see such problem occurs or not, socket logging will probably be required.
> http://www.mozilla.org/projects/netlib/http/http-debugging.html
> NSPR_LOG_MODULES=nsSocketTransport:5,nsHostResolver:5,negotiateauth:5,gssapi:5,POP3:5

By the way, if NSPR log for POP3 is obtained, there is no need of new mail at server. Log for auth, list, uidl etc, is sufficient.
(Reporter)

Comment 40

9 years ago
Created attachment 403700 [details]
TB Logs of Pop3

A log using NSPR_LOG_MODULES="negotiateauth:5,imap:5,gssapi:5,pop3:5,timestamp"
Attachment #396171 - Attachment is obsolete: true
Attachment #396172 - Attachment is obsolete: true
Attachment #396173 - Attachment is obsolete: true
Attachment #396174 - Attachment is obsolete: true
(Reporter)

Comment 41

9 years ago
Created attachment 403704 [details]
TB Logs of Pop3 with socket logging

NSPR_LOG_MODULES=negotiateauth:5,imap:5,gssapi:5,pop3:5,nsSocketTransport:5,nsHostResolver:5,timestamp
(In reply to comment #40)
> TB Logs of Pop3

(1) First successful login / logout
> 2009-08-30 04:23:34.240000 UTC - 0[172b140]: SEND: AUTH GSSAPI
> 2009-08-30 04:23:35.239000 UTC - 0[172b140]: RECV: +OK Logged in.
> 2009-08-30 04:23:35.330000 UTC - 0[172b140]: SEND: QUIT
> 2009-08-30 04:23:35.348000 UTC - 0[172b140]: RECV: +OK Logging out, messages deleted.
(2) Second successful login / logout
> 2009-08-30 04:46:38.143000 UTC - 0[172b140]: SEND: AUTH GSSAPI
> 2009-08-30 04:46:38.284000 UTC - 0[172b140]: RECV: +OK Logged in.
> 2009-08-30 04:46:38.425000 UTC - 0[172b140]: SEND: QUIT
> 2009-08-30 04:46:38.425000 UTC - 0[172b140]: RECV: +OK Logging out, messages deleted.

First login is by check new messages at startup?
Second login after 23 minutes is by manual Get Msgs? Or by check new messages every NN minutes?

Comment 43

9 years ago
(In reply to comment #42)
> First login is by check new messages at startup?
> Second login after 23 minutes is by manual Get Msgs? Or by check new messages
> every NN minutes?

Second is seems manual cause original report state he have 5 minutes and comment#3 is 10 minutes.
(Reporter)

Comment 44

9 years ago
(In reply to comment #43)
> (In reply to comment #42)
> > First login is by check new messages at startup?
> > Second login after 23 minutes is by manual Get Msgs? Or by check new messages
> > every NN minutes?
> 
> Second is seems manual cause original report state he have 5 minutes and
> comment#3 is 10 minutes.

Correct. The second was me manually pressing the 'Get Mail' button. Sorry, I should have annotated it a little more - I got side tracked.
(Start of first POP3 connection)
> 2009-08-30 04:23:33.913000 UTC - 0[172b140]: Entering NET_ProcessPop3 20
> 2009-08-30 04:23:33.913000 UTC - 0[172b140]: POP3: Entering state: 1
(End of first POP3 connection)
> 2009-08-30 04:23:35.348000 UTC - 0[172b140]: RECV: +OK Logging out, messages deleted.
> 2009-08-30 04:23:35.367000 UTC - 0[172b140]: POP3: Entering state: 25
It looks 1.5 minutes is required to connect and download a small mail.

Socket log required to check whether "connection kill by server" exists or not(socket level error is reported or not), is socket log after QUIT of first POP3 access at startup. And, huge socket log is produced because of logs for polling.
Please check log with "Check new messages every 2 minutes" first.
If too many noises exist in log, please get log with next to reduce log size and to exclude unwanted log, if possible.
 1. New profile, account definition of the POP3/GSSAPI only.
    Disable all unwanted network access such as update check.
    Disable all unwanted activity such as Gloda, auto-sync, ....
    Fetch header only, leave messages on server, and never delete from server.
    Checked : Automatically download message (to avoid unwanted bug)
    Checked : Check new messages at start up
    Checked : Check new messages every 2 minutes
 2. Start Tb, and force download of all mail header of all mails, and terminate.
 3. Start Tb with NSPR logging on, and wait for 2*(2 or 3) minutes.
 4. At command prompt, NETSTAT -n -o -b
    If session is killed by server, "CLOSE-WAIT" or something may be displayed.
 5. Terminate Tb.
(Reporter)

Comment 46

9 years ago
(In reply to comment #45)
> (Start of first POP3 connection)
> > 2009-08-30 04:23:33.913000 UTC - 0[172b140]: Entering NET_ProcessPop3 20
> > 2009-08-30 04:23:33.913000 UTC - 0[172b140]: POP3: Entering state: 1
> (End of first POP3 connection)
> > 2009-08-30 04:23:35.348000 UTC - 0[172b140]: RECV: +OK Logging out, messages deleted.
> > 2009-08-30 04:23:35.367000 UTC - 0[172b140]: POP3: Entering state: 25
> It looks 1.5 minutes is required to connect and download a small mail.

Huh? It retrieved the first mail immediately. The difference between 04:23:33 and 04:23:35 is only two seconds - actually 1.5 seconds would be closer to the mark.

I can get a new log later on today anyway.
My time calculator seems broken... Get log with "every 1 minutes"(minimum), please.
(Reporter)

Comment 48

9 years ago
Created attachment 403962 [details]
Logs collected as described in Comment #46 and #47

(In reply to Comment #46)
I collected some more logs as you described. There were no relevant CLOSE-WAIT connections. The only ones I saw were to my http proxy server.

C:\Documents and Settings\pmacey>netstat -n -o -b

Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP    10.2.5.12:445          10.8.6.73:3992         ESTABLISHED     4
  [System]

  TCP    127.0.0.1:2355         127.0.0.1:2356         ESTABLISHED     2168
  [thunderbird.exe]

  TCP    127.0.0.1:2356         127.0.0.1:2355         ESTABLISHED     2168
  [thunderbird.exe]

  TCP    127.0.0.1:2357         127.0.0.1:2358         ESTABLISHED     2168
  [thunderbird.exe]

  TCP    127.0.0.1:2358         127.0.0.1:2357         ESTABLISHED     2168
  [thunderbird.exe]

  TCP    10.2.5.12:1194         10.10.0.66:8080        CLOSE_WAIT      3880
  [jucheck.exe]


C:\Documents and Settings\pmacey>
(In reply to comment #48)
(Loopback connection-1 : Tb's port:2355 <-> Tb's port:2356
> TCP 127.0.0.1:2355 127.0.0.1:2356 ESTABLISHED 2168 [thunderbird.exe]
> TCP 127.0.0.1:2356 127.0.0.1:2355 ESTABLISHED 2168 [thunderbird.exe]
(Loopback connection-2 : Tb's port:2357 <-> Tb's port:2358
> TCP 127.0.0.1:2357 127.0.0.1:2358 ESTABLISHED 2168 [thunderbird.exe]
> TCP 127.0.0.1:2358 127.0.0.1:2357 ESTABLISHED 2168 [thunderbird.exe]

These are loopback connections which is required for Tb.
TCP session with POP3 server looks to be cleanly closed.

> Logs collected as described in Comment #46 and #47

After receiving response to QUIT, next logs are seen.
> 2009-09-01 05:02:23.616000 UTC - 0[1729140]: RECV: +OK Logging out.
> 2009-09-01 05:02:23.616000 UTC - 0[1729140]: POP3: Entering state: 40 (not written in Session_logging_for_mail/news. GSSAPI related? )
> 2009-09-01 05:02:23.616000 UTC - 0[1729140]: POP3: Entering state: 23 (23	AUTH_CRAM_MD5_CHALLENGE_RESPONSE
> 2009-09-01 05:02:23.647000 UTC - 0[1729140]: POP3: Entering state: 25 (25	SEND_AUTH_GSSAPI_STEP
> 2009-09-01 05:02:23.647000 UTC - 0[1729140]: STS dispatch [4021888]
> 2009-09-01 05:02:23.647000 UTC - 0[1729140]: nsSocketInputStream::CloseWithStatus [this=439c7d8 reason=804b0002]
> 2009-09-01 05:02:23.647000 UTC - 0[1729140]: nsSocketOutputStream::CloseWithStatus [this=439c7f8 reason=804b0002]
> 2009-09-01 05:02:23.647000 UTC - 0[1729140]: nsSocketTransport::PostEvent [this=439c740 type=6 status=804b0002 param=0]
> 2009-09-01 05:02:23.647000 UTC - 0[1729140]: STS dispatch [401dae0]

For Tb, it's similar to connection error which will prohibit retry or next mail check, or similar to entering offline?
For Tb, it's GSSAPI failure and Tb tries to fall back to next CRAM_MD5?
TCP session close is initiated by Tb normally? Or by something wrong?

Can you compare the flow with one by "Use Secure Authentication"=Off?
Woops. That was SMTP states. When POP3, states is as follows.
> 2009-09-01 05:02:23.616000 UTC - 0[1729140]: RECV: +OK Logging out.
> 2009-09-01 05:02:23.616000 UTC - 0[1729140]: POP3: Entering state: 40 (40	XSENDER_RESPONSE
> 2009-09-01 05:02:23.616000 UTC - 0[1729140]: POP3: Entering state: 23 (23	DONE 
> 2009-09-01 05:02:23.647000 UTC - 0[1729140]: POP3: Entering state: 25 (25	FREE

reason=804b0002 of CloseWithStatus is normal close by Tb? Or notification of socket close by other?
(Reporter)

Comment 51

9 years ago
Created attachment 404201 [details]
Logs of a Plain Auth transaction

(In reply to Comment #49)
Here are logs with Secure Authentication turned off. I typed in the password and left TB alone for about 6 minutes
(In reply to comment #51)
> Logs of a Plain Auth transaction

Log just after QUIT. Same as GSSAPI case. It looks normal/clean TCP session close.
> 2009-09-02 07:00:54.497000 UTC - 0[1729140]: RECV: +OK Logging out.
> 2009-09-02 07:00:54.497000 UTC - 0[1729140]: POP3: Entering state: 40 (40	XSENDER_RESPONSE
> 2009-09-02 07:00:54.497000 UTC - 0[1729140]: POP3: Entering state: 23 (23	DONE 
> 2009-09-02 07:00:54.513000 UTC - 0[1729140]: POP3: Entering state: 25 (25	FREE
> 2009-09-02 07:00:54.513000 UTC - 0[1729140]: STS dispatch [3f31a88]
> 2009-09-02 07:00:54.513000 UTC - 0[1729140]: nsSocketInputStream::CloseWithStatus [this=377b8b8 reason=804b0002]
> 2009-09-02 07:00:54.513000 UTC - 0[1729140]: nsSocketOutputStream::CloseWithStatus [this=377b8d8 reason=804b0002]
> 2009-09-02 07:00:54.513000 UTC - 0[1729140]: nsSocketTransport::PostEvent [this=377b820 type=6 status=804b0002 param=0]
> 2009-09-02 07:00:54.513000 UTC - 0[1729140]: STS dispatch [3f30300]

After that, next log appears after 1 minute. It looks start of next connection kicked by timer.
> 2009-09-02 07:01:46.749000 UTC - 0[1729140]: creating nsSocketTransport @17342e0

After QUIT and close of TCP connection, timer request is not issued if GSSAPI is used? What kind of log should we get to check it?

With all:5, next log was seen. (my POP3. user/pass is used.)
It looks timer related log.
> (QUIT and nor mal session close)
> (After almost 1 minute)
> 00001036	53.00702286	[316] 0[182c140]: performing biffs	
> 00001037	53.00709534	[316] 0[182c140]: setting 3 timer	
> All logs here = set of ( performing biffs / setting 3 timer )
> 00001078	53.01681519	[316] 0[182c140]: performing biffs	
> 00001079	53.01689529	[316] 0[182c140]: setting 3 timer	
> 00001080	53.02657700	[316] 0[182c140]: performing biffs	
> 00001081	53.02706528	[316] 0[182c140]: creating nsSocketTransport @1837da0
(Reporter)

Comment 53

9 years ago
(In reply to comment #52)
Do you need any more info from me? Sorry I cant help much more.. I know nothing about TB internals.

> With all:5, next log was seen. (my POP3. user/pass is used.)
> It looks timer related log.
Does that mean this is a bug with the 'Check every XX minutes' code?
(In reply to comment #53)
> > With all:5, next log was seen. (my POP3. user/pass is used.)
> > It looks timer related log.
> Does that mean this is a bug with the 'Check every XX minutes' code?

With all:5, some other logs(not so many log types than I expected) were seen after QUIT and clean TCP session close, and the logs in comment #52 was seen just before start of next connection. I don't know such logs is useful for problem anlyais or not.
AFAIR, Tb doesn't schedule next connection when some kinds of error happens(similar to entering in offline mode), in order to avoid infinite retry loop or flood of error messages. I'm suspecting;
  If GSSAPI is used, internal/wrong error condition happens after QUIT and
  connection close, then next 'Check every XX minutes' is not scheduled.

Comment 55

9 years ago
(In reply to comment #54)

>   If GSSAPI is used, internal/wrong error condition happens after QUIT and
>   connection close, then next 'Check every XX minutes' is not scheduled.

No, that's not accurate, afaik. The scheduling has no idea the previous check failed. It may be the case that we're left in some sort of state where the next check fails, but that wouldn't explain why manually clicking get new mail works. Plus, we don't cache pop3 connections, so we should be starting anew each time.
(Reporter)

Comment 56

9 years ago
Is there anything else I can do to help resolve this bug?

Comment 57

9 years ago
Now that I think about it, we don't do the background check for new mail if the user has not authenticated against the server, because we assume we need a password. But kerberos doesn't require a password...so I'm not quite sure of the way out - we might be able to check if the server has kerberos capabilities, or, in general, requires a password.
(In reply to comment #57)

Similar issue to Bug 533083?

Comment 59

9 years ago
I think in this case we don't even try to connect to the pop3 server, whereas in that case, we do, if I understand correctly. But I could be wrong...

Comment 60

9 years ago
(In reply to comment #59)
> I think in this case we don't even try to connect to the pop3 server, whereas
> in that case, we do, if I understand correctly. But I could be wrong...

As far I can tell there no POP3 activity at all, so your guess is right.

Comment 61

9 years ago
This is closer to bug 529364 than 533083, I think.  It's probably due to the "preflight check" mentioned in comment #13 in 533083.  The functions "GetPasswordPromptRequired" and "GetServerRequiresPasswordForBiff" would influence whether the biff would occur..

Comment 62

9 years ago
Created attachment 417950 [details]
Logs with NSPR_LOG_MODULES=MsgBiff:5,timestamp

Biff logs with 'Use Secure Authentication' checked (with GSSAPI/Kerberos)

Comment 63

9 years ago
Created attachment 417952 [details]
Logs with NSPR_LOG_MODULES=MsgBiff:5,timestamp (no secure authentiction, no Kerberos/GSSAPI)

Biff logs when 'Use Secure Authentication' was NOT checked.  No Kerberos/GSSAPI.  I entered my password.

Comment 64

9 years ago
Sorry for the repeat entries, I don't use bugzilla that much.

I am experiencing the same issue as listed here.

I am willing to test builds, but lack the time to setup a build environment and do not have my employers clearance yet to submit code.

I have submitted two log files that show the logs for MsgBiffLogModule on Thunderbird 3.0.  When I use secure authentication it will not check for new messages failing with the error 'not biffing server serverBusy = 0 requirespassword = 1 password prompt required = 1 targetFolderIndex = -1'.

When I do NOT use secure authentication and put in a password it works fine, 'biffing server server2 rv = 0'.

On a quick glance it would look like a modification to GetServerRequiresPasswordForBiff to take GSSAPI into account would fix the issue.

It may take a little more work though.  If the user has not obtained a kerberos tgt (using kinit, kfw, kerberos.app, ...) thunderbird prompts for a kerberos principle to use.  The user may then cancel.  If this behavior was not taken into account then the user could cancel the kerberos principal selection, wait a few minutes and then have the Biff request another kerberos principle.

The check would need to look something like this maybe?

If use secure authentication and we have a kerberos credential available then no password is needed and launch biff

Comment 65

9 years ago
Jonathan, have look into bug 339050 bug 524698, these are about problems when no Ticket exist yet.

Comment 66

9 years ago
Nikolay, thank you, those where interesting reads.  I've had a quick glance at nsPop3Protocol.cpp, nsMsgProtocol.cpp, and some of the nsAuth* (SASL, GSSAPI) files.

I would love to see this bug 511832 solved (though it is a slightly larger problem when you include 524698).

From browsing the code it looks like secure authentication breaks down into these options (in order of preference by TB see nsPop3Protocol::ProcessAuth):

Kerberos (via GSSAPI or potentially SSPI if you are on windows)
CRAM-MD5
NTLM
APOP

This bug will only affect you if you use Kerberos (or NTLM?).  As CRAM-MD5 and APOP require the user to enter a password and it will get past the Biff checks.

This is more of a question, I've not done GSSAPI programming.  Is there a way to use the standard GSSAPI calls to test authentication and not potentially prompt the user for a credential?

Comment 67

9 years ago
An NTLM authentication can be called through SSPI call, this bug about password-less login. Have look into comment #57 of this bug.

Comment 68

9 years ago
Wow, somebody actually uses POP with Kerberos? I thought we supported that just for kicks / consistency.

Thanks for the pointers Nicolay and Michael. Yes, I am doing a lot of work on bug 525238, which changes matters a lot (to the better, I hope). I haven't checked whether this fixes "[x] Automatically download", though, it may fix it by accident.

> This bug will only affect you if you use Kerberos (or NTLM?).
> As CRAM-MD5 and APOP require the user to enter a password and it will
> get past the Biff checks.

That terribly reminds me of bug 533083.

But please defer this bug until these other bugs are fixed.

Comment 69

9 years ago
(In reply to comment #68)
> That terribly reminds me of bug 533083.

Bug 533083 is more about unexpected server connections (when no password exists), while Bug 529364 is about not doing the startup check if "Automatically download new messages" is not set (and no password is saved).  I think this bug is more closely related to 529364.

> But please defer this bug until these other bugs are fixed.

I'm hoping Bug 525238 is included in "these other bugs".  In my brief glance at the patch, I see you added some (a lot of!) code in the same area (nsPop3Protocol::Initialize) as I did when attempting to fix Bug 533083.

Comment 70

9 years ago
> this bug is more closely related to bug 529364.

Yes, right.

> I'm hoping Bug 525238 is included in "these other bugs".

Yes, definitely.

Updated

2 years ago
Duplicate of this bug: 747875

Comment 72

2 years ago
(In reply to Ben Bucksch (:BenB) from comment #70)
> > this bug is more closely related to bug 529364.
> 
> Yes, right.
> 
> > I'm hoping Bug 525238 is included in "these other bugs".
> 
> Yes, definitely.

Phillip the reporter writes "no longer on a kerberised pop3 server".
But the above bugs have subequently been fixed ~early 2011. And blocking bug 278227 was just closed WFM.
So this is probably WFM
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.