> 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 >> "roaming >> users" 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. > Whoa... I wasn't expecting that... Just don't send me flowers or anything, OK? :)
> 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. > OK, I think I'm seeing where you're going with this, and while it'll take a little design work (not to mention some help with different backends - I only use MySQL right now), I'm game. > 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. > Maybe - we'll see what works out the best after I do a detailed design on it. >> 2) Hijack the --enable-roaming-users config line to allow a different >> default set of tcpserver flags to be added. For now, the default >> would be >> '--enable-roaming-users="RELAYCLIENT=\"\",RBLSMTPD=\"\""', but once >> #1 is >> finalized 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. > Well, I was thinking that a simple way to do it under the current struction was to have --enable-roaming-users="XXX" set the default, compile-time directive, and then be able to override it at runtime (thus keeping the current behavior without any changes). But forcing runtime configuration works too, as long as it's well documented . > 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.) > If we're taking the info out of vchkpw and moving it into an external process, we can design it right from the ground up. This may involve redesigning the relay table to add more info, or have some additional tables to do lookups in, but I'm already starting to get some ideas... >> This will preserve the ability to run vpopmail in exactly the same >> manner >> as it currently is, but move in the direction of eliminating >> auth-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? > Clean, simple, flexible. I like it. :) > 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. > Will do (once it's out :)) - I'm a little busy working on a couple of other things, like releasing my Uber-Mega-qmail patch set (the patches are done, but documenting them takes time... :), but I'll add this to the queue. Since the patch isn't going into 5.4.18 anyway, there's time. > 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. > By default, vpopmail logs the last auth for most backends. This could handle that as well. > 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. > *nod* > 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. > Alternatively, vpopmail could just write to the pipe itself, but the onauth script is a cleaner method. Basically, I'd send 4 tokens to the service: user, domain, IP, timestamp. It can handle the rest. > 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.) > It should be able to run as vpopmail, since the tcp.smtp.cdb file is owned by vpopmail, and that's what gets used by qmail-smtpd. vchkpw runs as vpopmail, and it handles it all now, so I don't see a need for root access here. > 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. > Agreed. And it makes alternative development/hooks easier too. > 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. > I'd appreciate the help on the daemon, although just giving me the sampe code of your daemon would probably be good enough. I have a very long history of looking at other peoples' code and taking just the parts I need for whatever I happen to be working on - it's how I learned C in the first place 15 years ago... :) Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
