Mercurial > dovecot > core-2.2
annotate TODO @ 1250:31510fc5e02f HEAD
updates
| author | Timo Sirainen <tss@iki.fi> |
|---|---|
| date | Mon, 24 Feb 2003 21:38:09 +0200 |
| parents | 6fd1f2e82c9a |
| children | ccb430d3b945 |
| rev | line source |
|---|---|
| 1178 | 1 - we need permanent storage for UIDs. with mbox use X-UID like UW-IMAP, |
| 2 with maildir a) file:2,flags,Uuid b) file,U=uid:2,flags. uid validity | |
| 3 would be in .uidvalidity file. the b-case would require that to be done | |
| 4 by the client moving it from new/ to cur/ | |
| 5 | |
| 6 - DELETE/RENAME: when someone else had the mailbox open, we should | |
| 1211 | 7 disconnect it (when stat() fails with ENOENT while syncing). |
| 1178 | 8 |
| 526 | 9 - bugs |
| 10 - maildir: if mail file isn't found, it may be because it was renamed | |
| 11 (flag changed). we must then sync the directory and see again if the mail | |
| 12 is found | |
| 725 | 13 - SIGHUP didn't update imap_listen. this is a bit annoying to fix though, |
| 1178 | 14 since new listen() may fail for a few times because login processes may |
| 725 | 15 not die immediately.. |
| 860 | 16 - SIGHUP doesn't update log file location. |
| 1178 | 17 - CREATE a, CREATE b, save mails into them, DELETE a, RENAME b a. |
| 18 -> breaks if a+b have same UIDVALIDITY. We could update the | |
| 19 UIDVALIDITY for the renamed mailbox and all mailboxes under it. | |
| 20 Then return with tagged "OK [NEW-UIDVALIDITY 1234] Renamed". Assuming | |
| 21 other IMAP people agree to that. | |
| 526 | 22 |
| 23 - reliability fixes: | |
| 1250 | 24 - maildir: check if there's base name conflicts when syncing. the hash |
| 25 could also be built against index.data so it'd take less memory | |
| 605 | 26 - if we deleted mail from index but didn't write modify log, other |
| 27 dovecots don't handle it properly. they either assert at index-sync.c:42 | |
| 28 or if new mails have also been added since, they don't notice it at all | |
| 526 | 29 actually, that breaks reads as well since we get expunges only from |
| 30 the old file.. and check that deleting file does "inconsistency error" | |
| 31 - if imap process notices that both modify logs are getting full because | |
| 32 it's client isn't syncing, the client should be disconnected | |
| 725 | 33 - we don't handle out of memory conditions too well, malloc failing kills |
| 34 the process which is good enough (and likely never happens), but mmap() | |
| 35 failures aren't handled too well. Rather should be handled in similiar | |
| 36 way to locking failures, so that at least we don't try to rebuild the | |
| 37 index because of it. | |
| 860 | 38 - limit folder hierarchy levels? user can now create eg. a/a/a/a/... |
| 39 and then start renaming them from end to beginning, which probably will | |
| 40 at some point start causing syscall failures which will fill up logs. | |
| 795 | 41 - fsck should check binary tree |
| 474 | 42 |
| 1211 | 43 - mbox |
| 1250 | 44 - message_parse_header() skips headers (even multiline) larger than max. |
| 45 input buffer size, which in our case means that headers larger than | |
| 46 8192 bytes will be silently skipped when saving mails. | |
| 1211 | 47 - Optimize rewrites by using empty spaces after X-Keywords |
| 48 - Move data within file instead of writing it to temp file. We can now do | |
| 49 moving easily with o_stream_send_istream(). | |
| 50 - if a file isn't valid mbox and it's tried to be opened, say it in one | |
| 51 line in error log, not 6.. | |
| 52 - When expunging the first message we could move the X-IMAPbase header | |
| 53 to next message to avoid full rewriting later. | |
| 54 - We shouldn't send X-IMAPbase, Status, X-Status, X-Keywords, X-UID, etc. | |
| 55 headers to client - they may change and clients must see messages as | |
| 56 immutable. Create istream-filter and use it. | |
| 57 - two adjacent From-lines breaks us. not too easy to fix though. | |
| 58 - Handle UW imapd's "DON'T DELETE THIS MESSAGE" message. | |
| 59 | |
| 526 | 60 - checks: |
| 61 - if we have entries in modifylog with UID 10..11, 9..12, 8..13 etc. | |
| 62 do they work correctly? | |
| 63 - make sure SELECT rebuilds index properly when next_uid is near 32bit value | |
| 64 - make sure connection limits work | |
| 1178 | 65 - check that both header and envelope address writer produce same output |
| 1211 | 66 - check if some asserts should be changed into if/i_panic code, so that |
| 67 disabling asserts would be possible | |
| 526 | 68 |
| 69 - enhancements: | |
| 852 | 70 - option to disable SORT, SEARCH and other memory/cpu-intensive features. |
| 1211 | 71 defaults and per-user by dovecot-auth. |
| 537 | 72 - when fetching body/envelope/etc we could try to cache it immediately if |
| 526 | 73 we can get lock with try_lock. |
| 74 - maildir could support also the dirty-flag in messages. files would be | |
| 75 renamed "whenever there's time" (that'd require the indexer program, or | |
| 76 forking and doing it in background) | |
| 77 - optionally keep the message file name as it's UID. Then we don't have to | |
| 78 save the filename anywhere. | |
| 537 | 79 - send EXISTS immediately after new mail arrives. |
| 605 | 80 - linux: we can use dnotify for maildir (but not mbox I think, we'd |
| 81 get interrupted all the time if we checked eg. large /var/spool/mail) | |
| 537 | 82 - *bsd: kqueue() can notify changes in mbox and maildir |
| 1250 | 83 - .subscriptions and .customflags needs nfs-safe locking |
| 634 | 84 - OpenSSL: support generated DH parameters |
| 1250 | 85 - SSL: Support password protected key files. Support reading the password |
| 86 from user at runtime (dovecot startssl or something). | |
| 725 | 87 - multiline headers can cause our memory usage to go up. that should be |
| 88 fixed somehow. try to change things to be able to handle one line at a | |
| 89 time? Well, other IMAP servers have same problem - post 1.0 problem. | |
| 90 - check with strace what dovecot does when evolution checks new mail, | |
| 91 it's quite a lot. some things probably wouldn't need to be done | |
| 92 (mkdirs/symlinking inbox) and other things could be cached in memory. | |
| 795 | 93 - sort: we could create alternative binary tree file(s) for different sort |
| 94 conditions, ".tree-sort" or something. sort code itself already supports | |
| 95 this optimization. | |
| 852 | 96 - tree file: should we instead use b+-tree or something similiar? or at |
| 97 least try to do some defragmentation with it, so that the root nodes | |
| 98 would be kept at the beginning of the file. | |
| 99 - use vsftpd-like safebufs, ie. keep non-rwx page before and after the | |
| 100 memory we want to use. | |
| 101 - mmap_anon() | |
| 102 - mmap()ing files would probably need to first go through anon_mmap() | |
| 103 and then use MAP_FIXED. annoying that it slows the mmaping.. | |
| 104 - data stack should use mmap_anon() | |
| 892 | 105 - option: copy /var/mail/$user to INBOX when logged in. nice for not missing |
| 106 any mails with quota enabled | |
| 965 | 107 - support zlib compressed mbox/maildir? mbox maybe just read-only. |
| 108 - THREAD=ORDEREDSUBJECT - although pretty useless I'd think. | |
| 1178 | 109 - sql authentication and mail database support. create some generic lib-sql |
| 110 which both can use | |
| 1250 | 111 - maildir: change it to use '/' as hierarchy separator to allow '.' |
| 112 characters (for usernames in shared folders) | |
| 965 | 113 |
| 114 - logging | |
| 1250 | 115 - Login: username 1.2.3.4:1025 5.6.7.8:993 imaps,compressed |
| 116 - Logout: username 1.2.3.4:1025 5.6.7.8:993 imaps,compressed in:1000 out:1000000 | |
| 117 - n failed login attepts (before failure or success, once in n seconds) | |
| 605 | 118 |
| 119 - lib-charset: | |
| 634 | 120 - utf8_toupper() is a must. and a bit difficult if we want to do it right. |
| 605 | 121 - add support for other things than iconv() as well? we could reuse |
| 122 the code from cyrus or courier | |
| 795 | 123 - cache iconvs? they'd probably be faster if we just reset the |
| 124 conversion instead of opening new one every time. and there will likely | |
| 125 be only one or two charsets which are used for nearly all conversions. | |
| 526 | 126 |
| 852 | 127 - should we allow following symlinks in mbox/maildirs? they are now. |
| 1250 | 128 - if we implement shared mailboxes with shared indexes, never do that or |
| 129 others could symlink your personal mailboxes and see the indexes | |
| 130 created for it which may contain envelope etc. data | |
| 131 - this allows circular mailbox hierarchies which should be prevented by | |
| 132 eg. allowing max. 20 hierarchies. | |
| 852 | 133 |
| 1250 | 134 - index: |
| 135 - we could try compressing same from/to/subject fields into a single | |
| 136 location in data file. requires larger changes.. | |
| 137 - read-only support for mailboxes where we don't have write-access | |
| 138 - we should try to avoid completely rebuilding indexes unless they're | |
| 139 corrupted. especially if we later want to support some read-only boxes | |
| 140 and keep the mail flags only in index file. fsck() could verify that | |
| 141 records are ok, and that if data file isn't ok the record is deleted. | |
| 142 - if .customflags is removed and Maildir files have custom flags, add | |
| 143 "unknown1" "unknown2" etc. flags to .customflags file for each found flag | |
| 144 - skipping deleted records in .imap.index would be faster if we saved the | |
| 145 deleted block size to first/last record, so we could just jump over them. | |
| 146 - support storing message headers into indexes. this could be useful when | |
| 147 indexes are in local disk but actual mails are accessed through NFS | |
| 148 - we could send flag changes after all commands by making expunge/flags | |
| 149 sync counters separate for modify log. flags would need to update the | |
| 150 seq though, too slow? | |
| 151 - if we wanted to support huge mailboxes with small memory usage, it'd now | |
| 152 be possible if we just instead of mmap()ing the whole index files would | |
| 153 have maybe 3-4 256k mmap()ed areas which we move based on the need. | |
| 154 - should work fine with .imap.index and .imap.index.data | |
| 155 - log files aren't affected by mailbox size | |
| 156 - if the tree file also kept constantly moving the nodes so that | |
| 157 tree's root was at the beginning of the file, we could use this mmap | |
| 158 caching with it too | |
| 159 - but, is it worth the trouble really? the OS can do all this itself, | |
| 160 only thing we're doing is keeping the processes virtual memory usage | |
| 161 small. | |
| 0 | 162 |
|
376
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
163 - SEARCH: |
| 1250 | 164 - message_body_search() could accept multiple search keywords so we |
| 165 wouldn't need to call it separately for each one (so we wouldn't need | |
| 166 to parse the message multiple times). | |
| 167 - message_body_search() could support NULL MessagePart and the searching | |
| 168 could be done while parsing the message. this would need changes to | |
| 169 message_parse() as well. | |
| 170 - could optionally support scanning inside file attachments and use | |
| 171 plugins to extract text out of them (word, excel, pdf, etc. etc.) | |
| 172 - use a trie index for fast text searching, like cyrus squat? | |
| 173 - Create our own extension: When searching with TEXT/BODY, return | |
| 174 the message text surrounding the keywords just like web search engines | |
| 175 do. like: SEARCH X-PRINT-MATCHES TEXT "hello" -> * SEARCH 1 "He said: | |
| 176 Hello world!" 2 "Hello, I'm ...". This would be especially useful with | |
| 177 the above attachment scanning. | |
| 0 | 178 |
| 1250 | 179 - general: |
| 180 - sieve (rfc3028), we can use Cyrus Sieve | |
| 181 - rfc2231 continuation support | |
| 182 - rfc2557 support for BODYSTRUCTURE, as specified by latest IMAP4rev1 draft | |
| 183 - lmtp server | |
| 184 - create indexer binary | |
| 185 - support Maildir++ quota | |
| 186 - provide some helper binary to save new mail into mailboxes with CR+LF | |
| 187 line breaks? | |
| 188 - some kind of IMAP proxy for load distributing | |
| 189 - maybe give more untagged NO/ALERT replies? like when mailbox is in | |
| 190 inconsistent state. and when UIDs are reordered because they're too | |
| 191 large. | |
| 192 - imap/ and lib-imap/ should allow infinite number of custom flags, it's | |
| 193 storage's problem if it can't handle too many of them. | |
| 194 - things calling message_send() could verify that it wrote enough data. | |
| 195 if not, fill the rest with spaces and return failure. -1 = error, | |
| 196 0 = filled, 1 = ok. | |
| 18 | 197 |
| 1250 | 198 - cleanups: |
| 199 - check if t_push()/t_pop() should be added somewhere | |
| 200 - try to fix @UNSAFE code to use buffer API instead | |
| 201 - subscription-file.c, custom_flags, ioloop | |
| 202 - [io]stream-file.c? | |
| 203 - grep for FIXME | |
| 204 - index/create_temp_file is used in only two places. once mbox rewriting | |
| 205 doesn't need it, get rid of it. | |
| 0 | 206 |
| 1250 | 207 - auth / login: |
| 208 - kchuid, SRP, anonymous SASL | |
| 209 - Digest-MD5: support integrity protection, and maybe crypting. Do it | |
| 210 through login process like SSL is done? | |
| 211 - for invalid user/pass, wait for a while before giving a reply to user | |
| 212 - dovecot-auth should limit how fast authentication requests are allowed from | |
| 213 login processes. especially if there's one login/connection the speed | |
| 214 should be something like once/sec. also limit how fast to accept new | |
| 215 connections. | |
|
376
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
216 |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
217 capabilities: |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
218 - preferrably all should be possible to #ifdef away by a configure |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
219 option (--without-capabilities=acl,namespace,...) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
220 - possibility to disable them from config file |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
221 - acl (rfc2086, draft-ietf-imapext-acl), namespace (rfc2342) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
222 - probably do it like cyrus. "user.<username>" to access other |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
223 users, with "" defaulting to "user.<myself>". these should be |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
224 configurable however. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
225 - shared namespaces? maybe configurable in config file |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
226 - easiest way to do ACL would be to use unix modes, but is that |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
227 useful at all? Well, ACL2 has a bit better support for that, so |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
228 maybe we could support it. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
229 - otherwise gets a bit trickly, we could keep all mail in "imapmail" |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
230 group and 0600/0700 mode by default, but when mail is shared to others, |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
231 the group read/write access bits would be set. or alternatively we |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
232 could launch another imap process to handle it, which we should support |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
233 anyway. ACLs could be stored into ".acl" ascii file in each folder. |
| 480 | 234 - support for private and shared flags, configurable by mailbox admin. |
| 235 this isn't in any draft yet, but ACL2 author was going to create one. | |
| 236 [SHAREDFLAGS (...)] would specify which ones are shared, don't know yet | |
| 237 how they would be configured. | |
|
376
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
238 - quota (rfc2087, draft-cridland-imap-quota) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
239 - give filesystem values only to admins |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
240 - support for Maildir++, probably no need to support more. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
241 quota capability supports complex quota configuration, but if |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
242 no mailer supports them we probably shouldn't bother either |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
243 - id (rfc2971) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
244 - must be configurable what gets sent, default to only name=Dovecot |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
245 - separate pre/post-login settings |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
246 - optionally log configured parts of the client information, but only |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
247 once, probably at the same time as logging "Logged in", |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
248 "Disconnected", etc. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
249 - remember to force truncating values longer than 30 chars, |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
250 especially before logging |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
251 - mailbox-referrals (rfc2193) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
252 - this is useful whenever we would otherwise need to make the |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
253 connection ourself. for example load balancing and shared mailboxes |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
254 requiring another UID to run. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
255 - this rfc defines no exact way for server to detect if client |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
256 supports referrals or not. I don't think there's much point in |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
257 supporting only referrals, as most clients don't support them. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
258 Instead we should return referrals when we know that client |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
259 supports them, otherwise do the connecting ourself. If client |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
260 issues RLIST or RLSUB command, it's safe to assume it supports |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
261 referrals. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
262 - for load balancing this works just fine, but what about shared |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
263 mailboxes which require different UID? If we login with our own |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
264 username, we end up with our own UID instead of what we wanted. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
265 IMAP URLs don't support separated authorization id which would |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
266 have made this very easy.. We could give the "userid@group" as |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
267 userid, but clients probably treat it as different userid and |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
268 ask the password again. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
269 - problems, problems, .. maybe not worth the trouble. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
270 - uidplus (rfc2359) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
271 - uid expunge: no problem |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
272 - append, copy: oh no. these would slow down things and make |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
273 handling them much more difficult. currently we just store the |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
274 mails to destination mailbox without touching the indexes. since |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
275 we'd need to know their final UID, we'd have to lock the indexes |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
276 and mbox) fsck() first and append() next to find out the uid, |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
277 maildir) move the mail directly into cur/ and index it. |
| 1178 | 278 - except, the index updating is faster than requiring to sync the |
| 279 changed mailbox. we'll probably create such deliver-binary anyway, | |
| 280 so it can't be that difficult to code. | |
|
376
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
281 - drafts: |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
282 - http://www.imc.org/ids.html |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
283 - annotate (draft-ietf-imapext-annotate) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
284 - per-message annotations. this will be major change. especially |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
285 because currently there's no suitable storage for them, and |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
286 they'll probably change all the time.. maybe if we moved into |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
287 berkeley db to store the .data file and these annotations. |
| 1178 | 288 - this is separate problem from index files. indexes are treated as |
| 289 temporary files, annotations are permanent data. we'd have to | |
| 290 support non-db way to do this too, which would probably be just a | |
| 291 simple (slow) text file. | |
|
376
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
292 - annotatemore (draft-daboo-imap-annotatemore) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
293 - server and per-mailbox annotations. much easier than |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
294 per-message annotations, but they'd be easier to place into |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
295 db as well. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
296 - binary (draft-nerenberg-imap-binary) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
297 - perhaps not too useful. I'd like to make Dovecot fully |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
298 binary-safe though. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
299 - view (draft-ietf-imapext-view) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
300 - slow, complex, luckily draft expired almost two years ago. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
301 i hope i don't have to implement this :) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
302 - can be done client-side just fine (evolution's virtual folders) |