90767 - IMAP: Inbox not expunged when using SSL

Status: VERIFIED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Brian Ryner (not reading)]

Seen on both branch and trunk builds:

Using an IMAP/SSL connection (with a certificate), the Inbox is never expunged
on exit, even if I have it set to do so.  It doesn't seem to make a difference
whether I have it set to remove messages immediately or simply mark them as
deleted... the result is that the deleted messages remain on the server after
exiting Mozilla.

With a non-SSL connection, the inbox is properly expunged on exit.  If I use
"Remove message immediately" and have it set to NOT expunge on exit, the deleted
messages are kept, but that may be the desired behavior or a separate bug.

Comment 1

[Brian Ryner (not reading)]

Oh, mail server used is judge.mcom.com.

Comment 2

[David :Bienvenu]

I don't really know how the SSL code works, or why it would be different from
the non-SSL case. The remove immediately behaviour you describe is the desired
behaviour. Scott, do you have any clue about why SSL would behave differently?
Is it because of the goofy way we do cleanup on shutdown by pumping events? If
so, this bug can't be fixed until there's an xp apps architecture for doing
asynchronous things on shutdown.

Comment 3

[David :Bienvenu]

One possibility that occurs to me is that psm might have been shut down by the
time we get told by the app to shutdown, in which case, obviously, we're not
going to be able to talk to the imap server via ssl. 

Comment 4

[David :Bienvenu]

Never mind my silly theories. I tried this with a debug trunk build and a
release branch build and it worked fine for me. Brian, could you generate a
protocol log by following these instructions? Thanks.
http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

Comment 5

[David :Bienvenu]

Never mind; I didn't have my certificate installed on my new machine. I'm seeing
the problem now.

Comment 6

[David :Bienvenu]

OK, I see the problem now. nsMsgAccountManager::cleanupOnExit will not do
anything if nsIImapIncomingServer::GetPassword returns the empty string, because
we think the user has not authenticated with the server in this session, so we
don't want to prompt the user for their password at shutdown time. But if you're
using SSL with a certificate, we don't have a password. So, we need to have
another way of detecting if the user has authenticated against the server. If
anyone knows the correct way to do this, please chime in, and meanwhile, I'll go
poke around a bit.

Comment 7

[David :Bienvenu]

I noticed that biff's not working when I have SSL turned on, and that's probably
a similar problem. See bug 58964, which I'll take as well, I guess.

Comment 8

[David :Bienvenu]

Attachment: proposed fix (also contains part of fix for cleanup inbox on exit not happening with ssl)

Comment 9

[Scott MacGregor]

looks good david. r/sr=mscott

Comment 10

[Navin Gupta]

Is this the complete patch ? I don't see anywhere userAuthenticated being set 
and then where we do use the getter. Sorry for my ignorance. 

Comment 11

[David :Bienvenu]

we were already calling SetUserAuthenticated in the imap protocol code; it just
didn't do anything. We're not using the getter currently, but I think we might
want to have it around.

Comment 12

[Navin Gupta]

One more question; if we got empty password previously what will we get 
now ? how do we end up issuing compact here ? 

this is in cleanupOnExit just before we compact inbox. 
>if (isImap)
>          server->GetPassword(getter_Copies(passwd));
>         if (!isImap || (isImap && passwd && 
>                       nsCRT::strlen((const char*) passwd)))
>         {

Comment 13

[David :Bienvenu]

Attachment: acct mgr part of proposed fix

Comment 14

[David :Bienvenu]

good point, I forgot to add this part of the diff. We use
serverRequiresPasswordForAuthentication which ends up being set to FALSE if
we've ever connected to the server with a cert (or with a real password).

Comment 15

[Navin Gupta]

r=naving

Comment 16

[David :Bienvenu]

fix checked in.

Comment 17

[Antonio Lam]

Tried with 2001072506_0.9.2 build, and the deleted message still not "expunged" 
after exiting mozilla.

Step to reproduce:

1. In the mail account setting, select "Mark it as deleted" for "When I delete a 
message" option, and turn on "Clean up [expunge] Inbox on Exit" check box.
2. With SSL/IMAP turn on, login to the server with a client certificate.
3. Delete a single message from the INBOX. Note that the message is marked as 
"deleted"
4. Exit mozilla
5. Launch mozilla mail again, login to the server, I can see the "deleted" 
message still show up in the thread pane.

Note that with non-secure connection or SSL/IMAP without client certificate, the 
deleted message is expunged after exiting the mozilla. And when I launch mozilla 
mail again, the deleted message is no longer showing in the thread pane.

I tested this on a PC with Windows NT 4.0.

Re-opening the bug.

Comment 18

[David :Bienvenu]

it's not fixed in .9.2, only on the trunk. resolving again.

Comment 19

[Antonio Lam]

Is there any special reason why it is fixed only on the trunk, but not in .9.2?

Comment 20

[(not reading, please use [e-mail] instead)]

there are plenty of bugs that landed on the trunk, but were considered too risk
for the 0.9.2 branch.

Comment 21

[David :Bienvenu]

yeah, it wasn't approved for checking into the branch. Out of my control, I'm
afraid.

Comment 22

[Karen Huang]

Verified on Linux 08-06-08-trunk build.
Expunge on Exit for IMAP/SSL is working now.