Rick Widmer wrote: > John Simpson wrote: > >> you're right, the "onauth" code itself is simple- i could probably >> write it in about fifteen minutes, and i'm sure several other people >> could as well. > > yeah, > > vi vpopmail.c > > duplicate the existing call_onchange function > > <line range of new function>s/change/auth/g > <line range of new function>s/CHANGE/AUTH/g > > then... > > grep POP_AUTH_OPEN_RELAY *.[c,h] > > Replace what ever it finds with a call to call_onauth if needed. Keep > track of what you remove, as you need to analyze it to decide what parms > to send to call_onauth, and probably write a script for each (supported) > backend that does the same thing. > > Not bad, there are only 14 instances... and you probably won't have to > do anything but delete some of them. Be sure to keep the ifdefs around > any calls to call_onauth, we still want to require the same ./configure > option to enable the functionality. > Should be simple enough - I haven't had a chance to look at 5.4.18 yet, so I'm not sure what the new code looks like and if any changes other than that will be needed.
>> what we need is to decide exactly what the interface will be when the >> script when it gets run (i.e. what gets passed on the command line, and >> what environment variables are passed.) what i see is the following: >> >> command line arguments: >> timestamp i.e. sprintf("%lu",time()) >> service pop3, imap, smtp >> [EMAIL PROTECTED] > > <snip> > >> thoughts? > > You need the remote IP address to handle the existing functionality from > the command line parms, so yes I think it should be there. > > The timestamp is an interesting idea. I would have left it to the > script to find out what time it was called, if it cared. It sure makes > a logger easy. > > I'm willing to assume the environment of the calling program is > acceptable until such time as someone shows a reason to build a custom > environment for the script. > OK, it looks like there are several tasks that need to be done, in several phases. 1) Implement the onauth hook and document the API (should be simple, unless there need to be changes to the onchange functionality, plus the design work to make sure the API isn't going to need to be redone because we forgot about something). Add --enable-onauth-script to configure as a forward-looking replacement for the roaming-users functionality. Plan to include in 5.4.19. 2) Create a new program (vrelayupdate?) that calls the existing code that gets defined if POP_AUTH_OPEN_RELAY is defined using the new API, but link against the existing code in libvpopmail.a for now. Change vchkpw to call the onauth API and document that the new program should be used as the onauth program to duplicate existing functionality. Deprecate the relay update functionality and document that it will no longer be part of later releases. I expect to get this into 5.4.19 as well. 3) Remove the non-common code used for updating the relay table and rebuilding the relay cdb from the core vpopmail and move it into the vrelayupdate program or it's support files. Move everything into the contrib directory and provide a method for building it to match the configuration of vpopmail. It will still link against libvpopmail so that the various common functions will still be available, but all auth-before-smtp-relay-specific functionality will be moved out of the vpopmail code. Plan this for 5.4.20 or 5.4.21, depending on how long this takes. Possibly have the code moved for 5.4.20 but not move the program to contrib until 5.4.21. In any case, at that point pop-before-smtp will officially be removed from vpopmail, and will be supported only through external scripts. Also, --enable-roaming-users, --disable-rebuild-tcpserver-file and --enable-relay-clear-minutes=# will be removed from configure and any use related to that will require --enable-onauth-script instead. 4) Possibly remove the authentication logging from vpopmailand make it external, but a quick look at the code shows ENABLE_AUTH_LOGGING to be pervasive and less likely to be a candidate for an external function, although maybe just the call to it could be migrated outside (since vuserinfo, vpopmaild and vdeloldusers all make user of it in addition to vchkpw). I need to do a little more looking to see what the exact API should be (i.e., what info gets passed to the onauth script, but I expect it won't be much different than what's been discussed here. It's mostly a matter of walking the code so that I understand it to my satisfaction and think about what else I can make a good argument for having available when making the call. I'm leaning towards the timestamp, but I'll here arguments on both sides. And for now I agree that there's no good reason to much with the calling environment... 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]