• Home
• About
• Download
• Contact, Support & Imprint
• License & Disclaimer
• Roadmap
• Changelog
• Tutorials
  • Install
  • Configure Doorman Server
  • Configure Detective server
  • Doorman and Detective interaction
• Configuration
  • Cache & Database
  • Defender
  • Detective
    • Archive
    • Bogofilter
    • ClamAV
    • CRM114
    • DeepDNSBL
    • DKIM Sign
    • DKIM Verify
    • DSPAM
    • HoneyCollector
    • Razor
    • SpamAssassin
  • Doorman
    • Association
    • Basic
    • CWL and CBL
    • DNSBL
    • Geo Weight
    • Greylist
    • Honeypot
    • Sender Permit
    • SPF

Doorman and Detective interaction

Why should they interact at all ?

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

Imagine the following:

On the policy side (Doorman), 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 (Detective).

Here now, there is 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 a policy server (Doorman) AND a content filter (Detective) - and not only one of them! 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 requiring more "in depth" analyses have to be done by the Detective afterwards.

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

Via Cache

Both, your Doorman and your Detective 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 Doorman results will be transported via the cache. It is save to say that this is safe, as long the connection to your cache server is secured (if not, you should not use it in the first place). You don't have to enable this, it works out of the box, as long as Doorman and Detective use the same cache.

Via Header

You have to enable this in the Doorman and the Detective config. This goes in the Doorman config:

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

And this in the Detective config:

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

Ok, to be honest, you can leave out the forward_sign_key and the doorman_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

TODO

Layout: external MX, separate caches

TODO