httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rian Hunter <r...@MIT.EDU>
Subject Re: [mod_smtpd] patch need for the SIZE extension
Date Wed, 08 Feb 2006 05:42:34 GMT

On Feb 7, 2006, at 8:15 PM, Brian J. France wrote:

> Hi Rian,
>
>   Before I started converting my other modules to the new code I  
> figured I would start with writing a new module to handle the SIZE  
> extension.  I needed to apply the following patch (link below) to  
> the mod_smtpd code to get access at the max data size.

+0, Well this is an interesting point. The max data size should be  
settable and gettable from extending modules. In a way max_data is a  
lot like the list of extensions: should it be set on every connection  
or upon server initialization (ie should it's scope be per connection  
or per mod_smtpd instance). I chose that the list of extensions might  
want to be per-connection since modules may not want to offer all  
clients all extensions, just the same way modules may want to enforce  
different max_data sizes for different clients. Where do you think  
these variables belong?

One thing I do know is that max_data doesn't belong in mod_smtpd's  
configuration structure and rather either in some other "per  
mod_smtpd instance" structure accessible to extending modules or just  
in scr (the per connection structure). Right? I think that would be  
cleaner and more modular. We should talk about this some more before  
I apply this patch.

>   I hooked the mail from hook, check for a valid SIZE in  
> mail_parameters and check to make sure it is not over the limit.   
> If it is over the limit I can use smtpd_respond_oneline to send the  
> 552 "message exceeds fixed maximum message size" line back to the  
> client, but what should the function return to make it force a QUIT  
> or REST command as anything but SMTPD_DONE sends more stuff to the  
> client.
>
> Should I just return SMTPD_DONE and set scr->should_disconnect?   
> Could we tweak it to support two different settings, one would only  
> allow QUIT only and the other would allow QUIT and REST (to start  
> over).

+1, Since quit and rset are both handled by mod_smtpd there should  
probably be another variable called scr->only_quit_or_rset, also  
because I think there are other times when the client should only  
issue a quit or rset. More discussion follows though:

My basic design strategy has been that mod_smtpd should do as little  
as possible or what will be practical to a large amount of extending  
modules. If mod_smtpd sets a variable in a structure it should use  
it. If an extending module sets a variable in a structure it should  
use it. Having an "only_quit_or_rset" variable in the scr structure  
with mod_smtpd consciously checking for it, but never changing the  
value itself sort of violates that strategy. That doesn't mean I'm  
against it because like I already mentioned I think a lot of modules  
will need this sort of thing.

Have you thought about hooking into all the commands, and then  
sending a "503 Only QUIT and RSET" from your SIZE module until a rset  
is received?

I only added the scr->should_disconnect logic since it's what should  
happen when a simple module wants to SMTPD_DENY some connections. I  
didn't want every module that wanted to implement connection policy  
to have to deal with being hooked into all the commands, and just be  
able to return SMTPD_DENY.

The scr->should_disconnect situation I just explained (where I didn't  
want every modules to have to deal with hooking all the commands for  
a redundant task) could be applied to any potential module that wants  
to disallow any of the built in commands with instead a bit-field  
that specifies which mod_smtpd core commands are currently allowed. I  
think I like this idea the best, what do you think?

Rian Hunter




Mime
View raw message