httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rian Hunter <r...@MIT.EDU>
Subject Re: New mod_smtpd release
Date Mon, 15 Aug 2005 02:17:27 GMT

On Aug 14, 2005, at 8:12 PM, Joe Schaefer wrote:

> Rian Hunter <rian@MIT.EDU> writes:
>> On Aug 14, 2005, at 1:22 PM, Joe Schaefer wrote:
>>> +
>>> +
>>> +  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.

View raw message