Milter-greylist

Moving a bit furhter...

dkim-milter comes with a library (libdkim), which seems a good candidate
for usage in milter-greylist.

We start by calling once dkim_init(), then dkim_verify() for each
message we want to verify. Then we call dkim_header(), dkim_eoh(),
dkim_body(), dkim_eom(), dkim_getpresult(), and dkim_free(). Each should
be called at different milter callback stages.

DKIM status are:

DKIM_STAT_OK -- successful completion 
DKIM_STAT_BADSIG -- signature did not match headers and body
DKIM_STAT_NOSIG -- no signature present 
DKIM_STAT_NOKEY -- no key available for  verifying
DKIM_STAT_CANTVRFY -- can't get key for  verifying
DKIM_STAT_SYNTAX -- message is not in  valid syntax
DKIM_STAT_NORESOURCE -- resource  unavailable
DKIM_STAT_INTERNAL -- internal error
DKIM_STAT_REVOKED -- signing key revoked
DKIM_STAT_INVALID -- invalid  
DKIM_STAT_NOTIMPLEMENT -- function not implemented
DKIM_STAT_KEYFAIL -- key retrieval failed (try again later)
DKIM_STAT_CBREJECT -- callback requested message rejection
DKIM_STAT_CBTRYAGAIN -- callback can't complete (try again later)
DKIM_STAT_CBERROR -- unspecified  callback error    
DKIM_STAT_MULTIDNSREPLY -- multiple DNS replies

We probably want to have meta-status to check in our ACL. In fact, these
migh be enough, I'm not convinced there is a need for checking the
detailed error codes. Moreover, that would prevent us from adopting a
second DKIM library later.

So here are the proposed meta-status:
pass -> ok
fail -> badsig, nokey, revoked, cbreject
none -> nosig
unknown -> cantvrfy
error -> syntax, invalid, notimplement, invalid, cberror, multidnsreply

keyfail and cbtryagain should probably just cause a tempfail, without
returning the value for testing to the ACL code.

internal is about memory allocation issues and callbacks been called in
the wrong order. That should cause the milter to exit.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...