HoneyCollector

TODO: nifty Graphic

Description

Counter part of the Doorman HoneyPot. It receives honey-flagged mails and either collects them in a Spam archive (for later later manual evaluation) and/or trains them into your active anti SPAM modules (eg CRM114, DSPAM and so on).

Whether the mails are stored, trained or both, they are automatically dropped afterwards and not processed further.

HoneyPot and HoneyCollector

Why two separate modules? The HoneyPot himself, being in the Doorman realm, cannot access any MIME parts of the mail. For most applications, it will probably enough to put out honey (domains, addresses) and block anybody sending to it by their IP. The combined usage of HoneyPot and HoneyCollector will probably only be used for short period of time, when you want to create new SPAM database for initial training your SPAM filters. So, most of the time the HoneyPot will suffice. As he does not need the full mail, he is in the Doorman space. Thats why.

Configuration

archive_dir

Allowed values: String (path name with variables)
Default: -

As in the Archive module, the mails are stored in this directory. The directory might contain variable names and will create non existing directories on the fly.

If archive_dir is not set, no SPAM mails will be stored (useful if you only plan to use training).

Variables are:

Examples

Each mail has to be unique, therefore the (unix) timestamp and a random, 6 char length string will be suffixed.

train

Allowed values: 0 or 1
Default: 0

Whether training is enabled. If so, any used Detective anti SPAM module which is capable of training will be feeded with the honey-potted mails.

Example

---

disable: 0
archive_dir: /var/spool/decency/honey/%ymd%/%recipient_domain%/%recipient_prefix%
train: 1

Performance

The archiving is fast (only copy file from A to B), the training can be exhaustive (depends on the used SPAM filters and how they are configured and so on).