Actually I am not sure if the heart of my product is actually a TCP proxy or an SMTP proxy.
I don't try to interpret SMTP commands beyond a point. Actually it is an SMTP proxy. Yes. It is so because I look at the 'DATA' command which actually sends out the headers and body of the mail and process it and then deliver it to the TCP pipe of the mail server or drop it sending an error 550 response code to the sending mail client. A TCP proxy would only look at a TCP shutdown or so. The design of my 3500 line C code is actually very very interesting. It could be smaller since I have an auth socket which is actually not something I have implemented yet. In these many lines of C code a lot of things happen. It was not written easily or in a week or so. It took I think around 2 months to write and to fix the most critical bugs it took more than 4 months I think. And it is only now that the code is production quality. So it has taken more than a year. The larger aspects of the design which we in software parlance call as a 35,000 feet view itself is quite complicated and requires substantial technical knowledge. Try discussing this with your manager in a big software company and I can wager, nobody would be able to figure out what this means. Anyway I will describe the parts: *) Daemonize(chdir /, setsid, daemon(2) and so on) *) fork() model for concurrent processing(hardest part) How to clean up and how not to crash your system *) multiple sockets, UNIX domain, 3 TCP sockets, client and server *) poll(2) based relaying in which you act as proxy, again hard *) the real engine which reads, writes, creates temporary files using mkstemp() and does other munching, only the offset calculation when writing to a file is tough *) the SMTP proxy part which does interpretation of SMTP commands like DATA, RECV FROM, HELO/EHLO *) other features like passive OS fingerprint, invoking spam,virus check, SURBL analysis, SPF, DNS and so on *) communication between multiple processes for keeping track of counters like mails rejected, total mail attempts, I used a UNIX domain socket, instead you could use shared memory. I think I first tried shared memory, but liked UNIX sockets better *) Using linked lists to keep track of configuration parameters and iterate through lists of blocked mail IDs, doing network matching and blocked MIME types, attachments *) Config file parsing at startup and reading it on SIGHUP signal *) clearing the statistics counters everyday(using setinterval() timer) *) responding to statistics requests on a UNIX domain socket for the web interface *) logging SMTP handshake using syslog And so on. Really easy eh? -Girish -- Gayatri Hitech http://gayatri-hitech.com _______________________________________________ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc