On Aug 14, 2005, at 8:12 PM, Joe Schaefer wrote:
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.
This make sense. smtpd_request_rec does what you say. After looking
at smtp_core.c it seems that request_rec isn't really something
needed for mod_smtpd (and really never was). After figuring out the
input filters situation, i'll probably do away with request_rec
(since it isn't needed for connection-level filters) and just stick
to smtpd_proto_rec. Any objections?
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.
Yeah I agree.
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.
Well there's also another problem. RFC 2821 (SMTP) doesn't define a
particular message format for SMTP (in wide use there the RFC 822 and
MIME message formats). I don't think that mod_smtpd should assume a
RFC 822 or MIME message format since its strictly a SMTP module,
that's why I still think header parsing should be in another module.
Of course this module is free to register itself as an mod_smtpd
filter and do what it needs to do, but it shouldn't be part of the
main mod_smtpd. The modules that will specifically rely on this
header parsing module will know how to obtain the header information
using the conventions specified by that parsing module.
-rian
