blob: 8f034be6dc91bda44421b3450ab89daef6aacedb (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
This file contains just some notes/thoughts on various implementation issues
for other backends or different things.
SQL-based logger for later training
- use dovecot's dict API
- configuration:
antispam_dict_uri = ...
antispam_dict_username = ...
- backend implementation:
1) dict_init(uri, username)
2) dict_transaction_begin
3) for each signature:
dict_atomic_inc(signature, comes_from_spam_folder ? 1 : -1)
4) dict_transaction_commit
5) dict_deinit
- later training implementation, to be atomic, needs to use transactions
to get a list of all values and delete them at the same time, or use a
temporary table that is copied from the original while the original is
emptied (again, atomically)
Full-message availability
Pristine retraining or SpamAssassin retraining might need the full message
available. This can easily be implemented since the backend is passed each
struct mail *mail that is moved.
|
