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
