Contributed by Paul 'WEiRD' de Weerd on from the dont-print-this-email dept.
Besides trying to reach Nantes (for some reason it has always been more complicated than it seems, even if I live not too far away; I now consider it as an achievement in itself), my goal for this hackathon was mostly to work with Gilles on fixing the remaining issues for the config rewrite of smtpd. I will not go into a detailed description of the whys and wherefores, since he already explained a lot about it. It is something quite big we needed for a long time, and we wanted to have it done for good before adding other features we had in mind.
When I arrived, Gilles was already actively working on it. He had a clear view of what needed to be done. So there was in fact not much for me to do but to discuss some details, make some suggestions, and basically ok the diffs he showed me. It was obvious that I should not waste too much time looking into that part of the code again, and we agreed that I would better focus on the next big thing: the legendary smtpd filters.
So I looked again at the SMTP filter daemon prototype I had written some time ago. To my surprise, I was able to remember fairly quickly how things were supposed to work, and I started to look at how to plug it in smtpd(8). Within a few hours I could run a proof of concept, where user SMTP commands and responses would flow "transparently" through the filtering daemon. That was a nice hack, but a proper integration would require much more work. I was not exactly sure where to start...
In the meantime, in order to get a feeling of concrete accomplishment, I imported the smtp(1) utility. The idea is to have a very simple tool for interacting with an SMTP server, running transactions and so on. Very useful to test SMTP server configuration and behavior. The middle-term goal is also to re-use the client state machine for an update of the relaying part of smtpd(8) at some point.
Exhilarated by my success at remembering how to use the cvs(1) command, I thought that was also the perfect occasion to finally import the new lpd(8) server implementation I have been working on for months, and which was more or less rotting on my disk, waiting to be finished. I took about a day to polish the code, especially by synchronizing the log and config parser code with other daemons. I actually started to look at unifying the dozen of flavors of log.c we have in the tree, but it turned out to be far from trivial. I guess that is a topic for a whole hackathon. Anyway, the new lpd(8) daemon itself is not yet complete, but it will be easier to work on it now that it is in the tree.
Then, I went back to the smtpd(8) filter integration issue. After having slept (and drunk) on it, I finally decided that the way to go was through a major cleanup of the SMTP session code. The strategy was roughly to revamp the code to better separate between the frontend part of the session (management of the client connection) and the backend part (internal state of the server dealing with SMTP transactions), with the intuition that the articulation between the two will be clarified in the process, making it easy to plug the filtering layer there afterwards. The good news was that Gilles' work on the new config was not affecting that part of the code at all. So I could commit lots of diffs in parallel without colliding with his work. The cleanup is still ongoing, but I am confident we can get the plumbing for filters ready before the next release. Finally.
Altogether, I am quite happy with what I have been able to achieve during this hackathon. I would like to thank Gilles and the OpenBSD Foundation for organizing, and my employer VPTech for letting me and other colleagues attend this event.
Thank you Eric, for your report and the work on smtp(d) and lpd!
(Comments are closed)