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.


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.

Reply via email to