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>
|
