time for the weekly blog 
i’ve spent another weekend heavilly devoted to smptd. i’ve chatted with a person who tried to do some hacking on the smtp server and gave up, and he told me of another who gave up and decided it’d be easier to rewrite it than to go where i’m going. do i agree? partly. for those of you who have not read the irc logs or were not around, at one point i commented on “looking at the same block of code for about an hour and a half, and finally come to the conclusion it is a complex piece of code”. it might be conceptually easier to think a rewrite would be better, but it would take a lot longer to try to get all the current functionality into the daemon. so what is the current status ?
i’ve gotten smtpd to accept mail for local delivery now for non-ssl connections. the ssl stuff won’t work quite yet as there is a small block of code i haven’t gotten to yet where the STARTTLS command is implemented. the code that goes in that block is already scattered through the system though so it should be fairly easy to get going.
remote delivery is close to being done, but there are two functions that i have yet to rework. one gets the answer from the remote system GetClientAnswer() and the other is one that i haven’t quite figure out yet SendServerEscaped(). i believe this one is supposed to escape data that could mess up the conversation (things like a period) in a certain spot. why this could happen i haven’t found yet, but the function is called in multiple places in code.
i’ve also been going to town on the variables. a bunch out of the ConnectionStruct struct are no longer needed so i’ve removed them. there were also a bunch of globals that i got rid of too. one in particular baffles me MaxFloodCount. it gets set in several places, but never used. i’m not sure what its intention was.
another area that needs a little bit of attention is the connection to the queue agent for queue processing. smtp is different from imap, pop, or dragonfly in that it registers with the queue on a specific queue number. when a message hits that queue number (6), the queue agent will call smtp to let it do processing. thus we have a thread system that listens for incoming connections from the queue server and processes those requests. the code is written but not tested yet (this is obvously tied closely with the outgoing mail tests).
there is also still a large number of things that i’d like to fix. there are blocks of code that are commented out via #if 0 statements, and abuses of variables clearly named for one purpose for something completely different. eventually (not for this release) it would be good to modularize the code more like imap making the code much easier to read. right now all the command processing is one big switch() statement. this could make for fast code (depending on your opinion of compiler optimizations — i’d like to see a study on speed comparisons), but it makes for code that is much harder to maintain and debug. another thing that kinda bugs is to have a variable on one line getting set with the result from another line. this makes gdb interesting as all you see is VariableName = (since my gdb doesn’t like to print multiline). other things like the non-standard (for bongo at least) matching of {} and other such things that don’t match.
on other fronts, alex and i have been doing lots of talking on lots of things. one thing he mentioned was address rewrites vs aliasing and how we are going to handle it. it would be nice to just have that code in smtp instead of a separate queue agent the way that it was before. this however would not work as then dragonfly would then have to be modified to use smtp instead of talking direct to the store. this would not be a cool thing for us as that would slow dragonfly down. it’ll probably end up in a library that is linked or used in some non-specific way like alex suggested of using the auth system in the store (which i think is an excellent idea. the only thing that worries me is non-global domain aliasing).
we chatted a little bit about bulid versioning just today. if you look at the agent code near the top is a define PRODUCT_VERSION which i believe used to be an expanded string in code (when i was on the team we used pvcs but i’m sure that’s long since been done away with). we were discussing a way to auto generate that constant. this needs a little more discussion.
we had a small discussion on dmc as well. dmc was a management tool to allow you to pass tuning parameters of almost any sort, and to get statistics from various agents. it is a great idea, but it is pretty complex code how it is currently implemented. the rules agent (which i’m not sure if it was ever completed) used a new system that is really pretty. we discussed the possibility of using this type of system as well. part of me thinks this would be really cool as then the snmp stuff i’d like to add eventually won’t have to be in every agent, but only in once place that speaks dmc-speak.
i think the other major discussion we had was the one concerning bongo-manager that alex mentioned where it provides configuration information. i think in the long run this is a good idea as bongo-mananger needs communication with the agents anyhow. it was pixelpapst on irc that proposed that idea after alex and i were chatting about mdb and configuration data.
one last thing i’d like to mention is an article i found on /. that i posted to the irc channel. it should be required reading in my opinion (InformationWeek). alex told me i should have blogged it and he’s right. i agree with a lot of what this guy says, some of it i don’t. i think that we have some of the things that he thinks makes an open source that will succeed. it’s a good read and if you want to discuss it, hop into irc
after having written this mostrosity, i’m seriously thinking about writing more often. this is just too much work for one sitting!