httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: mod_smtpd design - protocol
Date Sun, 17 Jul 2005 09:57:35 GMT
On Sat, 16 Jul 2005, Jem Berkes wrote:

> I want to focus a bit on mod_smtpd design, in particular the protocol
> module (which accepts connections and does the E/SMTP talking). I've seen
> various ideas thrown around on what exactly the module should do. It would
> be nice if we could come up with at least the high level design specs for
> this, just so we're all on the same page about what the module will do and
> what facilities it will offer to external module users.

Indeed, thanks for raising the subject.  Sorry I'm not being more
responsive, but I'm @apachecon and on the road with limited
time&connectivity for another week.

> So let me throw this out there as a starting point because I don't think
> this has been documented yet?
> The mod_smtpd protocol module accepts client connections and speaks E/SMTP,
> with default processing for all commands. e.g. it has a default greeting
> upon connection, a default response to EHLO/HELO, default accepts any
> envelop sender in MAIL FROM, default rejects any recipient in RCPT TO to
> prevent open relay configuration, etc.
> However the module should provide several hooks to allow another module to
> use smtp. Off the top of my head, we need at least these hooks:
> - upon connection from some client
> 	User might introduce delay, lookup IP for RBL, customize greeting
> - upon receiving HELO/EHLO from client
> - upon receiving MAIL FROM
> - upon receiving RCPT TO
> etc
> - upon receiving other command like VRFY, RESET, NOOP
> - upon receiving invalid command

Hmmmm ...

I had envisaged just an ap_hook_smtp_envelope rather than one for every
individual command.  But on reflection, since it has to respond to each
command individually, it needs to run a hook for each line.
Do you think it should have a bunch of different hooks, or a single
hook and let modules simply return DECLINED on commands they're not
interested in.

> I think this granularity is required. But I'm not sure about how the DATA
> hook would work? Among the two people who already have some code for smtp,
> are you coding something along these lines?

After DATA it's basically got headers and contents, and falls into
the HTTP processing path.  That's the beauty of doing this: we get
to reuse the existing architecture.  I guess it needs additional
spooling stuff as previously discussed, though.

Nick Kew

View raw message