195605 - automatic delete mail directly from Junk mail folder after the given number of days, don't put messages into Trash folder

Status: NEW

(MailNews Core :: Filters, enhancement)

Description

[Andreas Otte]

It would be nice to have an option to really delete junk mail after the given
number of days and not have them moved into the Trash Folder. That step is
unnecessary in my opinion. If a mail does not get rescued from Junk during the
given number of days then just delete them for good and be done.

Comment 1

[Patrick]

TOOLS - JUNK MAIL CONTROLS - AUTOMATICALLY DELETE JUNK MESSAGES OLDER THAN .. DAYS

[not using this feature myself, so i'm not sure if this feature is fully
functional, but the UI definitely is already there.]

PS : reporter, please provide more information next time, such as the Mozilla
build your using and things you already tried. You can use the Bugzilla helper
for that.

Comment 2

[Andreas Otte]

1. I'm using 1.3b and trunk builds (If that makes sense for an RFE)
2. I used the option you described (I thought my text made that clear), I just
want it to behave differently or have an option to let it behave differently

Comment 3

[Patrick]

Andreas : 
1) I think the UI for junk mail was implemented gradually. Therefore it might
[have] be[en] possible that your Moz build didn't have this feature yet whereas
a more recent nightly WOULD have it. In that way, knowing ones build number is
always useful, even for an RFE. [for example you're using Moz 1.0 and ask for
junk mail filters]

2) I guess the confusion started with the wording. The current wording on the
panel seemed to tie nicely in with your request : as both talk about "delete
junk". But if i understand your report correctly you see two things:
- the wording of the current Junk Mail Controls panel is wrong "automatically
delete junk messages older than XXX days from this folder" should read
""automatically move junk messages older than XXX days to Trash" ? Because
currently it moves it to Trash first?
- the enhancement request : skip the "move junk to trash" but "delete junk" ?

Comment 4

[Andreas Otte]

Basically yes. Currently when the option is switched on, deleting (as with every
other folder except trash) means "move to trash folder", only in the trash
folder itself "deleting" means really "deleting". In that way the current uitext
is consistent with every other delete operation. But regarding deleting in my
opinion there is not much difference (infact there is none) between trash and
junk so I would like to have an additional option to activate real deletion for
the junk folder too.
 

Comment 5

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

for imap, we'll follow your imap delete model.

(mark as deleted, move to trash, or delete immediately)

for local, we'll just move to trash.

so, the reporter is right, we don't give the user the option to "delete immediately"

accepting, but futuring.

Comment 6

[Tomas Drbohlav]

*** Bug 201346 has been marked as a duplicate of this bug. ***

Comment 7

[Tomas Drbohlav]

Because I've marked 201346 as a dup fo this one, I move the idea here: imho junk
delete should behave in different way that traditional delete (which seems to be
slighlty strange).

When user choose 'move to the junk folder', it should delete the source message,
do real move, not traditional 'move to the trash' which duplicates the message.

Comment 8

[Howard Chu]

(In reply to comment #7)
> Because I've marked 201346 as a dup fo this one, I move the idea here: imho junk
> delete should behave in different way that traditional delete (which seems to be
> slighlty strange).
> 
> When user choose 'move to the junk folder', it should delete the source message,
> do real move, not traditional 'move to the trash' which duplicates the message.

MailNews never does a real move/real delete because frequently such an operation
requires rewriting the entire mailbox. Otherwise, I agree with you that it
should behave this way. See bug #213636, which addresses this Delete behavior.

Comment 9

[Howard Chu]

Attachment: Adds "Delete Immediately" preference

This patch adds a new radio control to the Junk Mail Controls dialog - "When I
delete Junk messages:"
  1) move them to the Trash folder OR
  2) delete them immediately

This preference does not affect the regular DeleteMsg command, but it does
affect these other mechanisms that delete Junk:
  if you set "When I manually mark messages as Junk -> Delete them"
  if you run Tools -> Delete Mail marked as Junk in Folder

Comment 10

[Howard Chu]

Attachment: Fix unint'd var in prev patch

Same as before, just makes sure to initialize junkDelete in nsMsgDBView.cpp

Comment 11

[Howard Chu]

Attachment: wrong patch, sigh

Dang it. Forgot to trim out the other junk from the previous patch. Sorry for
all the noise.

Comment 12

[Howard Chu]

Attachment: Added Purge as well

This patch also includes the "purge after XX days" feature.

Comment 13

[Aaron Kaluszka]

*** Bug 213504 has been marked as a duplicate of this bug. ***

Comment 14

[Mike Cowperthwaite]

Howard Chu -- you should ensure that your patch still applies to the current 
codebase.  Also, you'd probably get more attention if you provided front end 
changes for Thunderbird as well.

Then, when you ask for a review, you need to specify a reviewer -- that's 
probably why this has lain untouched for as long as it has.  Probably the best 
reviewer would be: [e-mail]

Comment 15

[Mike Cowperthwaite]

*** Bug 256709 has been marked as a duplicate of this bug. ***

Comment 16

[Howard Chu]

(In reply to comment #14)
> Howard Chu -- you should ensure that your patch still applies to the current 
> codebase.  Also, you'd probably get more attention if you provided front end 
> changes for Thunderbird as well.
> 
> Then, when you ask for a review, you need to specify a reviewer -- that's 
> probably why this has lain untouched for as long as it has.  Probably the best 
> reviewer would be: [e-mail]

Thanks, I'd pretty much forgotten about this patch. I guess I assumed since the
bug was assigned to someone (Seth) that they would do the first review.

I don't use Thunderbird, so any UI patches I provide would be written blind,
without any idea of how they really look. Since I just heard that Mozilla 1.8
will never be released (???) I guess it's somewhat of a moot point.

Comment 17

[Howard Chu]

Attachment: refreshed, new UUID

diff against fresh source tree

Comment 18

[David :Bienvenu]

Comment on attachment 177897 [details] [diff] [review]
refreshed, new UUID

sr=bienvenu - however, we need a corresponding change to the thunderbird
junkMail.dtd, which lives in mail/locales/en-US/chrome/messenger

Comment 19

[David :Bienvenu]

I think the junk mail controls UI for this is a bit confusing, if I'm
understanding everything correctly. This setting doesn't control what happens
when I select a junk message and press delete, which is what the UI implies - it
controls what happens when junk mail is purged, or deleted via "delete mail
marked as junk in folder", or what happens if I have the "delete msg when
manually marked as junk" option set. I think the backend behaviour is what I'd
want - it's just that the UI wording for specifying that isn't precise. I'm not
sure what wording would be better. Maybe something like "When junk mail is
automatically deleted"...

I'll go get this working in thunderbird while we think of some better wording
for the UI.

Comment 20

[David :Bienvenu]

Attachment: thunderbird patch

this patch works with thunderbird. Howard, you should look at this because I
had to change the js slightly, and I think you need the same change in your
patch, replacing deleteJunk with deleteJunkMode...

Comment 21

[Howard Chu]

(In reply to comment #20)
> Created an attachment (id=178370) [edit]
> thunderbird patch
> 
> this patch works with thunderbird. Howard, you should look at this because I
> had to change the js slightly, and I think you need the same change in your
> patch, replacing deleteJunk with deleteJunkMode...

You're right, after it gets disabled it doesn't get reenabled because it's the
wrong name. I'll fix my patch and change the UI text to match yours.

Comment 22

[Howard Chu]

Attachment: Same as 177897, fix typo and label text

Comment 23

[Pierre Couderc]

(In reply to comment #19)
I think that the problem is not only a question of UI, it is simply that it is
boring to use Junk functions : 3 actions
1- Mark it Junk when received : it goes to Junk folder
2- delete it from Junk folder: it goes to Trash folder
3- delete it from trash folder
When operation 2 is done (manually or not), the junk mail should not go to Trash
folder but be delted immediately. Junk folder should be considered not as
another kind of folder, but as another kind of Trash folder.

Comment 24

[Howard Chu]

(In reply to comment #23)
> I think that the problem is not only a question of UI, it is simply that it is
> boring to use Junk functions : 3 actions
> 1- Mark it Junk when received : it goes to Junk folder
> 2- delete it from Junk folder: it goes to Trash folder
> 3- delete it from trash folder
> When operation 2 is done (manually or not), the junk mail should not go to Trash
> folder but be delted immediately. Junk folder should be considered not as
> another kind of folder, but as another kind of Trash folder.

Yes, that sounds pretty tedious. I would have actually preferred to have it
deleted both manually and not, but for reasons I don't remember I didn't get
that to work. But really, I don't see any reason to use a Junk folder at all. My
junkmail comes into my Inbox. I go through and toggle any additional messages
that the filter didn't automatically detect, then hit Tools/Delete Junk Mail in
Folder and it's all gone. What's the point of saving it anyway?

Comment 25

[Pierre Couderc]

(In reply to comment #24)


>... But really, I don't see any reason to use a Junk folder at all...
I let Junk mail go from Inbox to Junk folder automatically, and I declare
manually as Junk the junk mail not found by the Junk detector.
Fom time to time, I review quickly the Junk Folder to detect errors in case of
mail wongly declared Junk, then I empty it and it goes to... Trash folder!
I prefer to check myself once because I fear that myself make the mistake to
declre wrongly Junk a not-Junk mail.

Comment 26

[Ralph Hartley]

> Junk folder should be considered not as
> another kind of folder, but as another
> kind of Trash folder.

I agree. I consider the junk folder to be *lower* than the trash folder. My
trash folder contins things like appointment reminders that I (rarely) need to
see again, I never delete mail from there.

The junk folder contains mail automatically (or manually) clasified as spam.
Each message needs to be hand checked *once* (mostly I only need to see the
header, so I can do blocks all at once) and then absolutely destroyed. 

I need to select a block of messages in the junk folder and make them go away
forever. The few legit messages there, I mark not junk and then move to my
inbox, or to the trash.

I am now totally confused about what this patch does. Does it let me do what I
want or not?

If it does, even in a *slightly* roundabout way, fine.

Could I let the filter place spam in my junk folder, check to make sure there
are no legit messages there (marking them as read to keep track) and then delete
junk from folder to distroy them all?

Messages never seen by my eyes should always be preserved.

If the patch does not permit the distruction of *exacly* those messages I decide
should be distroyed, I need to file a new bug.

> I don't see any reason to use a Junk folder at all.
> My junkmail comes into my Inbox. I go through and
> toggle any additional messages that the filter didn't
> automatically detect, then hit Tools/Delete Junk Mail
> in Folder and it's all gone. What's the point of saving
> it anyway?

Two reasons:

1) It gets it out of my way immediately. I don't want to deal with junk every
time I read my mail.

2) Checking to make sure it is all junk is much faster if it is all together,
not mixed with current mail or legitimate trash. Typically my junk has
characteristic headers. I can expand the message list pane, and check whole
blocks at a time.

Comment 27

[Howard Chu]

Any more action here? The patches were reviewed and all set to go but if any
more time passes they're likely to break/fail to apply as the source tree
continues to change.

Comment 28

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 178398 [details] [diff] [review]
Same as 177897, fix typo and label text

So I'm wondering if there's some solution to this that doesn't involve adding
even more UI widgetry and preferences, since there is already quite a bit of
both.

Comment 29

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #28)
> (From update of attachment 178398 [details] [diff] [review] [edit])
> So I'm wondering if there's some solution to this that doesn't involve adding
> even more UI widgetry and preferences, since there is already quite a bit of
> both.
> 

In particular, one possibility would be to simply always treat the Junk folder
as a second Trash folder.

Comment 30

[Tuukka Tolvanen (sp3000)]

(In reply to comment #29 (also suggested in comment 23))
> In particular, one possibility would be to simply always treat the Junk folder
> as a second Trash folder.

I disagree with that idea -- personally, I use automatic move to Junk folder, so
Junk is an incoming folder for probably-spam messages; it gets manually scanned
occasionally. Trash-like semantics, not to mention associated bugs (bug 209189
(msf corruption), bug 132121 (dataloss)) on the Junk folder would be unwelcome.

Comment 31

[Pierre Couderc]

(In reply to comment #30)
> > In particular, one possibility would be to simply always treat the Junk folder
> > as a second Trash folder.
> 
> I disagree with that idea -- personally, I use automatic move to Junk folder, so
> Junk is an incoming folder for probably-spam messages; it gets manually scanned
> occasionally. Trash-like semantics, not to mention associated bugs (bug 209189
> (msf corruption), bug 132121 (dataloss)) on the Junk folder would be unwelcome.
Mmm,I use too automatic move to Junk, and manual occasionnal check, and I see no
interest to be obliged after deleting from Junk to delete again from Trash.
The fact that some bugs remain on Trash does not change the theoric approach,
but these bugs and the fact that some people work different ways, suggest that
this could be an option ("Put deleted from Junk to Trash or Delete immediately")

Comment 32

[Tuukka Tolvanen (sp3000)]

(In reply to comment #31)
> Mmm,I use too automatic move to Junk, and manual occasionnal check, and I see no
> interest to be obliged after deleting from Junk to delete again from Trash.

see, that's a job for "empty trash on exit" :) This could go on forever, though
-- some people actually want to store things in trash over sessions, which seems
like a failure of the "familiar objects" principle <grin/>. I wonder if they
would be better served by e.g. labels and autorun filters (e.g. filter all
labeled as 'bah' to 'graveyard', filter all >14d old in 'graveyard' to 'trash',
and empty 'trash' on exit)... That is, I'd rather like to see various usage
patterns supported by tool-features like that rather than munging the semantics
of the base set of objects. Not that I'll die over one more pref or anything :\

Comment 33

[Howard Chu]

(In reply to comment #32)
> (In reply to comment #31)
> > Mmm,I use too automatic move to Junk, and manual occasionnal check, and I see no
> > interest to be obliged after deleting from Junk to delete again from Trash.
> 
> see, that's a job for "empty trash on exit" :) This could go on forever, though
> -- some people actually want to store things in trash over sessions, which seems
> like a failure of the "familiar objects" principle <grin/>. I wonder if they
> would be better served by e.g. labels and autorun filters (e.g. filter all
> labeled as 'bah' to 'graveyard', filter all >14d old in 'graveyard' to 'trash',
> and empty 'trash' on exit)... That is, I'd rather like to see various usage
> patterns supported by tool-features like that rather than munging the semantics
> of the base set of objects. Not that I'll die over one more pref or anything :\

I'd like to see autorun filters too (bug 59365, bug 294632) but we don't have
those yet, and it's a lot more work to get there. But you're missing some of the
point - "empty trash on exit" is an option, it is not enabled by default, and
not everyone uses it. Yes, this could probably go on forever...

At this point I'm in favor of the "Junk folder is a Trash folder" approach. But
I would still add this refinement - if no Junk folder is specified, then
Deleting Junk equals Delete Immediately.

The fact that bug 132121 and bug 209189 are looming out there affects all local
mail folders; that is really orthogonal to this discussion and I don't think
it's appropriate to consider here.

Comment 34

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

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 35

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 36

[Wayne Mery (:wsmwk)]

does this fit in to anyone's newer thinking on junk processing?

Comment 37

[Wayne Mery (:wsmwk)]

Comment on attachment 178370 [details] [diff] [review]
thunderbird patch

David, review is now up to you? :)

almost forgot why I came here - clearing sr? mscott

Comment 38

[Bryan Clark (DevTools PM) [:clarkbw]]

I agree with Dan (Comment #29) that Junk should be treated just like another type of trash folder.   I would switch to an immediately delete from Junk.

I'm not sure why we should offer a delete that moves junk mail into the trash folder at all.  That would tend to make the Trash folder harder to use.  Initially the trash folder is a staging area for items specifically deleted that you may want to get back.  Once you move all your junk mail into the trash folder you now have a lot of messages you don't want to get back littering the trash folder.

The Junk folder is supposed to be the staging area for false positives and training mistakes.  Once a person has decided to remove the junk mail they shouldn't need to remove it again.

I'd recommend changing to a similar set of interactions for the Junk folder that the trash folder has.

Comment 39

[Pierre Couderc]

No need to comment now 5 other years, just a good will to do it...

Comment 41

[Wayne Mery (:wsmwk)]

aleca, do you agree with previous UX owner we should do this (comment 38)? If so I think we should do this for next release.

Slightly complicating factor, not necessarily blocking, is Bug 318897 - need keep messages in trash and junk for a N days starting at the time of deletion - otherwise deleted mail cannot be recovered from Trash if trash's retention policy is auto-delete messages older than xx days

Comment 42

[Alessandro Castellani [:aleca]]

Indeed, the Junk/Spam folder should be handled like the trash folder, meaning if the user deletes a message that is in the Junk folder, it gets deleted immediately without passing through the Trash folder.

I don't see the relation with Bug 318897, sorry, could you elaborate?

Comment 43

[Wayne Mery (:wsmwk)]

If this bug is fixed and Bug 318897 is not fixed ... then if today I mark a message dated Sept 1 as junk, then very next retention pass (every 6 hours? I forget) will delete the message even though I only recently marked only as junk.

I'm not suggesting Bug 318897 is a prerequisite to fixing this bug, but a nice to have. Trash folder of course already has the same issue, and people are living with it.

Comment 44

[Alessandro Castellani [:aleca]]

All right, that makes sense.
I'll try to work on this later next week, and after it lands, I'll move to Bug 318897

Comment 45

[Anje]

Hi Alessandro, If you are working on this could you please take a look at bug 1673176