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]
