IMAP: Inbox not expunged when using SSL

VERIFIED FIXED

Status

MailNews Core
Networking: IMAP
--
major
VERIFIED FIXED
17 years ago
9 years ago

People

(Reporter: Brian Ryner (not reading), Assigned: Bienvenu)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
Oh, mail server used is judge.mcom.com.
(Assignee)

Comment 2

17 years ago
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.
(Assignee)

Comment 3

17 years ago
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. 
(Assignee)

Comment 4

17 years ago
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
Status: NEW → ASSIGNED
(Assignee)

Comment 5

17 years ago
Never mind; I didn't have my certificate installed on my new machine. I'm seeing
the problem now.
(Assignee)

Comment 6

17 years ago
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.
(Assignee)

Comment 7

17 years ago
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.
(Assignee)

Comment 8

17 years ago
Created attachment 42655 [details] [diff] [review]
proposed fix (also contains part of fix for cleanup inbox on exit not happening with ssl)

Comment 9

17 years ago
looks good david. r/sr=mscott

Comment 10

17 years ago
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. 
(Assignee)

Comment 11

17 years ago
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

17 years ago
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)))
>         {
(Assignee)

Comment 13

17 years ago
Created attachment 42658 [details] [diff] [review]
acct mgr part of proposed fix
(Assignee)

Comment 14

17 years ago
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

17 years ago
r=naving
(Assignee)

Comment 16

17 years ago
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 17

17 years ago
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 18

17 years ago
it's not fixed in .9.2, only on the trunk. resolving again.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 19

17 years ago
Is there any special reason why it is fixed only on the trunk, but not in .9.2?
there are plenty of bugs that landed on the trunk, but were considered too risk
for the 0.9.2 branch.
(Assignee)

Comment 21

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

Comment 22

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

Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.