684593 - Feature Request: Super-Delete Filter Action

Status: RESOLVED DUPLICATE of bug 160021

(Thunderbird :: General, enhancement)

Description

[Asher Densmore-Lynn]

User Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110815 Iceweasel/3.5.16 (like Firefox/3.5.16)
Build ID: 20110815153231

Steps to reproduce:

Sometimes my mailbox is filled up with automated messages. I've got a manual filter I run whenever I get a flood of these, but it never works correctly on its own.


Actual results:

Deleting a message actually copies it to the Trash, and if the mailbox is no longer accepting new messages then the copy fails and so the delete fails.

To make it work correctly, I have to open the mailbox settings and set deletions to happen instantly, and then rerun the filter -- and God save me if I delete anything before I put it back. Assuming I remember to.



Expected results:

I'd like a new Super-Delete target for rules that will ignore any retention settings in the account -- anything it targets is *gone*, no copies, no saving, whether local or remote it's just not there anymore. This would limit my exposure to dangerous account settings to the minimum necessary to unjam my mailbox.

Comment 1

[Hashem Masoud]

(In reply to Asher Densmore-Lynn from comment #0)
I tried to find a setting in the configuration editor but couldn't find anything related to this http://kb.mozillazine.org/Mail_and_news_settings . I'm changing this to enhancement.

Comment 2

[Asher Densmore-Lynn]

I have to protest, Hashem. "Deletions don't work when the mailbox is not accepting new mail" -- I'm not sure that's only enhancement-level. I can't delete messages if the mailbox is full unless I make (and later reverse) dangerous and risky configuration changes.

Granted, I proposed a quickie feature (which would only apply to rule-based deletions) because I thought it was the lowest impact change that would work around the bug, but if you'd rather I can refile it as a bug sans suggestion.

Comment 3

[Jim Porter (:squib)]

In any case, this is a duplicate of bug 160021, so marking as such.