Rian Hunter <[EMAIL PROTECTED]> writes: > On Aug 14, 2005, at 1:22 PM, Joe Schaefer wrote: >> +RELEASE SHOWSTOPPERS: >> + >> + >> + smtp_process_connection_internal should take a "smtp_proto_rec" >> + argument (which is what the current "smtp_request_rec" struct >> + should be renamed to). >> > I can easily rename smtpd_request_rec but I don't think I should pass > it to smtpd_process_connection internal only because the hooks take a > request_rec*.
The hooks can still take a request_rec, but IMO the protocol's state management shouldn't be done from a request_rec. I'd still like to see one request correspond to one MAIL FROM/RCPT TO/DATA sequence, so that whenever the state gets reset, the whole request_rec pool gets cleaned up. > They need request_rec to use filters (even though i > don't currently enable convenient use of filters yet). The request_rec slot can be NULL for connection-level filters. But I'd create a request_rec sometime before I added an smtp protocol filter, which would just do the "."-decoding, similar to how http_in deals with TE. [...] > Ideally header parsing should be done in an mod_smtpd plugin not in > mod_smtpd. I respectfully disagree, because I'd like different hooks to have increasing state information available to them through the request_rec. In particular I'd like to see the smtp filtering API match httpd, by first parsing the headers, but passing the rest of the data through r->input_filters, with smtp_in translating the final "." line into an EOS bucket. -- Joe Schaefer
