httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: mod_smtpd design.
Date Mon, 11 Jul 2005 21:39:40 GMT
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)


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

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

View raw message