0
|
1 test:
|
|
2 - make sure mmap()s work properly with NFS
|
|
3 - make sure locking is done properly when opening/switching modifylog
|
|
4 - make sure SELECT rebuilds index properly when next_uid is near 32bit value
|
|
5 - make sure rfc822_parse_date() works properly
|
|
6 - make sure imap_match functions work properly
|
|
7 - make sure connection limits work
|
235
|
8 - make sure it's noticed by other processes if a) data file is compressed,
|
|
9 b) hash is rebuilt
|
|
10 - make sure the index's ftruncate stuff works
|
|
11 - make sure modify log works properly, especially switching the files
|
0
|
12
|
|
13 index:
|
|
14 - optimization:
|
|
15 - could hash function be better..? like uid*uid? what about changing
|
|
16 probe strategy from linear to something else?
|
|
17 - support shrinking hash file when it becomes 99% empty or so
|
235
|
18 - if first_hole_records == MAIL_INDEX_RECORD_COUNT() -
|
|
19 header->messages_count, we know we can just skip over the hole and do
|
|
20 another direct lookup there
|
|
21 - we could use tree structure to keep track of seqnumbers.. each node
|
|
22 would store how many subnodes it has. deleting nodes (mails) would just
|
|
23 update those counts. this increases the cost of lookups/inserts/deletions
|
|
24 but is faster when more than one hole appears in file.. is it worth it?
|
|
25 maybe #ifdefed away. except we could get rid of the hash file with this
|
|
26 as well, since it could be used to look for both sequences and uids. it
|
|
27 also speeds up UID range lookups when the first UIDs don't exist. use
|
|
28 right-threaded redblack/avl trees (we need to know all child node counts,
|
|
29 does that affect redblack's performance?)
|
0
|
30 - mbox:
|
96
|
31 - if a file isn't valid mbox and it's tried to be opened, say it in one
|
|
32 line in error log, not 6..
|
299
|
33 - locking: if we set shared lock to it while we're accessing it, we could
|
|
34 get it pretty reliable. this means that the mbox fd needs to be locked
|
|
35 before sync() and kept locked after that until we're done with it.
|
|
36 problems are:
|
|
37 - we don't have a single open mbox fd, we open it multiple times
|
|
38 - switching to exclusive lock may deadlock
|
|
39 - because mbox-rewrite rename()s the file, the old file gets lost.
|
|
40 if mailer only checks the fd lock, the new mails disappear..
|
|
41 i guess the only way to fix this is to set dotlock before opening
|
|
42 the mbox file.
|
235
|
43 - maybe support Content-Length for figuring out size of text? at least
|
|
44 mutt doesn't prefix "From " in outbox.. If we verify that both
|
|
45 Content-Length and Lines match correctly, there's quite a little chance
|
|
46 that it could be broken by sending them invalid (doesn't local MTA
|
299
|
47 update them anyway?). Though, this may be a bit difficult to implement,
|
|
48 and now that we verify the From-line better, is this even needed?
|
235
|
49 - rewriting could try to preserve the locations of fields it changes
|
|
50 instead of writing them all to end..
|
|
51 - mbox-rewrite rename()s the file, which breaks if the original was a
|
|
52 symlink. but how do we fix this? we may not have write-access to the
|
|
53 directory where it points to, so we'd need to manually copy it..
|
61
|
54 - read-only support for mailboxes where we don't have write-access? Maybe,
|
|
55 but don't try to use their indexes since that's way too problematic, and
|
|
56 probably even impossible since we can't lock it.
|
235
|
57 - we should try to avoid completely rebuilding indexes unless they're
|
|
58 corrupted. especially if we later want to support some read-only boxes
|
|
59 and keep the mail flags only in index file. fsck() could verify that
|
|
60 records are ok, and that if data file isn't ok the record is deleted.
|
|
61 - if .customflags is removed and Maildir files have custom flags, add
|
|
62 "unknown1" "unknown2" etc. flags to .customflags file for each found flag
|
|
63 - debug: index could be read-only mmaped when it's not locked.
|
299
|
64 - if message text is modified (or indexes are corrupted), this may happen:
|
|
65 Panic: file imap-bodystructure.c: line 179 (part_parse_headers):
|
|
66 assertion failed: (part->physical_pos >= inbuf->offset)
|
0
|
67
|
|
68 lib-storage:
|
|
69 - support multiple mailbox formats and locations for one user. that would
|
|
70 require support for multiple MailStorages, and since we're chroot()ed,
|
|
71 usually the only way to communicate with others would be to create
|
|
72 RemoteMailStorage which would use TCP/UNIX sockets to connect to another
|
|
73 imap session.
|
|
74 - DELETE/RENAME: when someone else had the mailbox open, we should
|
|
75 disconnect it (when stat() fails with ENOENT while syncing)
|
|
76 - optimize SEARCH [UN]SEEN, [UN]DELETED and [UN]RECENT. They're able to
|
|
77 skip lots of messages based on the index header data.
|
|
78 - use a trie index for fast text searching, like cyrus squat?
|
61
|
79 - BUG: hardlink-COPY doesn't work right:
|
|
80 - it should generate new filename for destination folder, so copying
|
|
81 same message twice won't break it
|
|
82 - custom flags aren't copied
|
0
|
83 - maildir: atomic COPY could be done by setting a "temporary" flag into the
|
|
84 file's name. once copying is done, set an ignore-temporary field into
|
|
85 index's header. at next sync the temporary flag will be removed.
|
61
|
86 - we should probably do some light checking that appended mails actually
|
|
87 look like valid rfc822 mails..
|
235
|
88 - SEARCH CHARSET support, iconv()? also means we need to parse the charset
|
|
89 stuff in headers.
|
96
|
90 - SEARCH could optionally support scanning inside file attachments and use
|
|
91 plugins to extract text out of them (word, excel, pdf, etc. etc.)
|
61
|
92 - RENAME INBOX isn't atomic with Maildir. And in general, RENAME can't
|
235
|
93 move mails between different storages. Maybe support doing also using
|
|
94 COPY + delete once COPY is atomic?
|
|
95 - "UID FETCH|SEARCH|STORE *" doesn't work if latest message was deleted.
|
|
96 - maybe limit the length of custom flags? we don't really have a problem
|
|
97 with them, but with mbox a long X-IMAPbase could break something.. Maybe
|
|
98 configurable, default to 50 chars?
|
|
99 - "APPEND invalid data {5}" - says "+ OK" and after that says it's invalid.
|
|
100 that "+ OK" shouldn't be sent by imap-parser if LITERAL_SIZE is used..
|
|
101 - SEARCH should use imap-msgcache, especially for size checking
|
0
|
102
|
|
103 general:
|
|
104 - capabilities:
|
|
105 - acl (rfc2086)
|
|
106 - quota (rfc2087)
|
|
107 - namespace (rfc2342), id (rfc2971), mailbox-referrals (rfc2193),
|
|
108 literal+ (rfc2088), idle (rfc2177), uidplus (rfc2359)
|
|
109 - drafts: listext, children, unselect, multiappend, annotatemore
|
|
110 - sort, thread: are these really useful for clients? do any actually
|
|
111 use them? i'd think most clients want to know all the messages
|
|
112 anyway and can do the sorting/threading themselves.
|
|
113 - http://www.imc.org/ids.html
|
235
|
114 - sieve? (rfc-3028)
|
0
|
115 - rfc-2231 continuation support
|
|
116
|
|
117 - go through .temp files and delete them
|
61
|
118 - Content-Language isn't parsed correctly
|
235
|
119 - ulimit / setrlimit() should be set somewhere for imap process
|
0
|
120 - create indexer binary
|
235
|
121 - SIGHUPing master should reload the configuration .. killing imap-auth and
|
|
122 imap-login processes? or just signal imap-login to stop accepting new
|
|
123 connections and let it kill itself
|
61
|
124 - users should always be able to delete mail from mailbox, even if their
|
|
125 quota is completely full. this would require us to create the indexes
|
|
126 elsewhere .. in-memory should work fine?
|
|
127 - if index was rebuilt (because corruption was noticed), the user should be
|
235
|
128 disconnected because everything might have changed (unless it's noticed
|
|
129 while just opening the indexes).
|
|
130 - settings for specifying what sort of data to cache by default
|
|
131 (index->cache_fields)
|
299
|
132 - setting for choosing mbox locking methods
|
235
|
133 - maybe a bit more verbose warnings for some errors, like "invalid date:
|
|
134 <date that was tried>". easier than sniffing the traffic.
|
|
135 - imap-login writes UTC timestamps to log file .. why is that?
|
|
136 - imap-login leaks I/O descriptors when killed (ssl_input + plain_input)
|
|
137 - logins are always sent now using syslog(), we'd need to have i_info()
|
|
138 or something so they could also be written to log files.. also make it
|
|
139 possible to log into different log than errors.
|
|
140 - should we bother checking if there's invalid 8bit headers in
|
|
141 BODY/BODYSTRUCTURE output and converting them to quoted printable?
|
|
142 - virtual mail which shows up every time we're out of disk space. but how?..
|
|
143 - update docs/index.txt
|
61
|
144
|
|
145 auth / login:
|
0
|
146 - SRP authentication support?
|
61
|
147 - PAM: support some options so /etc/passwd-lookup isn't needed. uid=x, gid=y,
|
|
148 mailroot=/var/mail. maildirs should be then created when needed
|
|
149 - vpopmail support
|
0
|
150 - Digest-MD5: support integrity protection, and maybe crypting. Do it
|
|
151 through imap-login like SSL is done?
|
|
152 - imap-auth should limit how fast authentication requests are allowed from
|
|
153 login processes. especially if there's one login/connection the speed
|
235
|
154 should be something like once/sec. also limit how fast to accept new
|
|
155 connections.
|
61
|
156 - HIGH: support executing each login in it's own process, so if an exploit
|
|
157 is ever found from it, the attacker can't see other users' passwords.
|
|
158 - master should limit number of login processes to max_logging_users,
|
|
159 killing old processes when limit is reached
|
|
160 - master should try to keep login_processes_count extra processes all
|
|
161 the time
|
|
162 - login should notify master after it accept()s, and it must close the
|
|
163 listening socket immediately
|
18
|
164
|
|
165 cleanups / checks:
|
|
166 - grep for FIXME
|
|
167 - check if t_push()/t_pop() should be added somewhere
|
61
|
168 - IOBuffer should probably be split into IBuffer and OBuffer, and maybe
|
|
169 making it's internals hidden .. or at least only partly visible.
|
18
|
170 - io_buffer_fd_ref() .. unref() and destroy() would close if refcount = 0?
|
|
171 annoying those close(inbuf->fd)s with open_mail()..
|
|
172 - allocating readwrite pools now just uses system_pool .. so pool_unref()
|
|
173 can't free memory used by it .. what to do about it? at least count the
|
235
|
174 malloc/free calls and complain if at the exit they don't match
|
61
|
175 - ..wonder what it would look like if I did s/FooBarBaz/struct foo_bar_baz/..
|
|
176 - HIGH: Make sure messages of size INT_MAX..UINT_MAX (and more) work
|
|
177 correctly. virtual_size can also overflow making it less than physical_size
|
|
178 - verify memory alignment is valid when reading from index files
|
96
|
179 - create env_put() and env_clean()
|
235
|
180 - nearest_power() could be problematic with things that want it for ints,
|
|
181 not size_t..
|
0
|
182
|
|
183 optional optimizations:
|
|
184 - provide some helper binary to save new mail into mailboxes with CR+LF
|
|
185 line breaks?
|
|
186 - disk I/O is the biggest problem, so split the mail into multiple computers
|
|
187 based on user and have a proxy in the front redirecting the connection.
|
|
188 cyrus had something like this except a lot more complicated - it tried
|
|
189 to fix the problem of having shared mailboxes. we have the same problem
|
293
|
190 with local shared mailboxes as we don't use same UID for everyone's mail
|
|
191 and we may be chrooted, so locally we could communicate with UNIX sockets,
|
|
192 remotely that could be done with TCP sockets.
|