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.
duplicate the existing call_onchange function
<line range of new function>s/change/auth/g
<line range of new function>s/CHANGE/AUTH/g
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.
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
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.