Thoughts about LUA and policy hooks

My current thinking is to have two policy hooks in opendkim that would call user-defined LUA scripts.

The first one would be called during the end-of-header handling milter call. At this point we have all the header fields we will get, and we know whether or not we will want to add signatures to the message. The LUA script called here would get access to the headers and the client information and thus can decide which key(s) should be used to sign the message, whether or not to use "l=", etc.

The second one would be called during the end-of-message handling milter call when verifying. At this point the whole message has been received, the signatures have been evaluated and the policy query has been done. We can provide all of this data to the second LUA script and it can decide whether the message should be accepted, rejected, redirected, quarantined, etc.

So first discussion point: Is this sufficient? Should we have LUA script available at both points for both modes? I can't imagine what we might want to do at EOH in the verify-only case, for example; that is, I can't think of anything useful the user's policy might want to do here. Similarly, I can't think of what would happen at EOM in the signing case that might require user input that wasn't already done at EOH.

If all of that is settled (heh), then the next thing I need to do is figure out which hooks have to be provided in both directions for each of the scripts; that is, what things does the script need to be able to get from opendkim/libopendkim, and what stuff does it need to be able to return. So far here's what I have:

RETRIEVE FROM OPENDKIM/LIBOPENDKIM:
        request DB handle (e.g. get the DB handle for internal hosts, signing domains, etc.)
        query a DB for membership
        request From domain
        request source hostname/IP address
        domain is signable?
        source is signable?
        retrieve arbitrary header/value

        retrieve Nth signature
        retrieve d= value from signature
        retrieve i= value from signature
        retrieve signature result (pass/fail/error)
        did signature use "l="?
        how big was the body?
        Which canonicalizations were used?
        ADSP?

SEND BACK TO OPENDKIM:
        request a signature (domain, selector)
        request an "l=" tag
        request a "z=" tag

        set result code (accept, reject, discard, tempfail)
        set SMTP reply text
        quarantine, quarantine reason string
        redirect address
        recipient add address

Have I missed any capabilities we'll need to provide to policy script writers?
Received on Thu Nov 19 2009 - 22:54:40 PST