[RFC] policy API

From: Daniel Black <daniel.subs_at_internode.on.net>
Date: Sun, 11 Oct 2009 21:50:21 +1100

small disclaimer up front - I haven't looked a lot at the libopendkim api and
the opendkim implementation I'm a little rusty on.

This API is designed on the premise of low latency. The milter API and
opendkim performance/'memory design may limit how this is implemented.

Through the milter processing of the email, opendkim will give the
policydaemon messages based on email content as they become available. These
messages are assumed to be all related to the same email so no email ID
specified here though it will need to be there in the API/protocol somehow.

opendkim messages to policydaemon:

* connect {source IP} - new connection from source IP
* sender {email} - envelope sender - MAIL FROM
* recipient {email} - recipient email - RCPT TO
* dkim signature {uniqID} {dkim params} - a opendkim generated uniqID with the
parameters of a DKIM-Signature header field
* header {header field} {value} - header field from email (probably should
have some defaults here like From:, To:, CC:, Sender:)
* milter {param} {value} - name,value pair from requested milter-req
* result {DKIM/ASDP} - results from standard verification of the message
according to the RFC (Authenticated-Results format fields)
* eom - to indicate that the end of message has been reached and the
policydaemon needs to decide what to do to the message
* eoh - end of header reached

policydaemon messages to opendkim:

* validate {uniqID} - tell opendkim to validate signature {uniqID} and add a
AR header
* novalidate {uniqID} - don't validate uniqueID
* sign {uniqID} {DKIM-signature params} - tell opendkim to add a signature
with the specified parameters.
* nosign - the policydaemon is not going to request a signing operation -
allows opendkim to free buffers
* adsp {domain} - validate against the ADSP domain and add AR header
* header-req {header field} - request the header fields be provided
* milter-req {milter param} - request a milter value/macro
* addheader {headerfield} {text} - add a header field to the email

final messages - no further opendkim processing needs to occur after these
messages.
* reject {code/text} - reject the message immediately
* drop - discard email immediately
* tempfail {code/temp} - cause a temp fail SMTP code
* accept - finish signing and verification operations and accept the email
* redirect {mailbox} - redirect the email to mailbox after
signing/verification is completed
* quarantine - quarantine email after signing/verification

I'm thinking all of these can be non-blocking except the eom. Once an eom
message is received the policydaemon has to make a final message as to what to
do with the email.

eoh may need to be blocking and acknowledged (new policydaemon to opendkim
message eoh-ack) to prevent signing /verification requests starting a large
way into the body processing.

The milter API requires some actions to be declared up front so this would
need to be declared somehow.
Received on Sun Oct 11 2009 - 10:50:32 PST