Jem Berkes wrote: > Where are we in the mod_smtpd design/task allocation? Since there are > several people involved we're really going to have to divide up the tasks > and at least decide on how our various modules will communicate. I'd like > to start coding, if one of the mentors could push me in the direction they > want please :)
I'd like to see more of you on IRC:-) > > As I understand it, we want to produce one module that deals with the SMTP > protocol, and a separate module to handle mail delivery (probably via > procmail is easiest for now). Does this mean we should also produce > separate modules, one for incoming and one for outgoing mail transactions? > In other words, several modules: > > - SMTP protocol library Hmmm, a library might be OTT. If there's significant common code it could in principle become something like util_smtp. If you think it should be a lib, perhaps you could propose at least the outline of an API for the lib. SMTP is two tasks: accept incoming connections (a protocol module - c.f. the ftp modules), and make outgoing connections to another server. The latter would be a proxy_smtp module in the mod_proxy framework - c.f. proxy_http and proxy_ftp. These are clearly Have you done any research on available code for handling the protocol? > - Incoming SMTP mail (hook connection/server) Indeed, as discussed in recent correspondence on this list. Wasn't someone going to evaluate options of reusing the request_rec as-is vs developing a version customised for SMTP? > - Outgoing SMTP mail (spooling, DNS MX, sendmail-ish) Yep. As you say, it'll want spooling. Incoming mail will also want spooling, so we've identified that as an important function. I'm wondering if we could deal with that by introducing a new spool bucket type, that will be like a file (or mmap) bucket but with additional code/hooks to enable longer-term queueing, and recovery after a system restart. > - Delivery of SMTP message (to local, e.g. pipe to procmail) That's basically a similar task to CGI, and a first pass at that would be to try running procmail under CGI (with incoming HTTP POST or PUT requests will do fine). I imagine that would be a pretty trivial job with perl or python. Now look at what you needed to do. That's a first-pass spec for this task. It should be a fairly straightforward mod to mod_cgi(d). I'm not sure whether that's the best approach, but hacking it up will surely throw some light on the matter. > Or is that getting too fragmented? Not at all. The more modular we keep it, the better. With of course the proviso that the modules need to be coordinated with underlying utilities such as spooling and util_smtp - if those are implemented separately. That gives us at least three subprojects. You should probably identify one of them and then concentrate on it. If it's not the SMTP frontend, start by running HTTP requests through it for dev purposes and move to SMTP when available. Post here to stake out your territory (Rian - have you staked out any territory? Mathieu - have you shared the SMTP hacking you started before we got the SoC folks?) And then there's the RBL and spamassassin input filters if you need some more to do :-) -- Nick Kew
