Menu
▾
▴
archivemail-devel — Discussions about archivemail development
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(13) |
Nov
(11) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(4) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(7) |
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
(22) |
Dec
(3) |
| 2008 |
Jan
(8) |
Feb
|
Mar
(5) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
(11) |
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
(6) |
Nov
(1) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(12) |
Sep
(5) |
Oct
(6) |
Nov
(1) |
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
(2) |
Jul
(10) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(10) |
Nov
(4) |
Dec
|
|
From: SourceForge.net <no...@so...> - 2010-08-09 11:00:09
|
Bugs item #2882023, was opened at 2009-10-20 00:11 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2882023&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Kriston Rehberg (kriston) >Assigned to: Nikolaus Schulz (nikosch) Summary: Delete messages marked with dates that are in the future Initial Comment: Archivemail detects messages whose dates are in the future but does not delete them. Since these are universally invalid the program should delete them, or offer an option to delete messages with dates in the future. ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2010-08-09 13:00 Message: When an email has no Delivery-Date header, archivemail 0.8.0 now reads and prefers the Received header over the Date header. That should fix this problem. Please comment if it doesn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2882023&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2010-08-09 10:53:13
|
Patches item #1874868, was opened at 2008-01-18 17:58 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1874868&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Tim O'Donnell (tim_odonnell) Assigned to: Nikolaus Schulz (nikosch) Summary: Allow writing to world-writable directory with sticky bit Initial Comment: Current behavior: If the destination directory is world-writable, halt. New behavior: If the destination directory is world-writable, then proceed only if the directory's sticky bit is set. Rationale: If the destination directory is world-writable with the sticky bit set, then only the user who owns the archived file (or the owner of the directory) can delete it. From the user's perspective, it's equivalent to the directory not being world-writable, so there's no need for concern. I'm including an svn diff of the quick change. If you'd like this another way, just let me know. Thanks! Tim ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2010-08-09 12:53 Message: archivemail 0.8.0 does no longer bail out when the destination directory is world-writable, and /tmp works just fine. Not that in order to do this safely, there are some new security checks, which disallow symlinked target files. ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2008-01-19 01:57 Message: Logged In: YES user_id=1594781 Originator: NO I do not feel comfortable applying this patch. archivemail's file operations are quite sloppy, it uses high-level utilities (the shutil module) and thereby pretty much trusts its environment. Actually, I think archivemail needs be fixed here, but it is not trivial. As matters stand, there are at least two potentially raceable spots: when archivemail reads an already existing archive, and when it writes the new archive. Consider this example: the destination directory is a sticky /tmp, no archive exists yet. archivemail starts, archiving to a safe temporary file. Note that the environment variables $TMPDIR, $TEMP, and $TMPDIR all override /tmp as a place for temporary files. Now when archivemail's done, it first tries to rename the tempfile to the final destination, which is safe, albeit not entirely without problems (it silently overwrites an existing archive, which you might just be reading, if it already existed before). But this e.g. fails if the temporary file and /tmp are not on the same filesystem; in this case, archivemail essentially does a 'cp -p <tempfile> <dest>', which follows symlinks! So an attacker could easily drop a symlink in /tmp and cause archivemail to overwrite the link target. Similarly, an attacker can inject any file's content into the archive when archivemail tries to read an existing archive in /tmp. So, until this sloppiness is fixed, I prefer to leave the current check alone. One might argue, of course, that it's not smart to try to stop the user from doing dangerous things like that. But then, I think it makes more sense to remove the entire check than to special-case the /tmp scenario. Nikolaus ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1874868&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2010-08-09 10:49:16
|
Bugs item #855269, was opened at 2003-12-06 12:08 Message generated for change (Settings changed) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=855269&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Karl Chen (quarl) Assigned to: Nikolaus Schulz (nikosch) Summary: need an option to skip procmail_lock Initial Comment: To operate on mboxes in e.g. $MAIL=/var/mail/$USER, you can't use procmail locks (/var/mail/$USER.lock) since you don't have write permission to that directory. Since procmail doesn't write there either, this should be allowed via a command-line option (or even automatically detect if directory is not writeable by user) ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2010-08-09 12:49 Message: archivemail 0.8.0 skips dotlocking if it hasn't sufficient privileges to create the dotlock file. ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2007-11-09 04:08 Message: Logged In: YES user_id=1594781 Originator: NO Okay, I see this is a problem. As far as I know procmail *does* dotlocking in /var/mail. I am not an overall Unix wizard, but on my Debian boxes, /var/mail is writeable for group mail, and there exist several utilities for dotlocking, all of which are setgid mail. The mailbox module in python 2.5 does indeed just skip dotlocking, if the program has no write permissions. Of course that's not really ideal. :-) archivemail could search for known dotlocking utilities and try to acquire a dotlock with their help... I have to think about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=855269&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2010-08-09 10:48:01
|
Bugs item #2043900, was opened at 2008-08-09 14:47 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2043900&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Andrey Rahmatullin (wrar) Assigned to: Nikolaus Schulz (nikosch) Summary: mtime tests fail with python 2.5 Initial Comment: ====================================================================== FAIL: mbox timestamps should not change after semi-archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 713, in testMixed self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9247789 != 1218285951.924777 ====================================================================== FAIL: mbox timestamps should not change after no archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 690, in testNew self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9328034 != 1218285951.932802 ====================================================================== FAIL: mbox timestamps should not change after archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 736, in testOld self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9367993 != 1218285951.936799 ---------------------------------------------------------------------- ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2010-08-09 12:48 Message: Closing all artifacts that are fixed in archivemail 0.8.0. ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2008-10-26 15:42 Message: Fix committed to git-svn, will make it in archivemail 0.8.0 ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2008-08-15 11:44 Message: Logged In: YES user_id=1594781 Originator: NO Okay, I can reproduce the test suite failure with xfs, and the odd 1ms timestamp skew. Thanks for the links, that was very useful. There is no real fix for this problem, I'll simply have to make the timestamp check in the test suite less strict, let it be by rounding or by disabling floating timestamps at all as per os.stat_float_times(). It seems that the next POSIX standard will address the lacking precision of utimes(2) by adding the futimens(2) system call; futimens(2) is already implemented in Linux 2.6.22 and glibc 2.6. But of course, speaking about Python, that buys us nothing. ---------------------------------------------------------------------- Comment By: Andrey Rahmatullin (wrar) Date: 2008-08-14 19:38 Message: Logged In: YES user_id=884799 Originator: YES I use Linux and XFS. I've asked about this problem some time ago and received some interesting answers. You can see the thread in Russian at http://lists.altlinux.org/pipermail/devel/2008-March/071387.html (especially http://lists.altlinux.org/pipermail/devel/2008-March/071492.html). Here are some ideas from that thread: 1. stat(2) uses nanoseconds, while utimes(2) uses milliseconds, so utimes(2) loses precision less than millisecond. 2. os.path.getmtime + os.utime sometimes loses 1ms. You can see the testcases at the provided links. ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2008-08-14 13:39 Message: Logged In: YES user_id=1594781 Originator: NO That's interesting. I'm just learning about this; which operating system and which file system are you using? Does your system support the utimes(2) system call? I *think* Python should be able to restore the exact timestamp with utimes(2), if it is available, although the Python documentation nebulously warns that os.utime() might fail to set precise timestamps. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2043900&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2010-08-09 10:46:18
|
Bugs item #2210732, was opened at 2008-10-31 00:33 Message generated for change (Settings changed) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2210732&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: tlhackque (tlitt) Assigned to: Nobody/Anonymous (nobody) Summary: archivemail not preserving selinux security context Initial Comment: under selinux, archivemail writes to a temporary file, which it then renames to the output file. Unfortuneatly, this process leaves the output file labeled with a tmp_t security context instead of that of the input file (usually user_u:object_r:user_home_t). This is not a good thing. ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2010-08-09 12:46 Message: archivemail 0.8.0 no longer updates mboxes by renaming a temporary file, so this shouldn't happen anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2210732&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2010-08-09 10:44:02
|
Patches item #2210707, was opened at 2008-10-31 00:24 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=2210707&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 6 Private: No Submitted By: tlhackque (tlitt) Assigned to: Nobody/Anonymous (nobody) Summary: archivemail needs to preserve IMAP dummy message Initial Comment: archivemail will happily delete the dummy message that IMAP servers place in mbox files to keep track of the next UID. This isn't the end of the world, but it is mildly unpleasant. This simple patch will preserve this message. (A more rigorous implemention might ensure that this is the first message in the file.) Enjoy, --tlhackque at nospam.yahoo.com --- /usr/share/archivemail/archivemail.py~ 2007-06-14 11:57:39.000000000 -0400 +++ /usr/share/archivemail/archivemail.py 2008-10-30 18:23:16.000000000 -0400 @@ -981,20 +981,25 @@ # I could probably do this in one if statement, but then I wouldn't # understand it. if not old: return 0 if not options.include_flagged and is_flagged(message): return 0 if options.min_size and is_smaller(message, options.min_size): return 0 if options.preserve_unread and is_unread(message): return 0 + """TL: Do not remove IMAP header message""" + imaphdr = message.get('X-IMAP') + if imaphdr : + vprint("Message is an IMAP mailbox header ('%s')" % imaphdr) + return 0 return 1 def is_older_than_time(time_message, max_time): """Return true if a message is older than the specified time, false otherwise. Arguments: time_message -- the delivery date of the message measured in seconds since the epoch ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2010-08-09 12:44 Message: Feature implemented in archivemail 0.8.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=2210707&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2010-08-09 10:43:00
|
Patches item #2783134, was opened at 2009-04-28 21:39 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=2783134&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Kevin A. McGrail (kmcgrail) Assigned to: Nobody/Anonymous (nobody) Summary: Patch: Root Disable Seteuid Option Initial Comment: I needed to disable the root seteuid functionality so I wrote the attached patch. ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2010-08-09 12:43 Message: archivemail 0.8.0 removes the setuid feature entirely, so this no longer applies. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=2783134&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2010-08-09 10:40:38
|
Feature Requests item #604281, was opened at 2002-09-04 03:10 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=604281&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: Devin Bayer (mal0rd) Assigned to: Brandon Knitter (knitterb) Summary: fix dots at beginning of file Initial Comment: When backing up subdirs of a Maildir (which begin with a dot) the resultant archive begins with a dot, making it invisible. Please don't save files that begin with a dot; instead chop the dot off. ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2010-08-09 12:40 Message: Fixed in archivemail 0.8.0. ---------------------------------------------------------------------- Comment By: Scott Kuhl (skuhl) Date: 2004-09-11 05:30 Message: Logged In: YES user_id=941561 I don't know where documentation on the maildir structure is, but in general, if a mailbox starts with a dot, you should probably just strip off that dot in the archive name. I'm no python coder, but here is a patch that works good enough for me (this patch could very well break something that I'm missing). In version 0.6.1 this patch applies to around line 999: --- archivemail 2002-10-30 16:54:55.000000000 -0700 +++ /home/skuhl/bin/archivemail 2004-09-10 21:25:30.000000000 -0600 @@ -999,7 +999,8 @@ if mailbox_name[:7].lower() == 'imap://': final_archive_name = mailbox_name.split('/')[-1] + parsed_suffix else: - final_archive_name = mailbox_name + parsed_suffix + stripped_dot = re.sub("^\.", "", os.path.basename(mailbox_name)) + final_archive_name = os.path.dirname(mailbox_name) + stripped_dot + parsed_suffix if options.output_dir: final_archive_name = os.path.join(options.output_dir, os.path.basename(final_archive_name)) ---------------------------------------------------------------------- Comment By: Brandon Knitter (knitterb) Date: 2003-10-29 03:46 Message: Logged In: YES user_id=11101 If there are folders with a dot and without a dot (say in IMAP), a simple removal of the dot could have an unforseeable impact. I'm not familiar with maildir completely. Can you provide documentation on fht maildir structure? Sorry, I'm just taking this project over. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=604281&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2010-08-09 10:40:12
|
Feature Requests item #1306538, was opened at 2005-09-28 08:35 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=1306538&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: option for archive base name Initial Comment: how about an option to set the base portion of the archive filename so that it doesn't have to be the same as the input filename? this would be useful when archiving email out of a /var/mail/ username into ~username/INBOX.%Y_%m for example. ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2010-08-09 12:40 Message: Feature implemented in archivemail 0.8.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=1306538&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2010-08-09 10:37:34
|
Patches item #1918937, was opened at 2008-03-19 00:36 Message generated for change (Settings changed) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1918937&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Christian (chrisbra) Assigned to: Nobody/Anonymous (nobody) Summary: recursively archive all mails from an imap server Initial Comment: Hi, I thought, it would be nice, if archivemail could automatically archive messages from all folders in an imap server. This could for example be used for migrating all mails from one imap-server to another server. Attached is my first try to achieve this. I am not sure, how stable it is, especially the naming of the final archive could probably be improved and I am not sure how well this works with other imap servers beside cyrus, with which I've tested it. Greetings, C.Brabandt ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2010-08-09 12:37 Message: Feature implemented in archivemail 0.8.0. ---------------------------------------------------------------------- Comment By: Christian (chrisbra) Date: 2008-03-19 22:13 Message: Logged In: YES user_id=1928606 Originator: YES Oh well, that was what I meant with "...especially the naming of the final archive could probably be improved..." (without that line all messages would be archived into the same archive, which is probably not what would be expected, so I thought of a way to add the folder. This was a quick and dirty solution to create a new archive for each folder without adding too much complexitiy by refactoring the code for determining the final_archive_name. I was not sure how else to create an appropriate name for each subfolder. May be one can find a much better solution. Perhaps one can simply append the folder name to final_archive_name, of course the folder_name must at least be matched against "/" which needs to be replaced. Besides I noticed one probably needs to change the way, how the subfolders are determined. So this line: result, response = imap_server.list() should probably take the submitted folder_name into account, like this: result, response = imap_server.list(folder_name+"*") to take into account that the use only wants the subfolders below the one he specified and not all subfolders that exist. So I see your point, and the patch was kind of a starting point which I created quickly yesterday ;) Thanks for your comments, I'd obviously like to see this feature implemented ;) regards, Christian ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2008-03-19 21:02 Message: Logged In: YES user_id=1594781 Originator: NO Hm, okay, I see that this can be convenient. I'm not convinced that it's worth adding more complexity and yet another option to archivemail, though... I would expect that typically, mailboxes are pretty static objects; you don't create them often or move them around a lot, so the benefit of recursive archiving seems pretty small. By the way, this has already been requested a long time ago before I was involved with archivemail, but the tracker was closed by the maintainer for some reason, see Feature request #649607. Finally, can you please explain the following line from your patch? final_archive_name = "INBOX" + folder.replace("INBOX","") + o_fan.replace("INBOX","") First, this looks like you're assuming that all folders are below INBOX, which need not be the case. Also, one would have to catch if 'folder' in the assignment contains slashes. But leaving that aside, I don't understand it. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1918937&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2010-08-09 10:34:13
|
Feature Requests item #1978540, was opened at 2008-05-30 02:02 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=1978540&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nikolaus Schulz (nikosch) Summary: Archive _all_ imap folders Initial Comment: I've seen that there's a recursive patch in the patch section (which I haven't tried). I have, at the moment, 236 IMAP folders nested in various ways. They are organized in such a way that I don't have to spend much time thinking about where things are. While I certainly could just iterate a list of them all firing off archivemail on each one independently, it would be rather nice if I could just ask archivemail to visit every folder in a single invocation. ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2010-08-09 12:34 Message: Fixed in archivemail 0.8.0. ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2008-10-26 15:34 Message: Recursive archiving of IMAP folders has already been requested, see tracker item #1918937, which proposed a (rather suboptimal) patch. As I've stated there, I have been reluctant to add yet another feature and option, but I've changed my mind a little bit; archivemail could support IMAP wildcards. Especially there would be no need for a special option. But postponed for now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=1978540&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2010-08-08 16:38:27
|
Patches item #905657, was opened at 2004-02-27 07:55 Message generated for change (Settings changed) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=905657&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Aidant (wtfoguru) Assigned to: Nobody/Anonymous (nobody) Summary: Added --archive-name option Initial Comment: This was rudimetary addition, since my python skills were non-existant before this patch, and I waited very patiently. :) Anyway it works for me, and I did make a test for in the unit test file. Cheers, Jim ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2010-08-08 18:38 Message: OK, I've meanwhile managed to find the mentioned patch. An alternative implementation is in git and will make it into the 0.8 release. ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2010-07-30 22:56 Message: No patch here, and there exists a similar feature request #1306538, therefore I'm closing this as invalid. ---------------------------------------------------------------------- Comment By: Aidant (wtfoguru) Date: 2006-05-10 04:59 Message: Logged In: YES user_id=234456 I must have forgot to attach it. I'll try again. And if you are using a fc1 - fc4 you can downlaod a rpm that has the patch allready applied. http://mirrors.aidant.org/aidant/fedora/1/en/i386/RPMS.aidant/archivemail-0.6.1-3.fc1.ae.noarch.rpm http://mirrors.aidant.org/aidant/fedora/2/en/i386/RPMS.aidant/archivemail-0.6.1-3.fc2.ae.noarch.rpm http://mirrors.aidant.org/aidant/fedora/3/en/i386/RPMS.aidant/archivemail-0.6.1-3.fc3.ae.noarch.rpm http://mirrors.aidant.org/aidant/fedora/4/en/i386/RPMS.aidant/archivemail-0.6.1-3.fc4.ae.noarch.rpm http://mirrors.aidant.org/aidant/source/archivemail-0.6.1-3.ae.src.rpm ---------------------------------------------------------------------- Comment By: Y Def (ydef) Date: 2006-05-10 01:05 Message: Logged In: YES user_id=1443602 Doesn't work for me because there doesn't seem to be a place to download this patch. Did you forget to make it available for download? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=905657&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2010-07-30 20:57:01
|
Patches item #905657, was opened at 2004-02-27 07:55 Message generated for change (Settings changed) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=905657&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Aidant (wtfoguru) Assigned to: Nobody/Anonymous (nobody) Summary: Added --archive-name option Initial Comment: This was rudimetary addition, since my python skills were non-existant before this patch, and I waited very patiently. :) Anyway it works for me, and I did make a test for in the unit test file. Cheers, Jim ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2010-07-30 22:56 Message: No patch here, and there exists a similar feature request #1306538, therefore I'm closing this as invalid. ---------------------------------------------------------------------- Comment By: Aidant (wtfoguru) Date: 2006-05-10 04:59 Message: Logged In: YES user_id=234456 I must have forgot to attach it. I'll try again. And if you are using a fc1 - fc4 you can downlaod a rpm that has the patch allready applied. http://mirrors.aidant.org/aidant/fedora/1/en/i386/RPMS.aidant/archivemail-0.6.1-3.fc1.ae.noarch.rpm http://mirrors.aidant.org/aidant/fedora/2/en/i386/RPMS.aidant/archivemail-0.6.1-3.fc2.ae.noarch.rpm http://mirrors.aidant.org/aidant/fedora/3/en/i386/RPMS.aidant/archivemail-0.6.1-3.fc3.ae.noarch.rpm http://mirrors.aidant.org/aidant/fedora/4/en/i386/RPMS.aidant/archivemail-0.6.1-3.fc4.ae.noarch.rpm http://mirrors.aidant.org/aidant/source/archivemail-0.6.1-3.ae.src.rpm ---------------------------------------------------------------------- Comment By: Y Def (ydef) Date: 2006-05-10 01:05 Message: Logged In: YES user_id=1443602 Doesn't work for me because there doesn't seem to be a place to download this patch. Did you forget to make it available for download? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=905657&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2009-11-01 02:22:19
|
Bugs item #2823652, was opened at 2009-07-18 18:33 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2823652&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Warning - changing effective user id Initial Comment: python 2.4.3-24 archivemail 0.7.2 archivemail: Warning - changing effective user id: this automatic feature is deprecated and will be removed from later versions. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-11-01 02:22 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2009-10-17 22:17 Message: This is not a bug. The warning tells people who are using this feature that they should better do without it, because it will be removed in the future. There was some noise on the user mailing list when this warning was introduced, but that was all settled, because running archivemail as the appropriate user is the obvious fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2823652&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2009-10-19 22:11:35
|
Bugs item #2882023, was opened at 2009-10-19 18:11 Message generated for change (Settings changed) made by kriston You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2882023&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kriston Rehberg (kriston) Assigned to: Nobody/Anonymous (nobody) >Summary: Delete messages marked with dates that are in the future Initial Comment: Archivemail detects messages whose dates are in the future but does not delete them. Since these are universally invalid the program should delete them, or offer an option to delete messages with dates in the future. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2882023&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2009-10-19 22:11:14
|
Bugs item #2882023, was opened at 2009-10-19 18:11 Message generated for change (Tracker Item Submitted) made by kriston You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2882023&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kriston Rehberg (kriston) Assigned to: Nobody/Anonymous (nobody) Summary: Delete dates that are in the future Initial Comment: Archivemail detects messages whose dates are in the future but does not delete them. Since these are universally invalid the program should delete them, or offer an option to delete messages with dates in the future. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2882023&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2009-10-17 22:40:48
|
Bugs item #2818156, was opened at 2009-07-07 21:05 Message generated for change (Settings changed) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2818156&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Jonathan Ciesla (limburgher) >Assigned to: Nikolaus Schulz (nikosch) Summary: Not processing message Initial Comment: archivemail 0.72 isn't seeing this message, which is apparently in a non-ISO charset. ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2009-10-18 00:40 Message: Works like a charm here... please followup if you can reproduce the bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2818156&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2009-10-17 22:26:42
|
Bugs item #2852449, was opened at 2009-09-05 19:28 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2852449&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 2 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: Docs don't say that only POSIX platforms are supported Initial Comment: I was experimenting to see if I could get archivemail 0.7.2 working on windows. I installed the standard windows pythin 2.6 and did the archivemail install. When I tried to run archivemail, it said ImportError: no module named fcntl I'm really not too surprised. When I saw in the documentation that it usses flock(), that might not work on windows. But, the documentation said to report ImportError's, so I am. Guess I'll see if I can get it working under cygwin. Thanks! ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2009-10-18 00:26 Message: archivemail runs on POSIX platforms only. OK, I have to admit that the official documentation is quiet about portability, so one could expect it to work on your OS. :-) I guess I should add a note about that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2852449&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2009-10-17 22:17:34
|
Bugs item #2823652, was opened at 2009-07-18 20:33 Message generated for change (Settings changed) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2823652&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Warning - changing effective user id Initial Comment: python 2.4.3-24 archivemail 0.7.2 archivemail: Warning - changing effective user id: this automatic feature is deprecated and will be removed from later versions. ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2009-10-18 00:17 Message: This is not a bug. The warning tells people who are using this feature that they should better do without it, because it will be removed in the future. There was some noise on the user mailing list when this warning was introduced, but that was all settled, because running archivemail as the appropriate user is the obvious fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2823652&group_id=49630 |
|
From: Julien C. <jul...@gm...> - 2009-10-17 00:45:16
|
Dear all I just discovered archivemail today, great tool, thanks to all contributors ! I have encountered a bug for which I propose here a patch with the laster revision (285) on the repository -- sorry, not much familiar with sourceforge, hence not sure where to post (is the tracker still alive / watched ?) Bug: when fetching from an IMAP server which supports NAMEPSACE and whose prefix ends with the delimiter (example: prefix="INBOX." and delimiter="."), archivemail does not allow to fetch the topmost folder (example, here, the INBOX itself). The enclosed patch is such that the topmost folder is fetched when the folder name asked is either empty, or the prefix, or the prefix deprived from its final delimiter. I am not familiar with IMAP namespaces, hence I do not know if it common practice for the prefix to end with the deliniter. This is the case of my uninversity's, hence I dealt with it. Could anybody please tell me if the patch is worth being committed, possibly with modifications, and in that case where to post it to this intent ? (I am not a Python wizard, kinda dirty coding) Thanks, Best regards, -- Julien Cornebise, Ph.D. Postdoctoral Fellow, SAMSI http://www.stat.duke.edu/~jc250/ |
|
From: SourceForge.net <no...@so...> - 2009-09-05 17:28:44
|
Bugs item #2852449, was opened at 2009-09-05 17:28 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2852449&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError on windows: No module named fcntl Initial Comment: I was experimenting to see if I could get archivemail 0.7.2 working on windows. I installed the standard windows pythin 2.6 and did the archivemail install. When I tried to run archivemail, it said ImportError: no module named fcntl I'm really not too surprised. When I saw in the documentation that it usses flock(), that might not work on windows. But, the documentation said to report ImportError's, so I am. Guess I'll see if I can get it working under cygwin. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2852449&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2009-07-18 18:33:25
|
Bugs item #2823652, was opened at 2009-07-18 18:33 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2823652&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Warning - changing effective user id Initial Comment: python 2.4.3-24 archivemail 0.7.2 archivemail: Warning - changing effective user id: this automatic feature is deprecated and will be removed from later versions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2823652&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2009-07-07 19:05:10
|
Bugs item #2818156, was opened at 2009-07-07 14:05 Message generated for change (Tracker Item Submitted) made by limburgher You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2818156&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Ciesla (limburgher) Assigned to: Nobody/Anonymous (nobody) Summary: Not processing message Initial Comment: archivemail 0.72 isn't seeing this message, which is apparently in a non-ISO charset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2818156&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2009-04-28 19:39:22
|
Patches item #2783134, was opened at 2009-04-28 15:39 Message generated for change (Tracker Item Submitted) made by kmcgrail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=2783134&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kevin A. McGrail (kmcgrail) Assigned to: Nobody/Anonymous (nobody) Summary: Patch: Root Disable Seteuid Option Initial Comment: I needed to disable the root seteuid functionality so I wrote the attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=2783134&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-10-30 23:33:13
|
Bugs item #2210732, was opened at 2008-10-30 19:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2210732&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: tlhackque (tlitt) Assigned to: Nobody/Anonymous (nobody) Summary: archivemail not preserving selinux security context Initial Comment: under selinux, archivemail writes to a temporary file, which it then renames to the output file. Unfortuneatly, this process leaves the output file labeled with a tmp_t security context instead of that of the input file (usually user_u:object_r:user_home_t). This is not a good thing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2210732&group_id=49630 |
1 message has been excluded from this view by a project administrator.
