249274 - Unread truncated messages are not popped when deleted and trash is emptied.

Status: RESOLVED EXPIRED

(Thunderbird :: General, defect)

Description

[Gary Aitken]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Build Identifier: Mozilla Thunderbird version 0.7 (20040616)

When a message is not completely popped due to its length,
and that message is deleted without clicking in the truncated message box
to download the full message,
the message is left on the mail server and never deleted.
The result is the mailbox grows over time.

Reproducible: Always
Steps to Reproduce:
1. Clear our your mailbox on the mail server by popping everything
2. Send yourself a message longer than your download limit (attachments are your
friend)
3. Click "Get Mail" to make the message show up in Thunderbird's summary window
4. Click on the message in the summary pane; you will see the "Truncated!"
message in the detail pane
5. Delete the message without clicking in the truncated pane to download the
full message.
6. Empty the trash folder.
7. Go peek at your mailbox on the mail server; the message will still be
there... forever, unless you manually delete it.

Actual Results:  
The message disappeared from the summary pane,
The trash was empty,
but unfortunately, the message was still on the mail server.

Expected Results:  
Popped the message and thrown it away,
unless there is a way to tell the popper to discard a specific message.

The message can't really be deleted from the server until the trash folder is
emptied, since an "undelete" of the deletion operation should get back the
truncated message, and one should then still be allowed to download the full
message.

Hope this isn't a duplicate.  Searches for "pop", "popped" and "truncated" don't
show anything covering this.

Comment 1

[Mike Cowperthwaite]

Messages which are known to still reside on the server for whatever reason 
(partial download due to size, header-only download, or "Leave messages on 
server") and which then are marked to be deleted from the server do not actually 
get deleted until the next mail fetch.

I attempted to duplicate your procedure, and if I wait until the next mail fetch 
before checking the POP3 acc't via telnet, the message is gone.  In fact...

> The message can't really be deleted from the server until the trash folder is
> emptied, since an "undelete" of the deletion operation should get back the
> truncated message, and one should then still be allowed to download the full
> message.

Good point, but it's not handled like that -- the message is flushed once 
deleted after the next fetch, even tho it still resides in the Trash folder.

Bugs of this nature should be filed under   Core / Networking:POP.  Try a search 
there on "delet serv" to see the current open bugs about this.  See in 
particular bug 154630, which this may be a dupe of, depending.

Comment 2

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.