Re: [RFC] policy API

From: SM <sm_at_resistor.net>
Date: Fri, 16 Oct 2009 08:16:43 -0700

Hi Daniel,
At 03:50 11-10-2009, Daniel Black wrote:
>small disclaimer up front - I haven't looked a lot at the libopendkim api and
>the opendkim implementation I'm a little rusty on.

There are HTML files under libopendkim/docs that document the API.

>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.

The policy daemon is like exporting the information we get through
the milter to a separate application where evaluation is done. If we
also want the DKIM information there, we might as well do the DKIM
verification in the daemon.

>opendkim messages to policydaemon:
>
>* connect {source IP} - new connection from source IP
>* sender {email} - envelope sender - MAIL FROM

That means having a milter that passes all the information to the daemon.

>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

And have the daemon send the above information to the milter.

>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.

We would have to write two applications, the daemon and the new
milter. Are these changes worth it?

Regards,
-sm
Received on Fri Oct 16 2009 - 15:17:13 PST