Why should they interact at all ?^

In short: to reduce false-positives and false-negatives.

Imagine the following:
On the policy side, the incoming mail hits one big blacklist but your threshold and experience says: could be ham, still. So you let it pass and it reaches the content filter. Here now, theres is a negative DKIM check which indicates the mail originated from the wrong mail server. If you would be “there” in person, you would see: yes, the mail is spam. But you are not, so the automated filter has to decide. Each of those checks did not imply for sure that the mail is spam. But bringing them together the content filter can see the “whole picture” and decide: it is spam. Of course, you could simply increase each score (either policy or content filter) but this would give you lot’s of false-positives. Combining the two scoring results just gives you the right decision.

So how does this work with decency ?^

In contrast to many other solutions decency does implement policies AND a content filter (not only one of those). The advantage of this is: blacklists, greylists and everything that can be decided for sure before you receive the whole mail will be decided before receiving. All the decisions,  that require more “in depth” analyses have to be done by the content filter afterwards.

The policy server communicates with the content filter either via the header+cache or via a header (X-Decency-Instance, it will be removed before delivery).

Via Cache^

Both, your policies and your content filters are on the same machine and use the same cache OR are on the same (local) network and use the same network cache (memcached). In this case the policy results will be transported via the cache. It is save to say that this is save. You don’t have to enable this, it works out of the box, as long as policy and content filter use the same cache.

Via Header^

You have to enable this in the policy and content filter config. This goes in the policy file:

forward_scoring: 1
forward_sign_key: /etc/decency/sign.key

And this in the content filter file:

accept_scoring: 1
policy_verify_key: /etc/decency/sign.pub

Ok, to be honest, you can leave out the forward_sign_key and the policy_verify_key, but this would render open a “scoring injection” for spammers which you don’t want.

You can generate the sign.key and sign.pub like this:

# create private key for the policy server:
openssl genrsa -out sign.key
# extract public key for the content filter server:
openssl rsa -in sign.key -pubout -out sign.pub

Layout: one shared cache^

[caption id="attachment_579" align="alignnone" width="570" caption="Communication with internal cache"][/caption]

Layout: external MX, separate caches^

[caption id="attachment_580" align="alignnone" width="570" caption="Communication without cache"][/caption]