Rian Hunter wrote:
Well not exactly. A module that parses headers can register itself as an input_filter for mod_smtpd. It can parse the headers and the headers can be accessed by a get_smtpd_headers(request_rec*) function or similar exported by the parsing module, and modules that rely on this module will know about that API. This module can even be included with the default mod_smptd package. Do you agree that this is possible?
It should certainly be included with the mod_smtpd package. Is there any reason why the existing header parsing code for http shouldn't be used for this? AFAICS, the new things we have to deal with for SMTP are: - smtp handshake and envelope (which you've done) - spooling - dealing with multiple recipients - dealing with MIME message MIME decoding of multipart messages is something I'd like to see (for spam filtering), but it's not an immediate priority. If we have the initial RFC822 headers in r->headers_in, that'll be fine for now. Spooling and dealing with multiple recipients are things I'd like to think about now. ISTR posting about this before: I think each recipient needs a separate request processing cycle, because each recipient may have completely different processing rules. Do you think we can deal with that by creating a new suprequest for each recipient? If so, we'll need to allow filter hooks both before and after subrequesting, and pass each one the spooled input data.
Either way, lacking header parsing in mod_smtpd is being impractically pedant since probably 99% of SMTP transfers involve messages in the RFC 2822/MIME formats. Although I think that maybe there will be a plugin that wants data from the DATA command verbatim. I still feel this needs some thought.
Agreed. Maybe a hook for DATA could deal with pathological cases, with normal header/body handling the default? But I haven't thought it through: I wasn't even aware of the notion of smtp-without-RFC(2)822. -- Nick Kew
