csmaild-cvs Mailing List for C# Mail Server

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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&nbsp;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&nbsp;data store, such as a 
      file-system&nbsp;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.&nbsp; 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>

csmaild-cvs Mailing List for C# Mail Server

csmaild-cvs — cvs commit mailing list