-
Notifications
You must be signed in to change notification settings - Fork 7
/
TODO.txt
178 lines (129 loc) · 6.87 KB
/
TODO.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
Now that the basic server is working it is time to establish specific
things I need to do.
* break up resync all in to:
* find new folders
* resync on folders that have not been resync'd in <n> (five?) minutes
* expire active folders that are around past their expiry
* add continuing and queued work support per mailbox
XXX Still needs tweaking but it basically works now.
o we still need to add proper support for this with 'search' !! Definitely!
o we need to look at our STORE support and see if it needs any tweaking.
* add 'MailboxInconsistency' exception and handlers at the client.py
that when they get this have a better idea what to do (things like
'send a BAD to the client, 'be silent and retry command',
'disconnect client')
XXX 1/4 implemented. We have the exception and some commands grok it
and restart.
* Handle mailbox.MH and mailbox.MHMessage exceptions like 'malformed
sequence' and such.. like MailboxInconsistency.. mostly we just need
to retry since the problem wil be fixed by the time we get to it
again.. usually it is because we and some MH command were fighting
over things liek the .sequences file.
XXX I think I have this.. but really it needs to be tested and I am
not quite happy how I am handling the exception. I almost think
I should be handling it at a lower level. Too much repeating
myself in code.
* Watching Mail.app if a folder has pending expunges we send back
No's, but it keeps trying to do fetch's.. I wonder if we should do
an unceremonious close on a client if it asks for FETCH's like 10
times in a row while there are pending expunges.
XXX Yet to see if this actually works.
* add mulitple port (ssl/non-ssl) support
XXX have not tested this yet, but then SSL support is there but does
not work properly when Mail.app is talking to us (but 'openssl
s_client' works fine)
* add UIDPLUS (rfc4315) support
* write tool to split huge mailboxes in to mailbox + sub-mailbox by
year, keeping the last 1,000 messages in the current folder.
* fix logging so each subprocess output goes to its own logfile (named
with local and imap user names)
* daemonize properly.
* add proper unix account authentication support
* make sure we change to the right user
* Must support throttling so that brute forcing causes lock outs.
untested! (right now it is 3 bad auths in 60 seconds locks out
that IP address, 4 bad auths in 60 seconds for a specific user
locks out that user name for 60 seconds.)
* fix renaming folders with subfolders
* add SSL support
* fix literal+ support
* implement rfc3348 the 'child mailbox extension'
* There is a bug with renaming a folder to a new name that has
subfolders (not making it a subfolder of other folders.)
I think that although my recursion function should work it is a bit
too confusing and that I can replace it with a simple loop over
matching records in the database that will be as effecting and a
clearer to understand.
* this is a problem when an IMAP tries to copy a message to a folder
that is locked by some other process and the message ends up getting
copied ot the destination folder multiple times.
This mostly happens when my spam marking has locked the 'junk'
folder and Mail.app tries to put more messages in that folder
Fixed... it was not about queued commands but the resync on the
destination folder failing due to a mailboxlock and the upper level
basically re-queueing the entire command that had already been
executed..
o Apparently we should not even send untagged FETCH's to client unless
they are in these states:
- as the result of a client command (e.g., FETCH responses to a
FETCH or STORE command),
- as unsolicited responses sent just before the end of a command
(e.g., EXISTS or EXPUNGE) as the result of changes in other
sessions, and
- during an IDLE command.
Right now we are generating untagged FETCH's to clients when the
state of messages in a mailbox changes. We need to put these on to
things like the expunge queue.
o Find a way to make 'check all folders' run in the background. Maybe
fork a subprocess for it? and we parse the results when it finishes?
Or instead how about we get rid of find_all_folders. WHen we resync
a folder we track the last time we found its sub-folders. If it has
been more than an hour or something we get that folder's list of
sub-folders. If any of those folders are NOT in our db, we add them
(and either call resync now or wait until the next 'check all
folders' runs.)
o when we queue a command for later due to a mailbox lock we should
delay re-running it for like 0.1 seconds to prevent busy spins on
locks. I guess put in a 'delay' or something in the queued job and
'last time run' if delay is true, then delay running it until we
have passed the delay time.
o Add support for NOTIFY (rfc5465). I think this implies I need to
support rfc5267 as well. We should also support rfc5258 - LIST-EXTENDED
o some sort of intelligent fallback for messages with malformed
headers such that we can not find the UID properly.
o make COPY command queue'able.
o make SEARCH command queue'able again.
o add a better test system so we can run the full server but have it
not run as root, and not change to a user upon auth, and have the mail
dir exist in a set well known place.
o add command/response tracing facility and hook it into the ability
to run regression tests against a running server.
o write a unit test suite for the components we can test separately
(like IMAP message parsing, search & fetch over a set of test
messages.)
=== 2012.03.23 ===
o 'check_all_folders' is pretty quick... 4.8s on
kamidake.apricot.com for my account - but how about instead of doing
a sweep of folders we know about we basically queueu up a series of
requests to check the status for each folder. It would have the same
effect, but instead of blocking the server for <n> seconds, it would
flow normally, almost like an IMAP client doing CHECK commands
on every folder.
=== 2012.07.23 ===
Suggestions from Bill Janssen ([email protected])
Add to the readme or a how to run the server document text that better
text that tells you what you need to bring the server up. He pointed
out:
* Install pytz first.
* "sudo mkdir -p /var/log/asimapd/" first.
* Use utils/asimap_auth to create logins with passwords, before firing
up the server for the first time.
* Edit asimap/auth.py to use "~/MH-Mail" for my mail root instead of "~/Mail".
A couple of suggestions:
* You'd probably like Tornado (http://tornadoweb.org/). Great
replacement for the buggy and poorly maintained async*. -- look in to
tornado to replace async*
* It would be great if auth.py read ~/.mh_profile to get things like the
maildir. The vars "Path" (the maildir), "MailDrop" (the mbox spool
file to inc from), and "Flist-Order" (an ordering for mailboxes) might
be useful.