Defender
Table of content
Work in progress

The Defender server is a wrapper for Detective and Doorman to use Decency via the Milter interface or Postfix before-queue filtering. It does nothing by himself, so there are no modules to be configured.
How does it work ?
Most mailservers provide access to a milter interface. Postfix also has the so called before-queue or pre-queue proxy (PQP), which does basically the same (simplified) but via the SMTP protocol.
The idea is now to have a single server instead of two (Doorman and Detective). When a mail is received, first the envelope data (HELO, RCPT TO, MAIL FROM, etc) will be transmitted. On receive, it gets delegated (proxy) to the milter/PQP, which can run his tests and returns an answer (eg reject the mail or go on).
The Defender splits the received data in two parts. First it takes all envelope data before the actual DATA, when all is received, it runs the Doorman instance and checks and returns his answer. So basically, all policy checks are run first. If Doorman allows the mail (eg not blacklisted or otherwise suspicious) the DATA is received and delegated to Defender, which will check it as configured. Actually here is a small difference in the milter and PQP implementation: the PQP needs to reinject the mail whereas the milter does'nt.
So, what should i use? Defender or Doorman + Detective separate ?
Let me begin with the major benefits of milter/PQP vs two separate servers:
- It is simpler to configure (eg Postfix config)
- At least milter works with all mailservers which support milter
Well, all benefits have strings attached, here are the downsides:
- Normally you would configure many Doorman processes and far less Detective processes. Using Defender, you can only set an amount for both. So you will waste resources.
- milter: The is not received by your MTA until all checks are through. If you use lot's of checks, the mail client might time out or at least you could end up with a jammed mail server.
The major downside is, that you cannot
Configuration
Basically what you need to do is encapsulate the Doorman and Detective configuration within the Defender. All shared configuration keys (eg database, and so on) will be provided in the "main" Defender config and only the sub-server specific (eg which modules to load) will be configured in the server config context. Here a short outline:
---
mode: prequeue
database:
# ..
cache:
# ..
detective:
# ..
modules:
# ..
doorman:
# ..
modules:
# ..
reinject
Allowed values: HashRef or Array of HashRef
Default: { host: "127.0.0.1", port: 10250 }
Required: yes
Reinjection information for all to-be-passed mails (virus could be and so on). Remember to setup a MTA listening on this host/port (eg via your master.cf in postfix).
reinject.host
Can be IP or hostname.
reinject.port
The port for delivery.
reinject.copy
Defaults to 0. Set to 1 to enforce reinjection anyway.
reinject.debug
Optional. Set to 1 to print SMTP on STDERR
reinject.user
Optional. User for reinjection.
reinject.password
Optional. Password for reinjection.
reinject.ssl
Optional. Use SSL. Default 0.
# one single host
reinject:
host: 127.0.0.1
port: 10250
# multiple hosts
reinject:
-
host: 10.20.30.40
port: 10250
# failover
-
host: 10.20.30.41
port: 10250
# copy
-
host: 10.20.30.42
port: 25
copy: 1
user: someuser
pass: somepass
ssl: 1
mode
Allowed values: String (either "prequeue" or "milter")
Required: no
Default: milter
The defender can be run either as milter or pre-queue (before queue) filter.
If used in pre-queue mode, you need to configure reinject, if you use milter, you can if you want to.
defender
Allowed values: HashRef
Required: no
Default: -
detective_spam_reply
Allowed values: String
Required: no
Default: SPAM Rejected
This is the reply message for the reject code if mails are removed
detective_virus_reply
Allowed values: String
Required: no
Default: SPAM Rejected
This is the reply message for the reject code if mails are removed
=> '',
#detective_virus_reply => '',
#detective_enforce_reinject => 0,