mirror of
https://git.code.sf.net/p/archivemail/code
synced 2024-12-22 07:42:55 +00:00
3e0288e21b
- documentation of IMAP server side search peculiarities
- Debian bug #255944, which has been recorded as unreproducible, and fixed
in rev. 186.
82 lines
3 KiB
Text
82 lines
3 KiB
Text
Add IMAP tests to the testsuite (upload test messages with IMAP "APPEND
|
|
date-string").
|
|
|
|
Check sf.net and Debian BTS for new bugs.
|
|
|
|
Port to email.message and the new mailboxes in Python 2.5.
|
|
|
|
Add recursive archiving of mail subfolders?
|
|
|
|
Line out what we want with respect to multiple selection criteria.
|
|
Some make sense, but this easily gets too complex, and if only it's a hassle
|
|
with adding all the options. Hm.
|
|
|
|
Reject patch #1036022 "Added option to inverse date compare" after cooling down
|
|
because the patch is both stupid (copy+paste code) and broken. Don't see why
|
|
anyone should want this/we should support it.
|
|
If this is reasonable *at all*, I think we'd better go for all the complexity
|
|
to honour _two_ cut off dates (see Debian bug "#184124: archivemail: -D and -d
|
|
should not be incompatible", which is a comparably half-baken thought). </rant>
|
|
|
|
Add --debug or -vv switch, and move the printing of diagnostic info for each
|
|
message to --debug.
|
|
|
|
Perhaps add some more nice stuff like printing of subject, sender...
|
|
See tracker #868714 "added stats option to archivemail", which has a point.
|
|
Message-Ids are useful for diagnosis, but not very nice to read for humans.
|
|
|
|
Regarding the --archive-name option:
|
|
* Do we want this? Probably, it adds flexibility.
|
|
* I think we should expand date format strings like we do with --suffix
|
|
* Hmm, --output-dir overrides os.dirname(archive_name)...
|
|
If no output_dir is given, use $PWD like we do for IMAP, or require -o?
|
|
* Provide short option -a? Not sure.
|
|
* The patch in #905657 is not bad. The Debian package also has a custom
|
|
--archive-name option, but with a worse implementation.
|
|
|
|
Be a nicer citizen with respect to mailbox locking.
|
|
|
|
Perhaps prune/shorten IMAP mailbox URLs in messages?
|
|
They may be quite long and may contain the sensitive password.
|
|
Also shows up in the process list...
|
|
Perhaps find a clean, lean replacement for all that clutter in the IMAP urls.
|
|
|
|
Require --output-dir for IMAP archiving? Otherwise we just drop the archive in
|
|
in the current working directory.
|
|
|
|
Switch to fcntl(2) locking? That would be NFS-safe. Perhaps make the locking
|
|
method configurable?
|
|
|
|
Check all items below, which are from the original author. :-)
|
|
|
|
.archivemailrc support
|
|
|
|
Specify an option to not seteuid() when run as root?
|
|
|
|
When you get a file-not-found in the 6th mailbox of 10, it aborts the whole
|
|
run. Better to fail gracefully and keep going.
|
|
|
|
Think about the best way to specify the names of archives created with
|
|
possibly an --archive-name option.
|
|
|
|
Add more tests (see top of test_archivemail.py)
|
|
|
|
We need some better checking to see if we are really looking at a valid
|
|
mbox-format mailbox.
|
|
|
|
Lock any original .gz files
|
|
- is this necessary?
|
|
|
|
Check for symlink attacks for tempfiles (although we don't use /var/tmp)
|
|
|
|
Add an option to not cut threads.
|
|
|
|
Add MMDF mailbox support
|
|
|
|
Add Babyl mailbox support
|
|
|
|
Add option to archive depending on mailbox size threshold
|
|
- is this a good idea?
|
|
|
|
Add option to archive depending on number of messages
|
|
- is this a good idea?
|