On Tue, 2005-09-27 at 08:33 -0500, Brian J. France wrote: > Here are two modules I worked on last week while on a trip and ready > for some discussion. > > mod_smtpd_auth > mod_smtpd_auth_dbd > > http://www.brianfrance.com/software/apache/ > > mod_smtpd.patch will be needed which adds the auth hooks and info into > the smtp rec. This patch also does a dns look up of the remote_addr > because some auth methods need it and I figured it would be a good idea > to do it anyways.
This patch is arguable, hopefully more people on the list will like to give feedback. Since the AUTH command isn't a strict part of the SMTP protocol (as defined by rfc 2821) I can argue that a handler for it doesn't belong in mod_smtpd. Mod_smtpd does allow for plugins to implement extra command handlers though (through the unrecognized_command hook). The part of the patch that retrieves hostname looks good, although this is arguable whether or not this should be in mod_smtpd or one of the plugins (DNS requests are expensive). The part of the patch which adds an extra element to smtpd_trans_rec is controversial too if you move handling AUTH into another module. The correct way to do this is to have a module_config member in smtpd_conn_rec (similar to request_rec), where each module can store it's state structure. > mod_smtpd_auth currently has support for PLAIN, LOGIN, CRAM-MD5 and > DIGEST-MD5, but after finishing it I think whole auth stuff needs a > little rethinking/reworking. > > The way I did the mod_smtpd_auth module was to add the command AUTH to > mod_smtpd and then mod_smtpd_auth hooks that and has a big if/else if > block for all the auth methods. I think a better way to do it is to > have the auth stuff in the mod_smtpd server define two hooks, one for > methods and one for validating/getting passwords. Then in > smtp_protocol the command auth hook will just get the function to call > from the method hook list (just like command hooks are done) and run > that function. The big if/else if block that is currently in > mod_smtpd_auth will be turned into multiple modules that will use the > passwords hooks get get validate/get passwords. This means > mod_smtpd_auth will then go away and be replaced with two types of > modules, method (mod_smtpd_authm_*) and validate/getting > (mod_smtpd_authv_*) modules: > > mod_smtpd_authm_plain > mod_smtpd_authm_login > mod_smtpd_authm_cram_md5 > mod_smtpd_authm_digest_md5 > > mod_smtpd_authv_pwd > mod_smtpd_authv_dbd > mod_smtpd_authv_dba > > The other thing that will need to change would be the AUTH ehlo > response. It would need pull the method names from the method hook > list, which I don't know if it is possible or not. > > I think somebody with a little more hook experience could use the > current code and make the changes pretty quick, but I don't know enough > about the hook stuff to get it all setup with out getting a big > headache. Yes, there should be documentation. > There are a few issue that might be a problem with this setup. If > somebody wants to enable/disable auth methods based on server or > virtual hosts could be a problem, but I think that can be handled by > having the method modules delay hooking the method hook until the > connect phases to make sure they are enabled in that server. Not sure > if this is a problem or not, but if you look at the smtpd_protocol auth > function, it is pretty plain compared to the other ones. This goes > back to my original request to be able to set the response code from > the module (mod_smtpd_auth sets 6 different codes). Not sure how I did > this was the best way, but it got it working until we talk about this > again. > > On a side note, has there been some bugs fixed recently in apreq for > header parsing? I am trying to do final testing of mod_smtpd_clamd and > mod_smtpd_spamd, but I am failing on a assert in the parser header > function when I use real emails (vs real simple stuff). Need to svn > update and try it again when I get a chance, but figure I would ask. No but there will be very soon. > Brian >
