Mercurial > dovecot > original-hg > dovecot-1.2
annotate TODO @ 956:26cafa3dc09c HEAD
minor optimization
| author | Timo Sirainen <tss@iki.fi> |
|---|---|
| date | Sun, 12 Jan 2003 01:49:45 +0200 |
| parents | 80b847900dfd |
| children | 6f005d5d9931 |
| rev | line source |
|---|---|
| 526 | 1 - bugs |
| 2 - maildir: if mail file isn't found, it may be because it was renamed | |
| 3 (flag changed). we must then sync the directory and see again if the mail | |
| 4 is found | |
|
674
b7aefd0d7611
Locking changes triggered a bit larger cleanup :) If we have to wait for a
Timo Sirainen <tss@iki.fi>
parents:
651
diff
changeset
|
5 - we may override mbox dotlock file, but then get stuck at fcntl/flock. |
|
b7aefd0d7611
Locking changes triggered a bit larger cleanup :) If we have to wait for a
Timo Sirainen <tss@iki.fi>
parents:
651
diff
changeset
|
6 we should check for those before overriding the mbox lock.. |
| 526 | 7 - mail-lockdir.c isn't 100% safe.. stale locks are detected by checking |
| 8 that hard link count is 1, then it's unlink()ed. but what if another | |
| 9 process did the same unlink() + creat() in the middle of our | |
| 605 | 10 stat()..unlink()? no easy way to fix this really, just replace it with a |
| 11 fcntl() lock. | |
| 526 | 12 - SEARCH FROM/TO/CC/BCC now generates the field from ENVELOPE which it |
| 795 | 13 uses for matching. This however may give different results than when |
| 526 | 14 matching from headers. |
| 725 | 15 - SIGHUP didn't update imap_listen. this is a bit annoying to fix though, |
| 16 since new listen() may fail for a few times because auth processes may | |
| 17 not die immediately.. | |
| 860 | 18 - SIGHUP doesn't update log file location. |
| 795 | 19 - We can use Linux sendfile() up to 2GB, after that we get EOVERFLOW and |
| 20 fail. We should rather fallback to mmap+write at that point. | |
| 892 | 21 - unlink_directory() is racy with symlink handling, see if that could be |
| 22 helped.. | |
| 526 | 23 |
| 24 - reliability fixes: | |
| 605 | 25 - if we deleted mail from index but didn't write modify log, other |
| 26 dovecots don't handle it properly. they either assert at index-sync.c:42 | |
| 27 or if new mails have also been added since, they don't notice it at all | |
| 526 | 28 actually, that breaks reads as well since we get expunges only from |
| 29 the old file.. and check that deleting file does "inconsistency error" | |
| 30 - if imap process notices that both modify logs are getting full because | |
| 31 it's client isn't syncing, the client should be disconnected | |
|
674
b7aefd0d7611
Locking changes triggered a bit larger cleanup :) If we have to wait for a
Timo Sirainen <tss@iki.fi>
parents:
651
diff
changeset
|
32 - what happens if .customflags can't be locked while opening index? |
| 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 |
| 526 | 43 - checks: |
| 44 - if we have entries in modifylog with UID 10..11, 9..12, 8..13 etc. | |
| 45 do they work correctly? | |
| 46 - check that search message-id worked properly always | |
| 47 - check that search's OR and () work properly | |
| 48 - Should SEARCH SENT* apply timezone? | |
| 49 - make sure SELECT rebuilds index properly when next_uid is near 32bit value | |
| 50 - make sure connection limits work | |
| 51 | |
| 52 - enhancements: | |
| 852 | 53 - option to disable SORT, SEARCH and other memory/cpu-intensive features. |
| 54 defaults and per-user by imap-auth. | |
|
674
b7aefd0d7611
Locking changes triggered a bit larger cleanup :) If we have to wait for a
Timo Sirainen <tss@iki.fi>
parents:
651
diff
changeset
|
55 - optionally don't fail if index is locked, but build it in memory |
| 537 | 56 - when fetching body/envelope/etc we could try to cache it immediately if |
| 526 | 57 we can get lock with try_lock. |
| 58 - optionally use only in-memory indexes | |
| 59 - maildir could support also the dirty-flag in messages. files would be | |
| 60 renamed "whenever there's time" (that'd require the indexer program, or | |
| 61 forking and doing it in background) | |
| 62 - optionally keep the message file name as it's UID. Then we don't have to | |
| 63 save the filename anywhere. | |
| 537 | 64 - send EXISTS immediately after new mail arrives. |
| 605 | 65 - linux: we can use dnotify for maildir (but not mbox I think, we'd |
| 66 get interrupted all the time if we checked eg. large /var/spool/mail) | |
| 537 | 67 - *bsd: kqueue() can notify changes in mbox and maildir |
| 605 | 68 - .subscriptions currently uses fcntl() locking - maybe we should instead |
| 616 | 69 just write to temp file and rename()? optionally at least, so it |
| 605 | 70 works with NFS. |
| 634 | 71 - OpenSSL: support generated DH parameters |
| 725 | 72 - multiline headers can cause our memory usage to go up. that should be |
| 73 fixed somehow. try to change things to be able to handle one line at a | |
| 74 time? Well, other IMAP servers have same problem - post 1.0 problem. | |
| 75 - check with strace what dovecot does when evolution checks new mail, | |
| 76 it's quite a lot. some things probably wouldn't need to be done | |
| 77 (mkdirs/symlinking inbox) and other things could be cached in memory. | |
| 795 | 78 - sort: we could create alternative binary tree file(s) for different sort |
| 79 conditions, ".tree-sort" or something. sort code itself already supports | |
| 80 this optimization. | |
| 852 | 81 - sort: we could use some more memory so we don't need to parse the |
| 82 envelopes over and over again. for example with subject sorting we could | |
| 83 store the 4 first bytes of message into integer and compare it. only when | |
| 84 they compare equal we'd fetch the full subject and compare it. | |
| 85 - tree file: should we instead use b+-tree or something similiar? or at | |
| 86 least try to do some defragmentation with it, so that the root nodes | |
| 87 would be kept at the beginning of the file. | |
| 88 - use vsftpd-like safebufs, ie. keep non-rwx page before and after the | |
| 89 memory we want to use. | |
| 90 - mmap_anon() | |
| 91 - mmap()ing files would probably need to first go through anon_mmap() | |
| 92 and then use MAP_FIXED. annoying that it slows the mmaping.. | |
| 93 - data stack should use mmap_anon() | |
| 892 | 94 - option: copy /var/mail/$user to INBOX when logged in. nice for not missing |
| 95 any mails with quota enabled | |
| 605 | 96 |
| 97 - lib-charset: | |
| 634 | 98 - utf8_toupper() is a must. and a bit difficult if we want to do it right. |
| 605 | 99 - add support for other things than iconv() as well? we could reuse |
| 100 the code from cyrus or courier | |
| 795 | 101 - cache iconvs? they'd probably be faster if we just reset the |
| 102 conversion instead of opening new one every time. and there will likely | |
| 103 be only one or two charsets which are used for nearly all conversions. | |
| 526 | 104 |
| 852 | 105 - should we allow following symlinks in mbox/maildirs? they are now. |
| 106 - if we implement shared mailboxes with shared indexes, never do that or | |
| 107 others could symlink your personal mailboxes and see the indexes | |
| 108 created for it which may contain envelope etc. data | |
| 892 | 109 - this allows circular mailbox hierarchies which should be prevented by |
| 110 eg. allowing max. 20 hierarchies. | |
| 852 | 111 |
| 480 | 112 - allow index files to be in completely separate location than mail data. |
| 113 mails could be read through slow NFS access but indexes from fast local | |
| 114 disk. with this thinking it makes more sense to create larger index files | |
| 115 to save for example mail headers. also index rebuilding should be very | |
| 116 light operation, the indexes would be filled while the data is being | |
| 117 accessed by the imap client. of course all this should be optional so | |
| 118 we don't slow down when mails and indexes are stored in same disk. | |
| 526 | 119 |
| 497 | 120 - we need permanent storage for UIDs. with mbox use X-UID like UW-IMAP, |
| 121 with maildir a) file:2,flags,Uuid b) file,U=uid:2,flags. uid validity | |
| 122 would be in .uidvalidity file. the b-case would require that to be done | |
| 123 by the client moving it from new/ to cur/ | |
| 0 | 124 |
| 125 index: | |
| 126 - mbox: | |
| 96 | 127 - if a file isn't valid mbox and it's tried to be opened, say it in one |
| 128 line in error log, not 6.. | |
| 304 | 129 - empty lines at beginning of file still aren't ignored |
| 474 | 130 - UW-IMAPd writes empty spaces after X-Keywords which it uses so that |
| 131 it doesn't have to rewrite the whole file if status flags changed | |
| 132 in the beginning of it. We could do that too. | |
| 634 | 133 - When expunging the first message we could move the X-IMAPbase header |
| 134 to next message to avoid full rewriting later. | |
| 892 | 135 - We shouldn't send X-IMAPbase, Status, X-Status, X-Keywords, X-UID, etc. |
| 136 headers to client - they may change and clients must see messages as | |
| 137 immutable. | |
| 634 | 138 - COPY 1 copies X-IMAPbase header too which isn't good idea. save() could |
| 139 actually strip this (and X-UID) while also fixing From-lines etc. | |
| 526 | 140 - we need either From-line escaping or writing Content-Length when saving |
| 141 mails. | |
| 852 | 142 - two adjacent From-lines breaks us. not too easy to fix though. |
| 143 - we could try compressing same from/to/subject fields into a single | |
| 144 location in data file. requires larger changes.. | |
| 526 | 145 - read-only support for mailboxes where we don't have write-access |
| 235 | 146 - we should try to avoid completely rebuilding indexes unless they're |
| 147 corrupted. especially if we later want to support some read-only boxes | |
| 148 and keep the mail flags only in index file. fsck() could verify that | |
| 149 records are ok, and that if data file isn't ok the record is deleted. | |
| 150 - if .customflags is removed and Maildir files have custom flags, add | |
| 151 "unknown1" "unknown2" etc. flags to .customflags file for each found flag | |
|
376
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
152 - when index is being rebuilt, it always complains about tree/modifylog |
| 313 | 153 having wrong indexid.. |
| 474 | 154 - log transferred amount of bytes. just a bit problematic who logs it, since |
| 155 imap-login does SSL transfers but not unencrypted.. could also log SSL | |
| 852 | 156 settings (especially compression). login process doesn't currently know |
| 157 the userid.. maybe it should get it from auth as a reply. also log amount | |
| 158 of invalid password tries if all failed. | |
| 474 | 159 - if we wanted to support huge mailboxes with small memory usage, it'd now |
| 160 be possible if we just instead of mmap()ing the whole index files would | |
| 161 have maybe 3-4 256k mmap()ed areas which we move based on the need. | |
| 162 - should work fine with .imap.index and .imap.index.data | |
| 163 - log files aren't affected by mailbox size | |
| 164 - if the tree file also kept constantly moving the nodes so that | |
| 165 tree's root was at the beginning of the file, we could use this mmap | |
| 166 caching with it too | |
| 167 - but, is it worth the trouble really? the OS can do all this itself, | |
| 168 only thing we're doing is keeping the processes virtual memory usage | |
| 169 small. | |
| 0 | 170 |
| 171 lib-storage: | |
| 172 - support multiple mailbox formats and locations for one user. that would | |
| 173 require support for multiple MailStorages, and since we're chroot()ed, | |
| 174 usually the only way to communicate with others would be to create | |
| 175 RemoteMailStorage which would use TCP/UNIX sockets to connect to another | |
| 176 imap session. | |
|
376
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
177 - SEARCH: |
| 616 | 178 - message_body_search() could accept multiple search keywords so we |
| 179 wouldn't need to call it separately for each one (so we wouldn't need | |
| 180 to parse the message multiple times). | |
| 181 - message_body_search() could support NULL MessagePart and the searching | |
| 182 could be done while parsing the message. this would need changes to | |
| 183 message_parse() as well. | |
|
376
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
184 - could optionally support scanning inside file attachments and use |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
185 plugins to extract text out of them (word, excel, pdf, etc. etc.) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
186 - use a trie index for fast text searching, like cyrus squat? |
| 605 | 187 - Create our own extension: When searching with TEXT/BODY, return |
| 188 the message text surrounding the keywords just like web search engines | |
| 189 do. like: SEARCH X-PRINT-MATCHES TEXT "hello" -> * SEARCH 1 "He said: | |
| 190 Hello world!" 2 "Hello, I'm ...". This would be especially useful with | |
| 191 the above attachment scanning. | |
| 0 | 192 - DELETE/RENAME: when someone else had the mailbox open, we should |
| 892 | 193 disconnect it (when stat() fails with ENOENT while syncing). Also deleting |
| 194 selected mailbox begins giving internal error messages. | |
|
376
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
195 - RENAME INBOX isn't atomic with Maildir. And in general, RENAME can't |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
196 move mails between different storages. Maybe support doing also using |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
197 COPY + delete once COPY is atomic? |
| 337 | 198 - maildir: atomic COPY could be done by having transaction directories. |
| 199 Make a "tra" directory at the same level as cur/new/tmp, and make it | |
| 200 have subdirectories in the same way as tmp has temp files. Directory | |
| 201 begins with a "." as long as transaction isn't finished, rename()ing | |
| 202 it away finishes it. All mails under finished dirs must be moved into | |
| 203 new/ directory and the directory removed by any process who notices them. | |
| 61 | 204 - we should probably do some light checking that appended mails actually |
| 205 look like valid rfc822 mails.. | |
| 235 | 206 - maybe limit the length of custom flags? we don't really have a problem |
| 207 with them, but with mbox a long X-IMAPbase could break something.. Maybe | |
| 208 configurable, default to 50 chars? | |
| 337 | 209 - we could send flag changes after all commands by making expunge/flags sync |
| 210 counters separate for modify log. flags would need to update the seq | |
| 211 though, too slow? | |
| 212 - things calling message_send() could verify that it wrote enough data. | |
| 480 | 213 if not, fill the rest with spaces and return failure. -1 = error, |
| 214 0 = filled, 1 = ok. | |
| 0 | 215 |
| 216 general: | |
| 474 | 217 - sieve (rfc3028) |
| 337 | 218 - rfc2231 continuation support |
| 892 | 219 - rfc2557 support for BODYSTRUCTURE, as specified by latest IMAP4rev1 draft |
| 0 | 220 |
| 221 - create indexer binary | |
| 235 | 222 - should we bother checking if there's invalid 8bit headers in |
| 340 | 223 BODY/BODYSTRUCTURE output and converting them to quoted printable? well, |
| 224 several of them are now but not all.. | |
| 235 | 225 - update docs/index.txt |
| 337 | 226 - support Maildir++ quota |
| 227 - maybe give more untagged NO/ALERT replies? like when mailbox is in | |
| 474 | 228 inconsistent state. and when UIDs are reordered because they're too large. |
| 497 | 229 - imap/ and lib-imap/ should allow infinite number of custom flags, it's |
| 230 storage's problem if it can't handle too many of them. | |
| 61 | 231 |
| 232 auth / login: | |
| 337 | 233 - kchuid, SRP, anonymous SASL |
| 61 | 234 - PAM: support some options so /etc/passwd-lookup isn't needed. uid=x, gid=y, |
| 235 mailroot=/var/mail. maildirs should be then created when needed | |
| 0 | 236 - Digest-MD5: support integrity protection, and maybe crypting. Do it |
| 237 through imap-login like SSL is done? | |
| 892 | 238 - for invalid user/pass, wait for a while before giving a reply to user |
| 0 | 239 - imap-auth should limit how fast authentication requests are allowed from |
| 240 login processes. especially if there's one login/connection the speed | |
| 235 | 241 should be something like once/sec. also limit how fast to accept new |
| 242 connections. | |
| 18 | 243 |
| 244 cleanups / checks: | |
| 245 - grep for FIXME | |
| 246 - check if t_push()/t_pop() should be added somewhere | |
| 61 | 247 - ..wonder what it would look like if I did s/FooBarBaz/struct foo_bar_baz/.. |
| 852 | 248 - rfc822-tokenize: make it work with callbacks instead? |
| 249 - try to fix @UNSAFE code to use buffer API instead | |
| 250 - subscription-file.c, custom_flags, ioloop | |
| 251 - [io]stream-file.c? | |
| 0 | 252 |
| 253 optional optimizations: | |
| 254 - provide some helper binary to save new mail into mailboxes with CR+LF | |
| 255 line breaks? | |
| 256 - disk I/O is the biggest problem, so split the mail into multiple computers | |
| 257 based on user and have a proxy in the front redirecting the connection. | |
| 258 cyrus had something like this except a lot more complicated - it tried | |
| 259 to fix the problem of having shared mailboxes. we have the same problem | |
| 293 | 260 with local shared mailboxes as we don't use same UID for everyone's mail |
| 261 and we may be chrooted, so locally we could communicate with UNIX sockets, | |
| 262 remotely that could be done with TCP sockets. | |
|
376
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
263 |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
264 capabilities: |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
265 - 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
|
266 option (--without-capabilities=acl,namespace,...) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
267 - possibility to disable them from config file |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
268 - 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
|
269 - 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
|
270 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
|
271 configurable however. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
272 - shared namespaces? maybe configurable in config file |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
273 - 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
|
274 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
|
275 maybe we could support it. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
276 - 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
|
277 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
|
278 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
|
279 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
|
280 anyway. ACLs could be stored into ".acl" ascii file in each folder. |
| 480 | 281 - support for private and shared flags, configurable by mailbox admin. |
| 282 this isn't in any draft yet, but ACL2 author was going to create one. | |
| 283 [SHAREDFLAGS (...)] would specify which ones are shared, don't know yet | |
| 284 how they would be configured. | |
|
376
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
285 - quota (rfc2087, draft-cridland-imap-quota) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
286 - give filesystem values only to admins |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
287 - 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
|
288 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
|
289 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
|
290 - id (rfc2971) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
291 - 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
|
292 - separate pre/post-login settings |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
293 - 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
|
294 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
|
295 "Disconnected", etc. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
296 - 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
|
297 especially before logging |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
298 - mailbox-referrals (rfc2193) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
299 - 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
|
300 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
|
301 requiring another UID to run. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
302 - 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
|
303 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
|
304 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
|
305 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
|
306 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
|
307 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
|
308 referrals. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
309 - 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
|
310 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
|
311 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
|
312 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
|
313 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
|
314 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
|
315 ask the password again. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
316 - problems, problems, .. maybe not worth the trouble. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
317 - literal+ (rfc2088) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
318 - simple. in case of invalid data, just disconnect client. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
319 - idle (rfc2177) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
320 - just call the syncing every few seconds (configurable) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
321 - with Linux we can use fcntl() and F_SETSIG to provide fast checks. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
322 just make sure sync() still won't be called more than once in a |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
323 few seconds |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
324 - uidplus (rfc2359) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
325 - uid expunge: no problem |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
326 - 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
|
327 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
|
328 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
|
329 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
|
330 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
|
331 maildir) move the mail directly into cur/ and index it. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
332 - unselect (no draft or anything AFAIK) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
333 - like CLOSE, but doesn't expunge mails. easy. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
334 - drafts: |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
335 - http://www.imc.org/ids.html |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
336 - multiappend (draft-crispin-imap-multiappend) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
337 - shouldn't have any problems |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
338 - listext (draft-ietf-imapext-list-extensions) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
339 - well, it expired January 2002.. I like it though. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
340 - children (draft-gahrns-imap-child-mailbox) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
341 - I like listext more.. They have the same functionality though, |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
342 so pretty easy to support both if needed |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
343 - annotate (draft-ietf-imapext-annotate) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
344 - 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
|
345 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
|
346 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
|
347 berkeley db to store the .data file and these annotations. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
348 - annotatemore (draft-daboo-imap-annotatemore) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
349 - 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
|
350 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
|
351 db as well. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
352 - binary (draft-nerenberg-imap-binary) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
353 - 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
|
354 binary-safe though. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
355 - thread (draft-ietf-imapext-thread) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
356 - basically SORT but reply with thread lists |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
357 - possibly use a binary tree too .. or maybe it's enough to use the |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
358 sort-tree and then just pick up the references separately? have to |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
359 check more carefully later. |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
360 - view (draft-ietf-imapext-view) |
|
fd1fc4cf11b7
updated with lots of new capability comments
Timo Sirainen <tss@iki.fi>
parents:
340
diff
changeset
|
361 - 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
|
362 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
|
363 - can be done client-side just fine (evolution's virtual folders) |