Closed Bug 107883 Opened 24 years ago Closed 22 years ago

Feature request: Remove from server after x days (POP)

Categories

(MailNews Core :: Networking: POP, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
Future

People

(Reporter: adgraham, Assigned: Bienvenu)

References

Details

Attachments

(1 file, 4 obsolete files)

Feature currently exists to optionally remove mail from POP server once it's been downloaded. Feature request: add a field for number of days to wait before removing from server. This will allow those who use POP accounts to maintain a backup of messages on the server for a set number of days.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm pretty certain this is a duplicate, but I can't find it right now.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
*** Bug 119933 has been marked as a duplicate of this bug. ***
*** Bug 137781 has been marked as a duplicate of this bug. ***
*** Bug 137793 has been marked as a duplicate of this bug. ***
*** Bug 149681 has been marked as a duplicate of this bug. ***
*** Bug 155657 has been marked as a duplicate of this bug. ***
*** Bug 163366 has been marked as a duplicate of this bug. ***
*** Bug 168845 has been marked as a duplicate of this bug. ***
*** Bug 172439 has been marked as a duplicate of this bug. ***
*** Bug 173282 has been marked as a duplicate of this bug. ***
The ability to automatically delete FROM THE POP SERVER after x days is a VERY USEFUL FEATURE. Eudora has had it as long as I can remember (1997 or so), as do Outlook and Outlook Express. Anyone who accesses their mail account from more than one computer can really benefit from this feature. It allows you to retrieve all your mail onto 2 or more machines. (Not to mention providing a safety net if your nightly Mozilla build blows away your mail!) Without it, or another method of removing mail from the server, your POP mailbox will surely eventually fill up. I have to keep an old copy of Eudora around to clean up my inbox. I hope someone will give this one some priority! VOTE FOR THIS BUG!
Blocks: 11055
I concur with Jim Booth. This feature is ESSENTIAL when checking mail on more than one machine (i.e. work and home).
Blocks: 117037
No longer blocks: 117037
*** Bug 194006 has been marked as a duplicate of this bug. ***
Any chance of getting this in before 1.4 is done-and-over-with? If 1.4 is slated to have so many usability and user-friendly improvements in it, this would certainly be one to go with so far as flexibility of mail management goes.
Any chance of getting this useful feature included before the 1.4 series is over? We already have some similar functionality in the Junk Mail controls "Delete Junk Messages over X number of days old". Perhaps the same people could quickly carry over this functionality to deleting messages off of the server? Ken
Requesting
Flags: blocking1.4a?
Flags: blocking1.4a? → blocking1.4a-
*** Bug 200790 has been marked as a duplicate of this bug. ***
I think the junk-mail function to delete a message after x days only works locally , right? Anyway implementing this feature should be of high priority. I have to run sylpheed in the background to do this task right now. We should be able to do it with mozilla i think.
This is a basic functionality that nearly every email program has, whether free or not. This functionality is vital for a person who's requirement is to check his/her mail from two places such as work and home. I emplore whoever might be or potentially might be working on this bug to get it in for 1.4, which will become the stable, kill-all milestone to which many end-user browsers will be based.
Flags: blocking1.4b?
Agree with Kenneth, seriously needed feature.
sorry, not a blocker.
Assignee: naving → sspitzer
Status: ASSIGNED → NEW
Flags: blocking1.4b? → blocking1.4b-
Crap no patch yet. Not much use asking for 1.4 blocking. Let's switch to imap instead. That's what I'm doing (in the mean time, I'm using mutt because it works so much better with large volumes of mail).
Marking HELPWANTED. Maybe someone with the expertise to fix this will see it!
Keywords: helpwanted
*** Bug 209280 has been marked as a duplicate of this bug. ***
Essential and basic feature for all email client.
i think this feature is highly desirable for IMAP folders also (as well as - agreed - POP and local folders)
*** Bug 129244 has been marked as a duplicate of this bug. ***
*** Bug 105824 has been marked as a duplicate of this bug. ***
*** Bug 100059 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
Hooray! We finally made it to 50 votes for this bug! Adding this bug to Bug 163993 - [META] Mozilla Bugs with Large Community Interest. Hopefully someone with the ability to fix this will notice it now!
Yes, but will anybody? I thought the need for this feature should have been obvious from the start, if only for the sake of achieving feature parity with Eudora (Eudora 2.1, that is). And yet the target milestone remains "future." Is this a difficult feature to add? How hard is this? (I don't mean to ask the question in a "how hard can it be?" way; I'm genuinely curious as to what's kept this feature on the to-do list.)
I wanted to add a comment to this; we would be using Netscape exclusively at our organization, but our set-up requires that we leave email on the server for 7 days. It is not possible without this feature, and so many competitive email programs have it; Outlook, Eudora, OE. Thanks
taking; this would be a very useful feature. It's not too hard to implement. The easiest thing would be to put a time stamp in popstate.dat, so that we could then just iterate through it occasionally and delete messages older than XX days. That might require rev'ving the popstate.dat file because I think we'd break forward compatibility (i.e., a popstate.dat file with timestamps in it might break older clients).
Assignee: sspitzer → bienvenu
Attached patch work in progress (obsolete) — Splinter Review
this adds a couple server prefs for aging messages from pop3 server after XX days, and adds a date field to popstate.dat, so we can tell how old messages are. Remaining work is to write a method that iterates over the uidl hash table and marks for deletion messages older than XX days, if the server pref is set. I believe that the old popstate.dat code will deal with the new files, so we don't need to change the file name or anything (it will lose the dates, however...)
I'm not sure if this matters or not, but how will this deal with the inevitabl messages that are dated incorrectly? Sometimes I receive valid emails that are dated a week, or even a few years, behind time. I have a filter set to move all messages that are >8 days old to an 'Archive' folder. There are occasions that I have to go back and dig through there to find a valid email. (I say valid, because most emails I receive this way are spam.)
I'm storing the time the message was downloaded to your computer, and ignoring the dates in the message completely. So, basically, the message will be removed from the server XX days after you download it.
Attached patch proposed fix (obsolete) — Splinter Review
this patch should work - it has the account setting sui for configuring the number of days to keep msgs on server, and marks messages for deletion in popstate.dat when they were downloaded more than XX days.
Attachment #130320 - Attachment is obsolete: true
Attachment #130339 - Flags: review?(scott)
Comment on attachment 130339 [details] [diff] [review] proposed fix very cool david. I take it you have a pop server you were able to test against? Only one minor nit which wasn't even yours since it is just from a line you changed the indenting on: + if (info->uidl && m_pop3ConData->only_uidl == NULL) that can just be && !m_pop3ConData->only_uidl Gotta pick something so you know I actually read the patch =).
Attachment #130339 - Flags: review?(scott) → review+
yes, my ISP only has POP3, so I use it exclusively for my personal mail.
this patch (which just contains the diffs for nsPop3Protocol.cpp) addresses Scott's comment, and fixes a problem in the original patch where we were crunching the timestamp in popstate.dat.
turned out we were leaking uidl infos - latest patch to nsPop3Protocol.cpp fixes that.
Attachment #130466 - Attachment is obsolete: true
Another vote of support for this feature. Very annoying when working between home and office that Mozilla Mail doesn't provide this feature. The 'delete when moved out of inbox' approach isn't as intuitive a solution. I see that some patches have been submitted - when can we expect a version with this feature built in?
Another vote of support for this feature. Very annoying when working between home and office that Mozilla Mail doesn't provide this feature. The 'delete when moved out of inbox' approach isn't as intuitive a solution. I see that some patches have been submitted - when can we expect a version with this feature built in?
when the tree opens for 1.6 development, I'll check this in. That should be sometime in the next week, I believe. I'm not sure when this will be in Thunderbird. Perhaps for .3
Oh well, no chance for this in 1.5 then? *sigh* Been desperately after this for a while. We've got a shared account that's POP3 only (for the moment), and we're having to get all the Moz clients with "leave mail on server", and have 1 person use something else to clear the old mail... 'tis not good! Another vote for this bug from me.
Just to concur, this feature is essential. I just voted for it, though I'm not sure if that matters now that it's being worked on? Another related feature that (at least) Eudora has is "Delete from Server" as an option for the mail filters. I've searched through the existing bugs, and that seems possibly related to 89034, but I'm not sure. Should I open a new bug/RFE for this?
IMO : bug 89034 it's just what You (and me:]) want. Please vote for it :)
Ideally, it would be nice for this setting to support decimal days (ie hours). Like other people here I check the same account from multiple machines. One of these machines though is a cell phone so I would also like to have the email that's still on the POP server to be kept to a minimum because of the phone's slow transfer rate. It would be nice to be able be able to specify .2 days (5 hours).
Attached patch complete fixSplinter Review
this is the whole patch for Seth's sr.
Attachment #130339 - Attachment is obsolete: true
Attachment #130958 - Attachment is obsolete: true
fix checked in, r/sr=mscott.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
This patch broke something severely, see bug 219188 !
fix is in bug 219188 - if this patch gets applied to TB .3, you'll need the additional patch in that bug
I have a question about this new feature. What happens to mail that was allready left on server before this got implemented? Does this delete only mail that was downloaded (and is older then XX days) after the feature was added or does it also delete any other mail from the server (and was downloaded before this patch has been checked in) that is more then XX days old? Thanks for the answers.
@ comment 53 answering first question: the mail got left on the server indefinitely.
mail already downloaded before this feature landed still has to wait XX days from when you first run the version of the program that has this feature. The reason is that we now store the date downloaded in popstate.dat, but we weren't before. If we load a popstate.dat that doesn't have dates downloaded, we use Now() as the date downloaded.
will this work for IMAP folders too?
no, it's strictly pop3. There is a bug out there for aging messages away from imap folders, I believe
Blocks: 219336
Is this issue supposed to be 'resolved fixed'? Last comments regarding the code fix says that it severely broke something else...
I'm running version 1.5, dated 20031007, and it doesn't have the "Remove from server after x days" option for my POP accounts. If this is fixed but only via patch, then at what point will the fix be built in to the mozilla code? (I'm not clear on the big-picture process here.)
it's in 1.6, the current daily trunk builds. 1.6a is coming out any day now.
This feature incorrectly deleted almost all of my mail! I have my account set to "at most 10 days". I retrieved my mail with Mozilla and then rechecked my account with pine. Only the messages sent within the last few *minutes* were left. I have just filed this as bug 224711.
(In reply to comment #55) > mail already downloaded before this feature landed still has to wait XX days > from when you first run the version of the program that has this feature. The > reason is that we now store the date downloaded in popstate.dat, but we weren't > before. If we load a popstate.dat that doesn't have dates downloaded, we use > Now() as the date downloaded. This would be good if it worked this way. But it is not true. When I installed 1.6 all existing messages in popstate.dat got NEGATIVE timestamps. It was not now. Or there is some integer overflow... (Win98) All new messages got correct times. Then, of course those messages appeared (maybe years) old to Moz. I suppose bug 224711 is real and I am moving there because I had similar problems too.
Product: MailNews → Core
*** Bug 208428 has been marked as a duplicate of this bug. ***
v.
Status: RESOLVED → VERIFIED
Keywords: helpwanted
No longer blocks: majorbugs
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: