mod_smtpd_auth and mod_smtpd_auth_dbd

["Brian J. France" <li...@firehawksystems.com>]

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.

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.

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.

Brian

Re: mod_smtpd_auth and mod_smtpd_auth_dbd

[rian <ri...@MIT.EDU>]

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
>