[csmaild-cvs] csmaild/docs Todo.htm,NONE,1.1
Brought to you by:
tamc
Menu
▾
▴
[csmaild-cvs] csmaild/docs Todo.htm,NONE,1.1
|
From: <ta...@us...> - 2003-08-08 22:44:13
|
Update of /cvsroot/csmaild/csmaild/docs In directory sc8-pr-cvs1:/tmp/cvs-serv19295/docs Added Files: Todo.htm Log Message: Oops, here's the todo doc --- NEW FILE: Todo.htm --- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <title></title> <meta name="GENERATOR" content="Microsoft Visual Studio .NET 7.1"> <meta name="vs_targetSchema" content="http://schemas.microsoft.com/intellisense/ie5"> </head> <body> Things to do with the csmaild server, split into categories: <UL> <LI>General <UL> <LI>RFC 2822 parsing <UL> <LI>Still needs to be finished; look around, you'll find missing code ;)</LI></UL> <LI>Configuration <UL> <LI>Need to set various options (i.e. ports, ips, aliases, etc. etc.) <LI>IP address/domain restrictions on who can connect <LI>Filters for incoming mail <LI>Lots of other stuff I'm sure</LI></UL> <LI>Code review, refactoring, restructuring, performance alterations, logging, filters, mailing lists, etc. etc.</LI></UL> <LI>Imap <UL> <LI>Bounds checking </LI> <UL> <LI>Most of the time that the client will be using a literl string it'll be for reletively small amounts of data. Need the ability to limit this per command argument, or at a global level. The only command argument that *should* be of any significant size is the APPEND's message data argument. <LI>Need to ensure that the number they send us is smaller than uint.MaxValue before we put it into the uint variable, or some variation thereof. <LI>Both of the above issues may apply to FETCH's BODY[...] and BODY.PEEK[...] requests as they can specify an offset and length (both unsigned ints) <LI>Related to the above issues, but not necessarily bounds checking. If the string that is to be sent/received is going to be of any significant size we should probably figure out a way to not do it all in memory all at once (byte[] buf = new byte[uint.MaxValue] won't work I don't think ;)). Possibly using a chunking method, or some sort of Stream solution. Both have their issues as they both will be sending data either into or pulling data out of the data store, so the solution to this must be supported by the data store as well.</LI>< /UL > <LI>Notifications/locking</LI> <UL> <LI>Client will expect to receive various responses as per certain events that will occur on a message/mailbox. Need to design this framework. <LI>Should implement some sort of thread safety on the various objects to ensure that all clients receive all notifications for an object before they're allowed to modify it themselves.</LI></UL> <LI>Finish RFC-3501 commands <UL> <LI>APPEND <UL> <LI>Not even started</LI></UL> <LI>AUTHENTICATE <UL> <LI> Started, have more authentication mechanisms to implement if the desire exists <UL> <LI>CRAM-MD5 <LI>?others?</LI></UL></LI></UL> <LI>CHECK <UL> <LI>It's implementation is defined as implementation specific, if we can make a use for it, that should be done ;)</LI></UL> <LI>FETCH <UL> <LI>A bunch of the things a client can fetch aren't implemented. Just look for the NotImplementedException, and implement it. <LI>The ENVELOPE request has some addresses defined in the response. Need to figure out what exactly: "Holds route from [RFC-2822] route-addr if" means. Probably just means to read the 2822 spec a tad more closely</LI></UL> <LI>RENAME <UL> <LI>If the user is renaming the INBOX, then we create a new mailbox and move the messages. Still need to implement the moving of the messages. <LI>Not saving the name back to the datastore when a normal rename occurs</LI></UL> <LI>SEARCH <UL> <LI>Not even started</LI></UL> <LI>STORE <UL> <LI>Needs to send a FETCH response for the modified messages if the client didn't specify .SILENT</LI></UL> <LI>STARTTLS <UL> <LI>Ugh, who wants encryption anyway. Refer to rfc3501 and rfc2595 for info.</LI></UL></LI></UL> </LI></UL> <LI>Pop / Smtp <UL> <LI>Not even started yet, but I would imagine the structure would follow suit with what I started in Imap, seems to be working well for it so far (however no performance measurements have been done yet).</LI></UL> <LI>Data <UL> <LI>Actually think about the mail store, instead of just quick writing something that works for now ;) <LI>Abstractly, this is what I'd like. <UL> <LI>Mail server has absolutely no dependance and ideally no knowledge of/on a particular data store, only on the interface that defines them <LI>Seemingly contradictory to the above point, the ability to utilize certain perks of various mail stores (for example, I would imagine it might perform better if we translate the arguments to the SEARCH command into a SQL query and gather the results from that instead of loading all messages into memory and scanning through them via C# code, however, the same might not hold true on a different data store, such as a file-system style one (unix mbox or something))</LI></UL> <LI>Ideas to achieve above <UL> <LI>None as of publishing ;)</LI></UL></LI></UL> <LI>Gui <UL> <LI>This isn't pressing, but it's something that going to be done eventually. Basically it'll just be a way to start/stop/pause, add/edit/delete users, modify config files, etc.</LI></UL> <LI>Testing <UL> <LI>Functionality <LI>Performance</LI></UL></LI></UL> </body> </html> |
