On 2007-01-02, at 1018, Joshua Megerman wrote:
So we now have the question: What is the best way to proceed. I think that I would like to see the following changes made to the whole "roamingusers" functionality in Vpopmail: 1) Document that the auth-before-smtp RELAYCLIENT="" functionality is deprecated, and schedule it for removal 6-12 months down the line.
if i'm reading this right, you're proposing that the entire "pop before smtp" functionality go away? so that nothing other than POP3 happens when somebody logs into the POP3 service, and there would be no dynamic changes to the access control list of the SMTP service at all? and vpopmail's documentation would explicitly tell people "thou shalt use SMTP AUTH" from now on?
awesome. i just became one of your biggest fans.and for the time being, i think having an access control file attached to the POP3/IMAP services, which uses variables to tell when a given IP should trigger the update process, makes a lot more sense than trying to build a bunch of logic into vchkpw.c... just have it check for the presence and/or absence of environment variables, and let the external scripting control what does and does not go into that file.
for example, the script could read the static smtpd access control file and find any IP blocks with RELAYCLIENT defined on them- and then copy those blocks to the POP3/IMAP access control file... and then the logic in vchkpw.c would bypass any updating if it saw a RELAYCLIENT variable in the environment.
2) Hijack the --enable-roaming-users config line to allow a differentdefault set of tcpserver flags to be added. For now, the default would be '--enable-roaming-users="RELAYCLIENT=\"\",RBLSMTPD=\"\""', but once #1 isfinalized the RELAYCLIENT part would be removed.
there does need to be a way to set what gets added to the smtpd access control file for dynamic entries. i'm not sure that highjacking an existing option is the right way to do it, nor do i think it should be a configure option. i think it makes more sense to let it be configured at run time- something like "read the first line of a ~vpopmail/etc/_____ file" and use that.
also, you would want to add something other than just RELAYCLIENT to your dynamic lines, maybe something like "VPOPMAIL_DYNAMIC=\"1\"", so that the script which reads the smtpd access control list would recognize that as an entry which was dynamically added, and ignore it.
but the overall idea is to minimize the amount of code you're changing in vpopmail itself, and make the whole "update the cdb file" process an externally driven thing. (yes, i'm actually thinking of the same "separation of functions" idea that i used when wrote the "onchange" patch- when the time comes it checks for the existence of a script, and if so, it runs it. anything beyond that is up to the script, and therefore requires no further changes to vpopmail itself.)
This will preserve the ability to run vpopmail in exactly the same manneras it currently is, but move in the direction of eliminatingauth-before-smtp relaying as the default method AND improving the ability to use auth-before-smtp for other access control methods. Plus, it gives people options without requiring them to be set if they don't use them.Thoughts?
actually, yes... i just had an even better idea, the ultimate in flexibility.
just as my "onchange" patch calls a ~vpopmail/etc/onchange script whenever something changes about the accounts, what about calling a ~vpopmail/etc/onauth script whenever somebody authenticates, and just leaving vpopmail's direct involvement at that?
look at the 5.4.18 source code for the call_onchange() function (at the end of vpopmail.c), see how it works, and how it gets called from various places in the code. then consider writing a call_onauth() function similar to that, and then calling it from the appropriate place(s?) in vchkpw.c.
then the whole process of modifying the smtp server's access control, and the logic behind when you do and don't update the list, all becomes part of the external scripting. this "onauth" script could also be used to drive a situation where somebody wants to log authentications to some other storage media, like a database- or to update a "last auth" timer in a database or LDAP server, or for any number of other purposes.
then, you would write some kind of external script to manage the whole process of building the smtp access control file. that scripting could do whatever checking of static entries you like, and you can play with different scenarios in terms of making it work, without having to do any further patches to vpopmail.
the only thing to keep in mind is that the "onauth" script itself needs to run as quickly as possible, because whatever service the user is logging into, is waiting for it to finish. this is why my own "onchange" script simply sends its command line arguments to a named pipe, where an "update-qmail" service is waiting for the data... that service actually does all of the work while the script exits and vpopmail lets the user get back to what they were doing.
and then you could write a dedicated service, to run under daemontools, which would track which IP's are authorized and their timeout values, and would rebuild the smtp access control file whenever it needs to be changed... it could even run as root if needed (which it probably would, if it's going to be updating the smtp service's access control file.)
but by moving all of this logic out of vpopmail itself, you make it a lot easier to write and maintain the relay-after-pop3 code yourself. in fact you could even split that off into a separate project, and vpopmail's only involvement would be to provide that hook to run your script when needed.
and if you like, i'll even help you design and write the daemontools service to watch the pipe and handle timeouts as they happen. even though i think relay-after-pop3 is a bad idea, i'd rather see it moved out of vpopmail proper as soon as possible, especially if somebody like yourself is willing to take ownership of the code and maintain it going into the future.
---------------------------------------------------------------- | John M. Simpson --- KG4ZOW --- Programmer At Large | | http://www.jms1.net/ <[EMAIL PROTECTED]> | ---------------------------------------------------------------- | http://video.google.com/videoplay?docid=-4312730277175242198 | ----------------------------------------------------------------
PGP.sig
Description: This is a digitally signed message part
