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
This archive was generated by hypermail 2.2.0+W3C-0.50 : Fri Oct 16 2009 - 20:50:01 PST