Closed Bug 944948 Opened 8 years ago Closed 7 years ago

Messages, deleted in IMAP trash folder, are not removed from server

Categories

(Thunderbird :: Untriaged, defect)

24 Branch
x86_64
Linux
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 624841

People

(Reporter: Ulf.Zibis, Unassigned)

References

(Depends on 1 open bug)

Details

Attachments

(6 files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131115110311

Steps to reproduce:

- POP3 account to pop.gmx.net (freemail) since long time
- add IMAP account to imap.gmx.net with same user email, no offline store
- subscribe IMAP folder "Gelöscht"
- choose IMAP folder "Gelöscht" for trash
- delete some messages in Inbox, which are in fact moved to IMAP folder "Gelöscht"
- mark some messages in folder "Gelöscht" and delete them


Actual results:

The deleted messages disappear from the ThunderBird application trash folder, the messages are removed from the displayed list, however, the messages are still available on the server, verified by web-mailer.


Expected results:

The deleted messages should disappear from servers folder "Gelöscht" to prevent server space from quota exceeded.
Severity: normal → major
> Actual results:
> The deleted messages disappear from the ThunderBird application trash folder,
> the messages are removed from the displayed list, however, the messages are still
> available on the server, verified by web-mailer.
> Expected results:
> The deleted messages should disappear from servers folder "Gelöscht" to prevent server space from quota exceeded.

Do you correctly understand difference between "delete of a mail" and "EXPUNGE" in protocol named IMAP?
Do you understand differece between "uid xxx store +/-Flag (\Deleted )" and "expunge" in protocol named IMAP?
Have you read RFC 3501 before open *BUG* which is relivant to protocol named IMAP at bugzilla.mozilla.org?
> http://tools.ietf.org/html/rfc3501
Do you correctly undestand difference between "RETR/DLET of POP3" and "store +/-Flag (\Deleted), EXPUNGE in IMAP"?

Do you correctly understand followings before you open *BUG* which is relivant to protocol named IMAP at bugzilla.mozilla.org?
- differences among three "IMAP delete models in Tb"(mail.imap.expunge_option)
  (Account Setting/Server Settings, When I delete a message:)
  (1) Just mark it as deleted 
  (2) Remove it immediately
  (3) Move it to this folder: [ folder which is used as trash in Tb ] (move to trash model)
- meaning of "View/Not Deleted" in "View/All,Unread,Not Deleted,Tags,Custm Views"
- meaning of "Message and Storage" in Server Settings
- meaning of following EXPUNGE related prefs setting(can be viewed via Config Editor)
  mail.imap.check_deleted_before_expunge (default=false)
  mail.imap.expunge_after_delete         (default=false)
  mail.imap.expunge_threshold_number     (default=20. used by Penelope==Eudora only?)

Do you correctly understand difference between "Mbox of POP3 in gmx.net" and "Mboxes in gmx.net IMAP"?
To see what occurs easily, use "Just mark it as deleted" always.
- "mail flagged as \Deleted" is shown with strike-thru line at thread pane.
     Undelete, Delete again can be freely executed.
     Even "copy of mail flagged as \Deleted" is possible in IMAP.
- "mail flagged as \Deleted" is hidden by View/Not Deleted", and is shown by View/All.
- "mail flagged as \Deleted" is permanently removed from Mbox at server by Compact of
  folder, because Tb issues EXPUNGE command by Compact operation.
- If "mail flagged as \Deleted" is marked as Unread, \Seen flag of the mail is removed,
  then "unread mail count at folder pane" is incremented, because "Unread mail count at
  folder pane" != "number of mails without \Deleted flag && without \Seen flag"
  in "Just mark it as deleted" model. It's simply "number of mails without \Seen flag".
- "Unread mail count at folder pane" == "number of mails without \Deleted flag && without
  \Seen flag" is true only when "Remove it immediately" model and "Move to trash" model
  where MsgDBHdr of "mail flagged as \Deleted" is removed from MsgDB.
  In this case, it's "number of mails without \Seen flag in MsgDB" instead of "number of
  mails without \Seen flag in Mbox at IMAP server".

If you want to see similar thread pane display to "Remove it immediately", use "Just mark it as deleted" with View/Not Deleted.

If you want to see similar thread pane display to "Move to trash(Gelöscht)", use "Just mark it as deleted" with View/Not Deleted, and do "move mail from FolderX to Gelöscht" instead of "delete mail in FolderX", or do "copy mail from FolderX to Gelöscht(uid copy step), delete the mail at FolderX(uid store flags \Deleted step), View/Not Deleted at FolderX(removal of MsgDBHdr of deleted mail step)"(this is natural emulation of move to trash model).
(In reply to WADA from comment #1)
> > Actual results:
> > The deleted messages disappear from the ThunderBird application trash folder,
> > the messages are removed from the displayed list, however, the messages are still
> > available on the server, verified by web-mailer.
> > Expected results:
> > The deleted messages should disappear from servers folder "Gelöscht" to prevent server space from quota exceeded.
> 
> Do you correctly understand difference between "delete of a mail" and
> "EXPUNGE" in protocol named IMAP?
Let me try:
delete: Just mark messages as deleted
EXPUNGE: Remove them immediately from server Mbox

> Do you understand differece between "uid xxx store +/-Flag (\Deleted )" and
> "expunge" in protocol named IMAP?
I guess this is same as I wrote for above.

> Have you read RFC 3501 before open *BUG* which is relivant to protocol named
> IMAP at bugzilla.mozilla.org?
No.

> Do you correctly undestand difference between "RETR/DLET of POP3" and "store
> +/-Flag (\Deleted), EXPUNGE in IMAP"?
No.

> Do you correctly understand followings before you open *BUG* which is
> relivant to protocol named IMAP at bugzilla.mozilla.org?
> - differences among three "IMAP delete models in
> Tb"(mail.imap.expunge_option)
>   (Account Setting/Server Settings, When I delete a message:)
>   (1) Just mark it as deleted 
>   (2) Remove it immediately
>   (3) Move it to this folder: [ folder which is used as trash in Tb ] (move
> to trash model)
Yes, I understand. In my case I set (3) to "Gelöscht".
It is unclear, what should/will happen, if a message in the Trash folder itself becomes "deleted".
a) In POP3 account it is deleted from the local Mbox.
b) At a different provider in IMAP server side Mbox it is deleted too.
c) In gmx.net IMAP Mbox it is not deleted, but is somehow invisible for TB client.

The last case is the reason for posting a bug, as I understood account setting (3) to have to work as experienced in b).
If it is meant as just flagging the message as (\Deleted), how should I change the setting to determine freeing of server space?

> - meaning of "View/Not Deleted" in "View/All,Unread,Not Deleted,Tags,Custm
> Views"
How to set this?

> - meaning of "Message and Storage" in Server Settings
What you mean by this?

> - meaning of following EXPUNGE related prefs setting(can be viewed via
> Config Editor)
>   mail.imap.check_deleted_before_expunge (default=false)
>   mail.imap.expunge_after_delete         (default=false)
>   mail.imap.expunge_threshold_number     (default=20. used by
> Penelope==Eudora only?)
No.

> Do you correctly understand difference between "Mbox of POP3 in gmx.net" and
> "Mboxes in gmx.net IMAP"?
I guess, in POP3 case the local Mbox is meant, but in IMAP case the server Mbox is meant.
(In reply to Ulf Zibis from comment #3)
> > - meaning of "View/Not Deleted" in "View/All,Unread,Not Deleted,Tags,Custm
> > Views"
> How to set this?
At ToolBar customize, add following item to ToolBar, MenuBar etc.
         +----------+
   View: | All    |V|
         +----------+
          Mail Views

> > - meaning of "Message and Storage" in Server Settings
> What you mean by this?
I don't know it well. I merely pointed an EXPUNGE related setting for you :-)

> a) In POP3 account it is deleted from the local Mbox.

If local mail folder(POP3, Local Folders), BarkleyStore is used by default instead of newly available MaildirStore.
If POP3/Local Folders && BarkleyStore, "delete a mail from FolderX" == (a) "Copy mail from FolderX to Trash" + (b) "write EXPUNGE bit=On of X-Mozilla-Status: header in file named FolderX" + (c) "remove MsgDBHdr for the mail in MsgDB for folder named FolderX(corresponds to FolderX.msf)".

(b) is same as "uid store xxx +Flags(\Deleted)" in IMAP.
"Mail data with EXPUNGE bit=On of X-Mozilla-Status: header in file named FolderX" is, as you already know pretty well, removed by Compact only.

Particularity of Tb's IMAP support is;
  Most natural "Just mark it as deleted" is supported.
  For convenience of users("mail marked as \Deleted" is merely annoyance for many users),
    "Remove it immediately" model is also supported.
  In addition to "Remove it immediately", "View/Not Deleted" was implemented.
  Compact of IMAP folder named FolderX =
      request EXPUNGE of Mox named FolderX to IMAP server
    + do "Compact operation" on Offline-Store file named FolderX which is BarkleyStore
Particularity of local mail folder in Tb is;
  "Move to trash" model is always forced.
  trash folder name is always "Trash".

Because EXPUNGE is issued after a while from delete operation by user(for example, upon Compact), some kind of users complaint "Tb doesn't remove mail from Mbox at server even though I deleted mail using Tb!!!!!".
So, following option is provided by developer.
>   mail.imap.expunge_after_delete         (default=false)
If mail.imap.expunge_after_delete=true, EXUNGE is always issued after "uid store xxx +Flags(\Deleted)" according to request by user.

It can easily produce "data loss" if "Just mark it as deleted" or "Remove it immediately" because copy of "mail marked as \Deleted" is not kept. And, "Undelete" of any deleted mail with this option is impossible, because server permanently removes mail data from Mbox at server by EXPUNGE command.
So, mail.imap.expunge_after_delete=true is effective only when IMAP delete model=="move to trash".
Surprise:
Now 2 days later via web-mailer I can see, that the before "deleted" (flagged as \Deleted) messages in folder "Gelöscht" are now removed and server space was freed. :-)
So I presume, the problem is the GMX web-mailer. In folder view it doesn't distinguish upon the \Deleted flags, but there seems to be a daemon, which daily expunges the flagged messages.

So it seems, that this bug is invalid, but wait ...and additionally see another problem with "View/All" below ...

I now also tried Compact after "Delete some 50 messages from Inbox (via virtual folder filter) to [Gelöscht]" + "Delete these 50 messages in folder [Gelöscht]". Results:
1. 1 of the 50 messages is still visible in TB's view ...very strange!
2. All of the 50 messages are still visible in web-mailers's view, so EXPUNGE seems not to work on imap.gmx.net and so I have to wait for the daemon run :-(

(In reply to WADA from comment #4)
> > How to set this?
> At ToolBar customize, add following item to ToolBar, MenuBar etc.
>          +----------+
>    View: | All    |V|
>          +----------+
>           Mail Views
Thanks for this hint. In the ToolBar the item uses much space. You mentioned the MenuBar as alternative, but I'm not able to move it there, as on my Ubuntu here, the MenuBar becomes not visible, even after enabling (there is the so called "globalmenu" from Unity desktop instead, where one can't move the "View" widget). This seems to be a bug, is it known?
Any other idea to move that functionality to the menus?

BTW: I only have "View/All" here, not "View/Not Deleted", in the ComboBox but it doesn't show the "flagged as \Deleted" messages :-(
Is that *the* bug from TB side? Then please adapt the subject of this bug accordingly!!


> > a) In POP3 account it is deleted from the local Mbox.
> 
> If local mail folder(POP3, Local Folders), BarkleyStore is used by default
> instead of newly available MaildirStore.

This makes me confused, as in other issues you mentioned Mbox for local folders. Web search for "BarkleyStore" didn't help, just try it ;-)

> So, following option is provided by developer.
> >   mail.imap.expunge_after_delete         (default=false)
> If mail.imap.expunge_after_delete=true, EXUNGE is always issued after "uid
> store xxx +Flags(\Deleted)" according to request by user.
> 
> It can easily produce "data loss" if "Just mark it as deleted" or "Remove it
> immediately" because copy of "mail marked as \Deleted" is not kept.
Does that mean, that technically in behind both options do the same "mark as \Deleted", but "Remove it immediately" automatically enables "View/Not Deleted" ?
Now I again "Deleted some other 32 messages from Inbox (via virtual folder filter) to [Gelöscht]", but did not delete them in folder [Gelöscht]". Results (after 2..5 minutes):
1. Only 2 of the 32 messages are additionally visible in TB's view of [Gelöscht] ...again strange!
2. All of the 32 messages are additionally visible in web-mailers's view of [Gelöscht].
... after ~30 minutes:
3. All except 1 of the above 2 messages are now visible in TB's view of [Gelöscht]

What the **** (sorry) is happening here?
Correction:
... after ~30 minutes:
3. All except 1 of the above 2 messages (=31) +plus+ again all the 50 messages from 1st try with "Delete in [Gelöscht] + Compact" are now visible in TB's view of [Gelöscht]
The one which is no more visible was hooked (prepared for further action, e.g. delete/markAsUnred..., but here just to remember 1 of the 2) in web-mailer interface during that time.
(In reply to Ulf Zibis from comment #5)
> You mentioned the MenuBar as alternative, but I'm not able to move it there,
> as on my Ubuntu here, the MenuBar becomes not visible,
> even after enabling (there is the so called "globalmenu" from Unity desktop instead,
> where one can't move the "View" widget).
> This seems to be a bug, is it known?
> Any other idea to move that functionality to the menus?

ToolBar, MenueBar, and Application menu, are different elements.
MenueBar was hidden by default after introducing Application menu by Tb 17.
Because "submenu for show/hide MenuBar" is placed in "Context menu of ToolBr", and because there is no menu/submenu for MenuBar in Application menu, if user hides ToolBar, there is no way to show MenueBar again except not-so-well-known("Hidden" for us) Alt+F8.

Are you experiencing this issue?

> BTW: I only have "View/All" here, not "View/Not Deleted", in the ComboBox
> but it doesn't show the "flagged as \Deleted" messages :-(
Because MsgDBHdr for "mail flagged as \Deleted" is kept in MsgDB only when "Just mark it as deleted" model, as I already explained, "View/Not Deleted" is absolutely same as "View/All" if "Remove it immediately" model and "move to trash" model.
I believe developer kindly hides meaningless "View/Not Deleted" if "Remove immediately" model and "move to trash" model, to avoid user's confusion.

> This makes me confused, as in other issues you mentioned Mbox for local folders.
> Web search for "BarkleyStore" didn't help, just try it ;-)
Sorry for typo. It's "Berkley".
You can see string of "Berkley" in following prefs entry.
> mail.server.serverN.storeContractID;@mozilla.org/msgstore/berkeleystore;1
This can be changed to following if you want to use MaildirStore for this account/server.
> mail.server.serverN.storeContractID;@mozilla.org/msgstore/maildirstore;1
See meta bug 845952 and meta bug 859011, please.

> Does that mean, that technically in behind both options do the same "mark as \Deleted",
> but "Remove it immediately" automatically enables "View/Not Deleted" ?
No.
- Upon delete mail,
  - Just mark it as deleted, Remove it immediately
    store \Deleted flag
  - Move to trash
    copy to Trash, then store \Deleted flag
- After store \Deleted flag
  - Just mark it as deleted
    Keep meta data(MsgDBHdr) of the "mail flagged as \Deleted" in MsgDB    
  - Remove it immediately, Move to trash
    Remove meta data(MsgDBHdr) of the "mail flagged as \Deleted" from MsgDB    
- "Mail which can be shown at thread pane" is only "mail whose MsgDBHdr(meta data)
  is held in MsgDB(corresponds to .msf file content).
  "View/Not Deleted" simply hides "meta data of mail flagged as \Deleted" at thread pane.
  So, "View/Not Deleted" is meaningful for user only when "Just mark it as deleted".
(In reply to Ulf Zibis from comment #7)
> Correction: (snip)
Web mail of ISP != Mbox shown via IMAP by ISP != Inbox shown via POP3 by ISP.
Gmail example.
  Because "\Deleted falg" is IMAP only attribute,
  "\Deleted flag of a mail" is absolutely irrelvant to Gmal's Web mail.
  So, even when \Deleted falg is stored by IMAP client via Gmail IMAP,
  the "mail flagged as \Deleted via Gmail IMAP by IMAP client" is still
  merely absolutely actve/alive mail for Gmail's Web mail.
  Thus, a "mail flagged as \Deleted via Gmail IMAP by IMAP client" is always shown as
  "absolutely actve/alive mail" by Gmail's Web mail.

Following my first question contains question for your understandig/knowledge about gmx's system.
> Do you correctly understand difference between "Mbox of POP3 in gmx.net" and "Mboxes in gmx.net IMAP"?
Here is bugzilla.ozilla.org. Here is never QA forum/support forum for gmx's system.
Please surely rule out gmx's partiqularity before posting comment relevant to gmx's system.
To Ulf Zibis(bug opener):
Your this bug is essentially absolutely same as bug 920402, which can be called "support request", which can not be "report of actual flaw in code of Tb" nor "enhancement request on Tb's functionality".
And, IIUC and IIRC, that bug 920402 is also a dup of existent *BUG* report at bugzilla.mozila.org which is continuously opened at bugzilla.mozilla.org by general users.
Can I close this bug as dup of bug 920402?
(In reply to WADA from comment #10)
> Can I close this bug as dup of bug 920402?

It seems, there is some difference. Please give me some days for more accurate testing.

Especially because of my experience, that "deleted" messages reappeared after ~30 minutes.

Also I do not see that, after deleting messages with "Move to Trash" model, the deleted messages are left in server Inbox, like described in bug 920402. They are really moved to the trash folder which is confirmed by no change in server space indicator.

Additionally, Compact doesn't have any effect here. And if there is no \Deleted flag at the gmx server, as you presumed, there must be any other similar mechanism, which is used by the daily daemon on the gmx server!

It seems, there is some difference on deleting manually selected messages in trash and using "Trash->Delete Trash". In latter case, the messages were always deleted immediately from the IMAP server.

I think, deleting a message in a trash folder should always force EXPUNGE, maybe after few seconds of inactivity, in consistency to local trash of POP3 account, where likewise no undo after delete is supported. At latest force EXPUNGE, when trash folder or TB looses focus.
This IMHO is what user expects from operating on any trash in contrast to other locations.
*** Deleting/Emptying trash is immediately freeing resources! ***
*** Different behaviour requires warning/explanation to the user! ***
(In reply to WADA from comment #9)
> > Do you correctly understand difference between "Mbox of POP3 in gmx.net" and "Mboxes in gmx.net IMAP"?
At this question it is not clear to me, if you mean the server- or client-side Mboxes and/or if you ask for any particularity at GMX.
To make it more clear from my side: Officially, my GMX account is a POP3 account (free account) via pop.gmx.net + mail.gmx.net, but it internally works as a IMAP server (to serve the web-mailer with trash folder, custom folders etc.) with some limitations (20 folders, only on 2 levels), and additionally there is a not officially announced IMAP access via imap.gmx.net.

> Here is bugzilla.ozilla.org. Here is never QA forum/support forum for gmx's system.
Sure, that's absolutely clear.

> Please surely rule out gmx's partiqularity before posting comment relevant to gmx's system.
TB's in-transparent hiding philosophy is a real problem to sort out, where an error/misbehaviour comes from :-(
What would it hurt, if there would be one/few optional columns in thread pane to display all IMAP flags to the user. Then e.g. there would be no question under which conditions View/All in fact is View/Not Deleted.
> TB's in-transparent hiding philosophy is a real problem to sort out, where an error/misbehaviour comes from :-(

To understand reason why I asked you to surely rule out server's particularity, *READ* :-) all bugs listed in dependency tree for meta bug 402793 with "Show Resolved", and count number of bugs to which I posted comment, please. (because there are many bugs which I read but not posted comment, number of bugs I read is larger than the count.)

I believe cause of "opening bug at bugzilla.mozilla.org of more than half of *BUGS* in the dependency tree" is ;
  user didn't read most important Gmail's Help which explains particularity of Gmail IMAP.
And, cause of "user don't read important document" is that it's pretty hard to know such important document exists, and, even if user(including me) could know such document exists, it's pretty hard to get to the document unless link to the document is provided by someone quickly when user(including me) wants to read it, even if user knows how to do Google Search :-)
  Why set of dispersed small "Help document" which looks FAQ document for me?
  Why not "Gmail IMAP User's Guide" or "Gmail IMAP User's Reference" like one?
However, here is still bugzilla.mozilla.org for developers in order to implement open software and resolving actual bugs of open software, even if any general Thunderbird user can create report called *BUG* at bugzilla.mozilla.org. If help for trouble shooting is needed, I believe it should be asked at support forum instead of bugzilla.mozilla.org for developers.  

Please note;

If Tb user requested Tb to mark a mail as deleted while Work Offline mode, regardless of that user is aware of Offline mode or is not aware of it, and if Tb user goes to gmx Web site and check mail via Web mail before going back to Online mode, complaint of "mail is not deleted even though I requested Tb to delete mail!!!" is merely a user's fault.
(if cause is surely "Tb wrongly shows status" and bug is opened at bugzilla.mozilla.org, problem description has to be "Tb should correctly show/notify Offline mode to user" instead of "mail was not deleted".)

If Tb actually doesn't send "uid store nnn +Flag(\Deleted)" to gmx IMAP server even though Tb user correctly requested Tb to mark a mail as deleted, it's simply Tb's fault.
This kind of problem should be reported and processed at bugzilla.mozilla.org.

Once Tb actually sent "uid store nnn +Flag(\Deleted)" to gmx IMAP server and gmx server returned OK to it, behavior of gmx's any server is all up to gmx.
Gmx can show it freely "as deleted mail", "as active mail", or not show because deleted.
In this case, if something wrong for you occurred in gmx's Web mail, it should be reported to gmx instead of bugzilla.mozilla.org.

> What would it hurt, if there would be one/few optional columns in thread pane to display all IMAP flags to the user.
Such thing never exists currently. Complaint on such thing won't help problem analysis at all.

All communication between IMAP server and IMAP client is done by IMAP command and IMAP response. So, IMAP log is mandatory to know what happens in many many case.
Further, Tb surely has problem in unread mail count display at folder pane when CONDSTORE is supported by server and Tb's CONDSTORE support is enabled(enabled by default), and Tb shows only unread mail count at folder pane unless add-on to display unread count/all mail count/size at folder pane is installed. So, "report by user about mail count", which is obtained by merely looking Tb's folder pane, can be inaccurate and/or insufficient.

For problem determination of your new problem(number of mails is relevant), which is different problem from one stated in bug summary, which violates manner of "one problem per a bug", protocol level flow analysis is required.
However, even though you already know about NSPR logging well, you don't look to try to get and check IMAP log by yourself.
How can I help you?
IIRC, I already let you know how to get log ad-hoc using DebugView on Win. Wrong?
(In reply to Ulf Zibis from comment #11)
> Especially because of my experience, that "deleted" messages reappeared after ~30 minutes.
"mail reappeared even I deleted" case which I know is;
(a) At PC A, user-A deleted a mail -> Other people undeleted the mail at defferent device
(b) A mail has Gmail Label of "A" and "B". (mail is shown as mail in Mbox A and Mbox B)
    Delete mail in Mbox A(==Move to [Gmail]/Trash)
    Gmail removes Gmail Label A, and move mail to [Gmail]/Trash), hide Gmail Label B.
    => mail instance in Mbox B disappears == "mail in Mboxc B is deleted" for user/Tb
    Copy the mail to Mbox C => Gmail moves the mail to [Gmail]/All Mail,
    adds Gmal Label C, and unhide Gmail Label B
    => The mail re-appears in Mbox B.
(c) Mail data is backed up at server -> user deletes mail
    -> server problem occurs, then server admnitrator restores mail data from backup
    -> deleted mail re-appears. (or some mails are lost)
(d) Server application replaced mail data after user deleted.
    New mail arrives, UID=AA is assigned.
    UID=AA is fetched by Tb, and Tb user deletes it => uid store AA +Flags(\Deleted).
    After it, server application(spam/virus checker in many cases) replaces mail data,
    with/without changing header sequence, with/without adding new headers,
    with new UID=BB(AA<BB), with permanently removing UID=AA or with keeing UID=AA as-is.
    Because "mail of UID=BB" is new mail for IMAP client including Tb,
    mail is fetcched and presented to Tb user.
    Because Subject:/From:/To:/message body etc. is absolutely same as mail of UID=AA,
    it looks "deleted mail re-appeared" for Tb user.
    IIRC, this (d) which I saw at bugzilla.mozills were MS Exchange case only.

> I think, deleting a message in a trash folder should always force EXPUNGE, (snip)
Why can it be "SHOULD"?

IMAP Mbox can be shared by multiple IMAP clients. And (a) user of the "multiple IMAP clients" can be a single person, but (b) the user can also be multiple peoples.
 (a) A person uses Tb on PC at home, Outlook on PC at office, Smart Phone with IMAP client
 (b) In company, Mr. A uses Tb on PC A, and Mrs. B uses Outlook on PC B,
     and shares same IMAP account.
In case (b), Mr. A does "uid store MM +Flags(\Deleted)", and Mrs. B does it on UID=NN.
If Mr.  A requests EXPUNGE, both UID=MM and UID=NN is permanently removed from Mbox.
If Mrs. B requests EXPUNGE, both UID=MM and UID=NN is permanently removed from Mbox.
In any case, it's "mail marked as \Deleted by me is permanently deleted by someone, even though I kept the mail in case of that Undelete is needed". i.e. data loss for one person.
Because "selective EXPUNGE"(uid EXPUNGE nn like feature) is not always supported by IMAP server(rather still rare, I believe), and "selective EXPUNGE" is not supported by Tb yet, Tb's standard action can not be "Do EXPUNGE blindly always". This is same even on Mbox called Trash.
Please don't always blindly expand your want or requirement to "SHOULD of mail client called Thunderbird". 

As I already explained, if "Move to trash" + mail.imap.expunge_after_delete=true, EXPUNGE is issued after delete.
Do you want "no automatic expunge after delete if other than trash" and "automatic expunge after delete only on trash"? ("per folder expunge_after_delete" like option).
Or EXPUNGE is not issued after delete if trash when "Move to trash" + mail.imap.expunge_after_delete=true?
FYI. I incidentally met following bug again(I had put CC:, but I forgot it...) 
> Bug 624841 mail.imap.expunge_after_delete does NOT work for folder TRASH
How to check bug 624841 occurs or not quickly.
1. Show "Order Received" column to see MessageKey value(=UID of mail if IMAP).
   "Move to trash" + mail.imap.expunge_after_delete=true
   At Server Settings/Advanced set max cached connection=2
   (force select + uid fetch 1:* flags upon each folder open in test)
   mail.server.default.use_condstore = false
   (I don't know gmx imap supports CONDSTORE or not. So disable in case of "supported")
   Restart Tb.
2. Delete a mail at FolderX (UID=A) => mail is moved to Trash
   At Trash, delete the "deleted mail"(UID=B)
3. Change to "Just mark it as deleted".
   Open FolderX. If mail of UID=A is not shown, EXPUNGE was issued as expected.
   Open Trash.
   If mail of UID=B is not shown, EXPUNGE was issued as expected.
   If mail of UID=B is shown with strike-thru line, EXPUNGE was not issued.
   If mail of UID=B is shown without strike-thru line, store flag \Deleted was not issued.
To make it sure, IMAP log is needed. But I can't imagine reason why "uid store xx +Flags(\Deleted)" is not issued by Tb in above test. So, check of step 3 is sufficient for quick check.
FYI.
An example of "report from user about mail count, which is obtained by merely looking number shown at folder pane, is inaccurate".
  Bug 917886 (problem from Tb 24 by new feature in Tb 24)
  Because "unread count in folder pane" is "unread count of the folder" in some cases,
  but "unread count in folder pane" is "total unread mail count of the folder and all
  subfolders" or "total unread mail count of all search target folders" in other cases, 
  you have to clearly state Which *folder" at Which View, Folder is expanded or not, etc.
  Needless to say, IMAP log is better for presenting accurate and useful data,
  if what happens is unclear.
  (see also bug 939462. For performance issue. Not for problem of "too confusing")
This time I deleted whole Trash with 3 messages inside
This time I selected the 3 only messages in Trash and deleted them.
WADA, thanks for all your further explanations.
I agree with you, that problems with deleting mails first should be discussed in support forum rather than in BugZilla. Please excuse, if I did wrong in filing a bug first.
Please exceptionally allow one question again:
If user has 3 mails in Trash there are to ways to delete them:
1. Delete the whole Trash with action from context menu of Trash.
2. Select the 3 mails and delete them.
IMO, both seem to do the same from user perspective, because after there are no more mails visible in Trash.
As you can see in my above logs, different IMAP commands are used, and the results at the server are different:
1. All mails are removed from server.
2. The 3 mails still exist in Trash on server, but get expunged later by servers daemon.
Can't you agree with me, that this is not transparent enough to the user when just wanting to empty the Trash to free space from the server?
I think, this is the key of the problems I experienced.
Is there a way to have
mail.imap.expunge_after_delete=true  for Trash
mail.imap.expunge_after_delete=false for all other folders
?
Or if user selects the "Move it to this folder"-model for a distinct account, is it possible to implicitly set mail.imap.expunge_after_delete=true only for this account, as after deleting a mail from folder A, it is copied to Trash, so there is no danger for "UnDo" not to work after expunging folder A.
The miracle: The GMX server seems to expunge folder A immediately, even if mail.imap.expunge_after_delete=false.
(In reply to Ulf Zibis from comment #20)
> If user has 3 mails in Trash there are to ways to delete them:
> 1. Delete the whole Trash with action from context menu of Trash.
> 2. Select the 3 mails and delete them.
> IMO, both seem to do the same from user perspective, because after there are
> no more mails visible in Trash.
How these can be SAME?
After 1, Mbox labeled Trash doesn't exist any more on the Earth.
Even if Mbox laeled Trash appeared at folder pane again, it is absolutely different Mbox from the deleted Trash. The different Mbox is newly created and is merely labeled "Trash". Because of "newly created Mbox", state is "empty". 
After 2 and EXPUNGE, absolutely same Mbox labeled Trash surely actually exists on IMAP server, and state of the Mbox labeled Trash is "empty" at both in Tb and server after EXPUNGE.

What executed at protocol level, which is named IMAP.
1. "delete Trash", "unsubscribe Trash"
   "create Trash", "subscribe Trash"
2. select "Trash"
   "uid store xx:yy +Flag(\Deleted)"
   "expunge"

In Tb, context menu of Trash doesn't have "delete Mbox" when "move to trash" model, because Trash folder is mandatory folder in "delete mail" operation. When other delete model, trash folder is never used upon "delete mail" operation. So "delete folder named Trash" is possible when "Just mark it as delete" and "Remove it immediately".
This is simply:
  Choose "Move to trash" : Add special attribute of "Trash" to Mbox used as trash.
  Change to other model  : Remove specal attribute of "Trash" from Mbox used as trash.
  At context menu: When Mbox has special attribute of "Trash", don't show "delete" action.
  At folder pane : Show special folder icon if Mbox has special attribute.
This is same on other special attribute of "Sent", "Draft", "Archive", "Junk" etc.
I don't know which icon is shown when an Mbox is used for all of Archive, Junk, Draft, Sent by you. 

(In reply to Ulf Zibis from comment #21)
> Is there a way to have mail.imap.expunge_after_delete=true for Trash
Have you read and understand bug 624841?
Have you checked bug 624841 occurs in your evironment or not?
It's merely bug 624841 occurred in your environment too, isn't it?
Or bug 624841 is by design and is intentional behavior, so you are requesting "mail.imap.expunge_after_delete=true for Trash"?

Anyway, please get IMAP log and check IMAP log using Text Editor by yourself before writing complaints or wants repeatedly in article named *BUG* at bugzilla.mozilla.org.
(In reply to WADA from comment #22)
> How these can be SAME?
> After 1, Mbox labeled Trash doesn't exist any more on the Earth.
> Even if Mbox laeled Trash appeared at folder pane again, it is absolutely
> different Mbox from the deleted Trash. The different Mbox is newly created
> and is merely labeled "Trash". Because of "newly created Mbox", state is
> "empty".

Sorry for my bad English.
I executed in german "Gelöscht->Papierkorb leeren", which is "Empty Trash" in english.
So Mbox labeled Trash was not deleted, but emptied by
   "uid store 1:* +Flag.SILENT (\Deleted)"
   "uid expunge"
In comment 5 I reported, that Compact didn't work.
I tried again, now it seems to work :-)
Don't know why it didn't work before with ~50 mails in Trash.

(In reply to WADA from comment #22)
> Have you checked bug 624841 occurs in your evironment or not?
> It's merely bug 624841 occurred in your environment too, isn't it?
Yep!
Thanks for pointing at this again.
Attachment #8344255 - Attachment mime type: text/plain → text/x-log
Attachment #8344254 - Attachment mime type: text/plain → text/x-log
(In reply to WADA from comment #4)
> If POP3/Local Folders && BarkleyStore, "delete a mail from FolderX" == (a)
> "Copy mail from FolderX to Trash" + (b) "write EXPUNGE bit=On of
> X-Mozilla-Status: header in file named FolderX" + (c) "remove MsgDBHdr for
> the mail in MsgDB for folder named FolderX(corresponds to FolderX.msf)".
> 
> (b) is same as "uid store xxx +Flags(\Deleted)" in IMAP.
> "Mail data with EXPUNGE bit=On of X-Mozilla-Status: header in file named
> FolderX" is, as you already know pretty well, removed by Compact only.

I'm afraid, this is not correct.
As you can see from above log, no "uid store xxx +Flags(\Deleted)" was issued and no "expunge".
Instead "uid move 5,6,7 "Gelöscht"" was issued and EXPUNGE was automatically executed by the server. This explains, why server space is not changed with "move to Trash" delete model.
I think, this bug in the main is a duplicate of bug 624841.
But I additionally want, that if "Move to trash" delete model is configured, mail.imap.expunge_after_delete=true is set automatically and would also affect the Trash as described in bug 624841, because "UnDo Delete" would still remain to work properly on normal folders using the copy from the trash folder.
It is not intuitive to the user, when mails are deleted from Trash, that server space is not freed immediately.
With default of mail.imap.expunge_threshold_number=20, server activity should be enough prevented from overload.
(In reply to Ulf Zibis from comment #25)
> Instead "uid move 5,6,7 "Gelöscht"" was issued and EXPUNGE was automatically executed by the server.
If server supports MOVE extention, Tb uses MOVE command instead of "copy + store \Deleted".
Your server looks to support MOVE.
If MOVE extension is supported, there is no need to issue EXPUNGE at "move source folder". So, "choose Move to trash model" is suficient in Tb in order to achieve "immediate expunge after delete mail(move to Trash).
It's the trick that you never complainted about other than Trash.
It's reason why you didn't see mail with strike-thru line when you changed from "move to trash" to "Just mark it as deleted".

Because there is no "move target folder" when "delete mail at Trash", MOVE command is not usable. Method provided by protocol named IMAP for "delete mail at Trash" is;
 select Trash, uid store a:b,...,y:z +Flags(\Deleted)
 EXPUNGE, when "permanent removal of the deleted mail in Trash" is possible.

Retention policy depends on company/ISP.
  Gmail automatically/permanently removes mail data in [Gmail]/Trash(via IMAP. if Web mail,
  folder named "Trash") after 30 days from when the mail is copied/moved to [Gmail]/Trash.

What problem other than bug 624841 is involved in your case with gmx IMAP?
Because your server supports MOVE and Tb uses MOVE, there is no need to pay atention to other than Trash.
If EXPUNGE is issued upon "delete mail at Trash" when "Move to trash model" + mail.imap.expunge_after_delete=true, your want is fulfilled.

No retention policy on mail in Trash in gmx?

About bug 624841.
  It may be intentional.
  Because of mail.imap.expunge_after_delete=true, mail in Trash is only one copy of mail.
  Mailer can't do "permanent remove of final mail" without user's explicit order to execute
  "permanent remove of final mail".
  Tb is a mailer.
  And, "delete mail at Trash by user" is not always user's explicit request to remove
  final mail permanently.
  If Tb does so, bug like following will surely be opened at B.M.O by many users :-)
    After I deleted my mail at Trash, I couldn't undelete the mail. Data loss!!!
  "Compact" is one of user's explicit orders to execute "permanent remove of final mail".

As I already wrote, mail.imap.expunge_threshold_number may not be used by standard Tb.
> mail.imap.expunge_threshold_number  (default=20. used by Penelope==Eudora only?)
I don't know whether "added to Thunderbird 3" means "Tb 3 or later uses this option" or "Tb 3 or later has this option in all.js or mail.js".
http://kb.mozillazine.org/Deleting_messages_in_IMAP_accounts#Misc
> The Penelope extension and Eudora have a mail.imap.expunge_option that provides auto-expunge like the original Eudora [3].
> It was later on added to Thunderbird 3.
IIUC and IIRC, Tb's behavior was "issue expunge when more than 10 mails are deleted" and the "10" is hard coded. But it might be in Tb 1/2.
Even when mail.imap.expunge_threshold_number is used by Tb, it may be on other than Trash only in Tb.
Is auto-compact invoked on your trash folder of gmx IMAP after "delete mails in trash"?
(In reply to Ulf Zibis from comment #21)
> Is there a way to have mail.imap.expunge_after_delete=true for Trash

If server supports MOVE extension, Tb uses MOVE command upon "move mail between IMAP folders".
If "Move to trash" model, "delete a mail in an IMAP folder(except at trash)" is always "uid MOVE nn trash".
So, unless Tb user executes "delete mail at trash folder", Tb user can do undelete of mail any time on any mail.
Unless Tb user invokes EXPUNGE at trash folder, Tb user can do undelete any time on any mail even at trash folder after "delete mail in trash older", by changing to "Just mark it as deleted" model temporarily.

Do you think mail.imap.expunge_after_delete=true can be always considered
  "Tb user explicitly requests Tb to issue EXPUNGE on trash folder
   after the Tb user deletes mails at trash folder on the Tb"
if "server supports MOVE extension" && "the Tb user intentionally chooses Move to trash model at the PC",
in any environment,
regardless of "an IMAP trash folder is shared by multiple Tb users on multiple PCs, or not",
regardless of "other Tb user on other PC uses move to trash model, or not",
regardless of "other Tb user on other PC sets mail.imap.expunge_after_delete=true, or not"?

Please always isolate "Your want or requirement" and "Tb's mandatory standard/default behavior as an mailer who supports protocol named IMAP".
(In reply to WADA from comment #27)
> (In reply to Ulf Zibis from comment #25)
> > Instead "uid move 5,6,7 "Gelöscht"" was issued and EXPUNGE was automatically executed by the server.
> If server supports MOVE extention, Tb uses MOVE command instead of "copy +
> store \Deleted". [snip]
Thanks for your explanation, which I was missing after I wrote:
> Also I do not see that, after deleting messages with "Move to Trash" model,
> the deleted messages are left in server Inbox, ...

> What problem other than bug 624841 is involved in your case with gmx IMAP?
> Because your server supports MOVE and Tb uses MOVE, there is no need to pay
> atention to other than Trash.
In principle yes!

> If EXPUNGE is issued upon "delete mail at Trash"
?? I assume you mean "Empty Trash" with that ??
> when 
> + mail.imap.expunge_after_delete=true, your want is fulfilled.
I additionally want, that mail.imap.expunge_after_delete=true is default for "Move to trash model"

Thinking a little bit more, I would prefer property expunge_after_delete *per-account*. If user has different IMAP accounts, I believe there may be a desire to have different "Delete Policies", at least, if they were configured for different delete models. If user has configured "Mark as Deleted" model, what should happen upon mail.imap.expunge_after_delete=true or vice versa for the "Remove it immediately" model?

If MOVE is not supported by the IMAP server, I additionally want expunge_after_delete=true as default upon "Move to trash model" to guarantee that server space is not wasted.

> No retention policy on mail in Trash in gmx?
Hm, I do not understand what you mean.

> About bug 624841.
>   It may be intentional.
>   Because of mail.imap.expunge_after_delete=true, mail in Trash is only one
> copy of mail.
>   Mailer can't do "permanent remove of final mail" without user's explicit
> order to execute
>   "permanent remove of final mail".
>   Tb is a mailer.
>   And, "delete mail at Trash by user" is not always user's explicit request
> to remove
>   final mail permanently.
This is common behaviour upon Windows Explorer and also on all Linux File Managers I know. User expects freeing resources by deleting objects in Trash. Anyway with multi-user access, the "marked as deleted" mails could be expunged quickly if other user expunges trash or server daemon comes along, so guaranty for "UnDo" would not hold anyway.
This is also common behaviour upon web-mailers, so no surprise or inconsistency to the user.

Having "Move to Trash" model IMHO is enough safety for mailers via web or client and file managers too.
My only concern is about server load which could be limited by expunge_threshold_number.

>   If Tb does so, bug like following will surely be opened at B.M.O by many
> users :-)
>     After I deleted my mail at Trash, I couldn't undelete the mail. Data
> loss!!!
Do you know upon such bug reports massively on e.g. Windows Explorer?

>   "Compact" is one of user's explicit orders to execute "permanent remove of
> final mail".
... which could be invoked quickly by server daemon of concurrent user anyway.

> As I already wrote, mail.imap.expunge_threshold_number may not be used by
> standard Tb.
Uups, please excuse my forgetting.
(In reply to WADA from comment #29)
> If server supports MOVE extension, Tb uses MOVE command upon "move mail
> between IMAP folders".
> If "Move to trash" model, "delete a mail in an IMAP folder(except at trash)"
> is always "uid MOVE nn trash".
> So, unless Tb user executes "delete mail at trash folder", Tb user can do
> undelete of mail any time on any mail.
YES!

> Unless Tb user invokes EXPUNGE at trash folder, Tb user can do undelete any
> time on any mail even at trash folder after "delete mail in trash older", by
> changing to "Just mark it as deleted" model temporarily.
... except garbage daemon or other user expunges all mails with "marked as deleted".
If user explicitly wants an *uncommon* Trash behaviour, I could chum up with a non-default property like never_expunge_after_delete_marked.

> Do you think mail.imap.expunge_after_delete=true can be always considered
>   "Tb user explicitly requests Tb to issue EXPUNGE on trash folder
>    after the Tb user deletes mails at trash folder on the Tb"
> if "server supports MOVE extension" && "the Tb user intentionally chooses
> Move to trash model at the PC", in any environment,
Yes, because from this model mails in Trash are NOT "marked as deleted".

> regardless of "an IMAP trash folder is shared by multiple Tb users on
> multiple PCs, or not",
> regardless of "other Tb user on other PC uses move to trash model, or not",
> regardless of "other Tb user on other PC sets
> mail.imap.expunge_after_delete=true, or not"?
+ regardless garbage daemon expunges all mails with "marked as deleted" in Trash.

> Please always isolate "Your want or requirement" and "Tb's mandatory
> standard/default behavior as an mailer who supports protocol named IMAP".
My want is to have above behaviour as standard/default ;-)
(In reply to WADA from comment #28)
> Is auto-compact invoked on your trash folder of gmx IMAP after "delete mails
> in trash"?
Yes, if wasted space is above 10 MB.
But before real execution there is always an acknowledgement dialogue.
Another weird behaviour:
With "Move to trash" model delete 14 mails in Inbox.
Mark the 14 mails in Trash and delete.
--> 14 mails are still on server (marked as deleted).
Switch to "Delete immediatly" model.
--> 14 mails are deleted on server without doing anything.
(In reply to Ulf Zibis from comment #30)
> I would prefer property expunge_after_delete *per-account*.
I agree with you. "per account setting" is better.
  This is usually done by;
    mail.server.default.XXX = true/false in mailnews.js(global setting, for all accounts)
    mail.server.server#.XXX = true/false in prefs.js by user or by Tb(for each account)
See many mail.server.default.XXX via Config Editor.
There is no "mailnews.server.default.YYY". It may be a reason why I see bug of "YYY doesn't work on News account" sometimes :-)   

> guarantee that server space is not wasted.
There are already many ways to permanently remove "mail data which is flagged \Deleted", automatically or semi-automatically or manually.
- Server's retention policy : "Remove after 30 days from [Gmail]/Trash" of Gmail.
- Quota setting at server with feature like "remove old mails when quota is exceeded".
- mail.imap.expunge_after_delete=true
- Clean up("Expunge") Inbox on Exit
- Auto-Compact (issues Expunge, do compaction of offline-store file)
- "Compact Folders" menu and "Compact" context menu
- Empty Trash on Exit + Auto-Compact
- Empty Trash menu + (Auto-Compact or Compact Folders or Compact)
- Per folder "Retention setting" + (Auto-Compact or Compact Folders or Compact)

Why "immediate expunge of each mail just after delete request by you always" is so important or mandatory in your environment in order to keep mail data size or average mail data size in server Mbox within adequate size?
You can't permit "existence of mail flagged as \Deleted in your Mox at server"?
If so, ask IMAP protocol developer to implement "Delete-mail-immediately-permanently-Never-keep-it-as-flagged-Deleted" command, please.

> This is common behavior upon Windows Explorer and also on all Linux File Managers I know. 
> User expects freeing resources by deleting objects in Trash.
However, Windows Explorer kindly asks user for confirmation upon "delete file/directory at Trash" and "Shift+Delete at non-Trash&Trash".
Unless this kind of action by Tb will be implemented, I can't accept your request of "Silently remove capability to undelete deleted mails by user at Trash".

Even if user intentionally sets "Retention Setting" by himself, if user wants to read a purged mail by his retention setting again, user opens bug :-)
  My required mail was purged by Tb. Data Loss!!! Tb's bug!!!
  Tb has to provide me a way to recover the my important lost mail.
FYI. A way which utilizes Clean up("Expunge") Inbox on Exit.
  Use Inbox as Trash :-)
  Move all new mails to Inbox2 by message filter => MOVE command is used
  Delete mail -> Moved to Inbox using MOVE
  Delete at Inbox
  Terminated Tb => EXPUNGE is issued to Inbox
.
(In reply to Ulf Zibis from comment #33)
> Another weird behaviour:
> With "Move to trash" model delete 14 mails in Inbox.
> Mark the 14 mails in Trash and delete.
> --> 14 mails are still on server (marked as deleted).
> Switch to "Delete immediatly" model.
> --> 14 mails are deleted on server without doing anything.
Interesting.
Was dialog before Auto-Compact shown? (perhaps no, because you don't refer to dialog)
If no, it may be due to "Change from Move to Trash to Remove it immediately".
  mail.imap.expunge_after_delete is always true.
  Current mode == "Move to trash"
  Special attribute of "Trash" is removed from trash folder by the change.
  Becouse of IMAP delete model change, trash folder is re-opened again, and flag of all
  mail in trash is obtained.
  Because "change to Remove it immediately" is requested, MsgDBHdr of mail flagged \Deleted
  is removed. This is similar to ordinal "Delete mail".
  Because Current mode is still "Move to trash", this "delete MsgDBHdr" is considered
  OnlineMove or OnlineToOfflineMove. Then EXPUNE is issued.
  After it, "Change to Remove it immediately" model completes, and Current mode is changed.

Have you obtained IMAP log? Is it consistently re-producible even with one deleted mail in trash?
(In reply to WADA from comment #35)
> FYI. A way which utilizes Clean up("Expunge") Inbox on Exit.
>   Use Inbox as Trash :-)
>   Move all new mails to Inbox2 by message filter => MOVE command is used
>   Delete mail -> Moved to Inbox using MOVE
>   Delete at Inbox
>   Terminated Tb => EXPUNGE is issued to Inbox

Very funny idea :-D
Especially in multi-user mode, or when I'm travelling, using web-mailer.
(In reply to WADA from comment #34)
> (In reply to Ulf Zibis from comment #30)
> > I would prefer property expunge_after_delete *per-account*.
> I agree with you. "per account setting" is better.
Since we know from bug 624841, that it only applies on "Move to trash" model, I don't see it as much important any more, i.e. it has no effect on account-wise "Delete immediately" or "Mark as deleted" model.

> > guarantee that server space is not wasted.
> There are already many ways to permanently remove "mail data which is
> flagged \Deleted", automatically or semi-automatically or manually.
> - mail.imap.expunge_after_delete=true
From bug 624841 we know that doesn't work.
> - Clean up("Expunge") Inbox on Exit
Doesn't help for Trash and is superfluous if server provides MOVE action.
> ...
Most of these ways have some delay and/or are in-convenient and hard to communicate to laymen or not usable on selective deletions in Trash.

> Why "immediate expunge of each mail just after delete request by you always"
> is so important or mandatory in your environment in order to keep mail data
> size or average mail data size in server Mbox within adequate size?
Because I wanted to help my "stupid" girlfriend when unexpected faced with "Your mailbox is full" and to save her from using the cumbersome web-mailer for clean-up. In web-mailer you get only 100 search results for e.g. "newsletter xyz" at once, you can't search for distinct fields e.g. "To", you see only 100 messages at once and only can navigate +/-100 messages and always have to wait for rendering the web page.
She uses the Trash as a kind of an archive, which I think is not so bad idea, so "Empty Trash" is not an option.
When she selectively deletes messages from Trash via TB IMAP access, she has to wait for the daily garbage daemon to effectively get rid of "Your mailbox is full", as manually compact Trash sometimes didn't work for some unknown reason (see comment 5).

> You can't permit "existence of mail flagged as \Deleted in your Mox at
> server"?
Hm, what you mean by that?

> However, Windows Explorer kindly asks user for confirmation upon "delete
> file/directory at Trash" and "Shift+Delete at non-Trash&Trash".
This is good for computer laymen which normally use Windows and web-mailer.
TB is used by at least little experienced users and at Linux file managers you see this kind dialogue rarely at all, as they all rely on the safety from Trash and all know, that with delete in Trash or Shift+Delete "UnDo" is screwed up.

> Unless this kind of action by Tb will be implemented, I can't accept your
> request of "Silently remove capability to undelete deleted mails by user at
> Trash".
Anyway, if garbage daemon comes along or concurrent user expunges manually or by delete immediately, "Undelete deleted mails by user at Trash" is screwed up.

> Even if user intentionally sets "Retention Setting" by himself, if user
> wants to read a purged mail by his retention setting again, user opens bug
> :-)
>   My required mail was purged by Tb. Data Loss!!! Tb's bug!!!
>   Tb has to provide me a way to recover the my important lost mail.

Could be. This seems sometimes the penalty for open source projects.

Would you like to give it a try with the kindly dialogue "Would you really like to delete x messages permanently?", and a disable check-box in the settings?
(In reply to WADA from comment #36)
> Have you obtained IMAP log? Is it consistently re-producible even with one
> deleted mail in trash?
It is not reproducible with 1 mail in trash.
(In reply to WADA from comment #36)
> Have you obtained IMAP log? Is it consistently re-producible even with one
> deleted mail in trash?
This time it is also not reproducible with 14 mails in trash :-(
Oops, 3 minutes later I closed TB, and then the 14 mails were deleted from Trash, but unfortunately I had stopped logging before closing TB.
(In reply to Ulf Zibis from comment #38)
> She uses the Trash as a kind of an archive, which I think is not so bad idea,
It's pretty popular behavior of many many POP3+Local Folders/Tb users. I believe it's applicable to IMAP/Tb user, because user doesn't care POP3 or IMAP. 
So, I can't accept your proposal unless "Windows Exploerer like confirmation" will be implemented in Tb for delete mail at trash, Shift+Delete of mail with 'move to trash', etc.
  Note:
   Shift+Delete in Tb is "delete without copy to trash" for long long time(inherited from
   Netscape), and was pretty popular until many users started to use Thunderbird.
   And, "Shift+Delete of mail in MAP" == "store flag \Deleted" in Tb,
   regardless of IMAP delete model in Tb.
   This is same as "Shift+Delete of file/directory in Windows Explorer".
   "Shift+Delete of file/directory in Win" is also "delete without copy to Trash".
   Difference is;
     Shift+Delete of file in Win(no copy in Trash) : 
       Way to undelete is not provided(this is not MS/DOS, so it's pretty hard).
       Block/extent is put in free resource chain, so it is reused for other file.
       Salvage software is needed for undelete.
       Because of "no way to undelete", some users believe "permanent remove".
       But Deflag like action is never executed by "Shift+Delete" even in Win.
     Shift+Delete of mail in IMAP(store flag \Deleted) :
       In IMAP, \Deleted is merely a flag in IMAP.
       So, space for the mail is not freeed until EXPUNGE operation is invoked by someone
       and "Undelete" is always possible by "store -Flags(\Deleted)" until EXPUNGE
       operation is invoked by someone.
       The someone is; server daemon who removes old mails by retension policy,
                       IMAP client such as Thunderbird, Smart Phone
       Because some kind of users believe "Shift+Delete==Permanent remove",
       such users opens bug like "Tb doesn't remove mail from IMAP Mbox even though I did
       Shift+Delete". 

> When she selectively deletes messages from Trash via TB IMAP access, she has
> to wait for the daily garbage daemon to effectively get rid of "Your mailbox
> is full",

Does it mean Tb's auto-compact didn't work well as expected, so mbox full occurred?
Or gmax's garbage daemon removes old "mail flagged \Deleted" periodically or by threshold, but it's not so frequently and the daemon doesn't remove so many mails at a time?
Or gmx's Mbox is BerkleyStore like one, so similar operation to "Compact of local mail folder in Tb" is needed at server in order to free disk space which is still filed by "mail purged by EXPUNGE command", but it's not so frequent. If this case, "EXPUNGE by IMAP client" can do nothing for "immediate recovery from Mbox full" when "Mbox full at server" happened. IMAP client can do only "issue EXPUNGE command, and wait for Compaction by server".

IIRC, Tb had problems like (a) "auto-compact is not scheduled correctly for some kinds of Mbox" or (b) "Compact of IMAP folder doesn't work as desinged". But IIRC, (a) is already resolved, and even if (b) still remains, it's problem on compaction of Offline-Store file instead of issueing EXPUNGE command. 

Please note that threshold of "10 MB" is "total byte of deleted mails in entire Thuderbird" which triggers auto-compact. And, when auto-compact is scheduled, Tb doesn't schedule auto-compact for one hour, reardless of "total size of deleted mails in Tb after last auto-compact".

Within the one hour, his mbox became full?
"10 MB" is too large as threshold, then his mbox became full?

> as manually compact Trash sometimes didn't work for some unknown reason (see comment 5).

It's merely "expunged mails were still shown at Virtual Folder==Search Folder==folder which shows search result upon search folder open, isn't it?
IIUC, gmx server supports MOVE extension, and "MOVE" is seen in your log, althogh I still don't see CAPABILITY response from your gmx server in your log. So no problem in other Mbox than Trash.
And, IIRC, Tb sends "(select Trash) + EXPUNGE" to server when Compact is requested on Trash by Tb user. Once server returns OK to EXPUNGE command, "mail flagged as deleted in Trash" is removed from mbox named Trash by server, regardless of state of mails in Tb.
If "mail flagged as deleted in Trash" still kept in mbox named Trash on server even after OK response to EXPUNGE command from server, it's merely server bug.

> Hm, what you mean by that?
What is your acceptable Residence Time of a "mail flagged \Deleted" in Mbox of IMAP server?
(0) 0 sec
(1) less than 1 sec
(2-x) N sec, N min, N hour, N days
(3-x) N weeks, N months, N years
It sounds for me you are requesting "always (0) on any Mbox of any IMAP server".
Note:
By MOVE extension, if gmx IMAP server, (0) is already achived on other than Trash, if "Move to trash" model is used.
For (0), "Delete-mail-immediately-permanently-Never-keep-it-with-Deleted-flag" command is needed. This is similar to DELE in POP3.
For (1), "selective EXPUNGE" support is needed.

I believe "auto-expunge by auto-compact every several days ~ a few weeks" is usually sufficient to avoid "Mbox full of IMAP Mbox".
Even when "Mbox full of IMAP Mbox" happens, following is possible;
  1. change to "Just mark it as deleted",
  2. confirm that many mails are kept with "mail flagged \Deleted" state in an Mbox,
  3, do Compact or Compact Folders(EXPUNGE command is issued by Tb),
     (I don't know "Compact Folders" is "compact of all folders of all accounts")
     (or "compact of all folders of currently selected account".                )
  4. change back to "Move to trash" for daily use.
This is a big difference from "Mbox full at server in POP3". "Selective DELE" is pretty hard in Tb, so usually Web mail, other mailer, is needed, although "DELE for all mails" is easily achieved by "Uncheck 'Leave messages on server' + GetMsgs" only.
Quick summary of what are required to enable "expunge after delete at trash folder".

(1) Care on only "Move to trash" and "trash folder" is needed.
    No need to pay attension to Move extension.
    No need to care diference between "Shift+Delete" and "Delete".
(1-1) If "Just mark it as deleted" or "Remove immediately", mail.imap.expunge_after_delete is is irrelevant. No need to care.
(1-2) If MOVE extension is supported, mail.imap.expunge_after_delete is irrelevant to other than trash. If MOVE extension is not supported, mail.imap.expunge_after_delete=true works as designed, as expected.
(1-3) Because of "delete mail at trash", "copy mail to trash step" is not involved. So, "Shift+Delete mail at trash" === "Delete mail at trash".
(2) Windows Explorer like "confirmation dialog" is mandatory
    When "Move to trash" model && mail.imap.expunge_after_delete=true,
    if EXUNGE is issued by "delete mail at trash",
    because copy of the "mail deleted at trash" is not kept,
    "undelete of the delete mail" is impossible.
    So, Windows Explorer like "confirmation dialog" is mandatory.
(3) mail.imap.expunge_after_delete should be "per server setting"
    mail.server.default.imap.expunge_after_delete = true/false in mailnews.js(all accounts)
    mail.server.server#.imap.expunge_after_delete = true/false in prefs.js   (each account)
(4) When "selective EXPUNGE" will be supported in Tb, "selective EXPUNGE" command should be used instead of current EXPUNGE commad which expunges "mail flagged as \Deleted by other IMAP client(s).
(5) "Windows Explorer like confirmation dialog" for "Shift+Delete of mail at IMAP Mbox other than trash" is not needed.
    Because of IMAP, "uid store nn +Flags(\Deleted)" is issued by "Shift+Delete".
    So, "undelete" of any mail is always possible by "uid store nn -Flags(\Deleted)",
    regardless of IMAP delete model choice, unless EXPUNGE operation is invked by someone.
    - Change to "Just mark it as deleted" model.
    - Do undelete for mail which is shown with strike-thru line.
    - Go back to "Move to trash" model, if required for daily use.
(6) If "expunge after delete at trash folder" and "expunge after delete at non trash folder" should be separated, following options are required.
  - mail.server.default.imap.expunge_after_delete          = true/false (all accounts)
    mail.server.server#.imap.expunge_after_delete          = true/false (each account)
  - mail.server.default.imap.expunge_after_delete_at_trash = true/false (all accounts)
    mail.server.server#.imap.expunge_after_delete_at_trash = true/false (each account)
"WONTFIX of bug 624841" is pretty reasonable.
You may be better to open bug for separate enhancement request :
  Enable "expunge after delete at trash folder"

By the way, if Tb issues DELE in POP3, Tb users say "Never issue DELE!!!".
  Many bugs of "Tb's default should be Leave messages on server!!!" were opened.
  Current default of "Leave messages on server"=Checked with "for 14 days" is a compromise.
  If deleted within 14 days, "mbox full at POP3 server" usually won't occur on small Mbox.
And, if Tb doesn't issue EXPUNGE in IMAP, Tb users say "Issue EXPUNGE immediately, always!!!".
User can request any :-)
(In reply to WADA from comment #41)
> (In reply to Ulf Zibis from comment #38)
> > as manually compact Trash sometimes didn't work for some unknown reason (see comment 5).
> 
> It's merely "expunged mails were still shown at Virtual Folder==Search
> Folder==folder which shows search result upon search folder open, isn't it?
No, I had no Virtual Folder defined upon Trash, I just saw the mails "flagged as deleted" still alive in Trash at server via web-mailer after manual Compact on Trash at TB.

> If "mail flagged as deleted in Trash" still kept in mbox named Trash on
> server even after OK response to EXPUNGE command from server, it's merely
> server bug.
That may have been the reason.

> > Hm, what you mean by that?
> What is your acceptable Residence Time of a "mail flagged \Deleted" in Mbox
> of IMAP server?
~1 day       until server daemon purges the Mbox.
10..60 sec.  after Compact, issued from TB user.

> I believe "auto-expunge by auto-compact every several days ~ a few weeks" is
> usually sufficient to avoid "Mbox full of IMAP Mbox".
Yes, if my "lazy" girlfriend would regularly clean up the server Mboxes by web-mailer.
But if "mailbox full" *is reached* after habitual POP3 access, clean up the server Mboxes by web-mailer is hard work. So I configured the additional IMAP access to do this job easier. After deleting several mails in server Inbox with "Move to Trash" model and selectively deleting mails from Trash in several loops, auto-compact isn't triggered often enough, so doesn't help to free space in appropriate time.

> Even when "Mbox full of IMAP Mbox" happens, following is possible;
>   1. change to "Just mark it as deleted",
>   2. confirm that many mails are kept with "mail flagged \Deleted" state in
> an Mbox,
>   3, do Compact or Compact Folders(EXPUNGE command is issued by Tb),
>      (I don't know "Compact Folders" is "compact of all folders of all
> accounts")
>      (or "compact of all folders of currently selected account".            
> )
>   4. change back to "Move to trash" for daily use.
This is too complicated and error-prone for standard users as my girlfriend ;-)
(In reply to WADA from comment #42)
> (2) Windows Explorer like "confirmation dialog" is mandatory
Maybe reuse/adapt existing dialogue from "Empty Trash".

>     When "Move to trash" model && mail.imap.expunge_after_delete=true,
>     if EXUNGE is issued by "delete mail at trash",
>     because copy of the "mail deleted at trash" is not kept,
>     "undelete of the delete mail" is impossible.
With same justification, confirmation dialogue "This action prevents referring UnDo operations" upon Compact is arguable.

>     So, Windows Explorer like "confirmation dialog" is mandatory.
... and could inform: "This action prevents referring UnDo operations"
Because mail.imap.expunge_after_delete=true, contrary to it's name, only affects pseudo-move via copy but not delete itself, I think it would be better, to always display the "confirmation dialogue" and consequentially issue EXPUNGE upon "delete mail at trash" regardless of mail.imap.expunge_after_delete=true. Alternatively, if Delete operation becomes dependent from mail.imap.expunge_after_delete, then please upon mail.imap.expunge_after_delete=false + "Shift+Delete mail at trash" display the "confirmation dialogue" and consequentially issue EXPUNGE.

> (5) "Windows Explorer like confirmation dialog" for "Shift+Delete of
> mail at IMAP Mbox other than trash" is not needed.
Imagine this scenario:
- User is in a hurry and faces "Mailbox full".
- User rapidly selects some messages and uses Shift+Delete.
IMO it would be reasonable to display the "confirmation dialogue" and consequentially issue EXPUNGE, maybe dependent on mail.imap.expunge_after_delete=true.

(7) With "Delete immediately" model, Shift+Delete could provide exceptional "Mark as Deleted", accompanied by a suitable dialogue.
Depends on: 624841
FYI.
About "confirmation on Shift+Delete of message".
It looks already implemented in Tb 24.

Problem in it : It's shown even when "Just mark it as deleted" in IMAP.
It's needed only when Gmail IMAP with auto-expunge=enabled.
If other ordinal/normal IMAP server, "confirmation dialog" is merely a "lie" :-)
Difficulty in it: There is no way to know whether auto-expunge=enabled or enabled.
Why is this not just a duplicate of bug 624841?

If there is an important enough reason to not duplicate this, then the bug should be confirmed. (apologies, but I'm not going to read 48 comments)  Alternatively, if you think it's unclear bug 624841 will fix this (is the problem comment 26), we can leave the dependency and mark it duplicate, and reopen this in future if bug 624841 doesn't fully fix your issue.
Flags: needinfo?(Ulf.Zibis)
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Flags: needinfo?(Ulf.Zibis)
Resolution: --- → DUPLICATE
Duplicate of bug: 624841
You need to log in before you can comment on or make changes to this bug.