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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
|
The SpamAssassin Network Protocol
=================================
(This document is still a draft)
Synopsis
--------
The protocol for communication between spamc/spamd is somewhat HTTP like. The
conversation looks like:
spamc --> PROCESS SPAMC/1.2
spamc --> Content-length: <size>
(optional) spamc --> User: <username>
spamc --> \r\n [blank line]
spamc --> --message sent here--
spamd --> SPAMD/1.1 0 EX_OK
spamd --> Content-length: <size>
spamd --> \r\n [blank line]
spamd --> --processed message sent here--
After each side is done writing, it shuts down its side of the connection.
The first line from spamc is the command for spamd to execute (PROCESS a
message is the command in protocol<=1.2) followed by the protocol version.
The first line of the response from spamd is the protocol version (note this is
SPAMD here, where it was SPAMC on the other side) followed by a response code
from sysexits.h followed by a response message string which describes the error
if there was one. If the response code is not 0, then the processed message
will not be sent, and the socket will be closed after the first line is sent.
Commands
--------
The following commands are defined as of protocol 1.2:
CHECK -- Just check if the passed message is spam or not and reply as
described below
SYMBOLS -- Check if message is spam or not, and return score plus list
of symbols hit
REPORT -- Check if message is spam or not, and return score plus report
REPORT_IFSPAM -- Check if message is spam or not, and return score plus report
if the message is spam
SKIP -- Ignore this message -- client opened connection then changed
its mind
PING -- Return a confirmation that spamd is alive.
PROCESS -- Process this message as described above and return modified
message
TELL -- Tell what type of we are to process and what should be done
with that message. This includes setting or removing a local
or a remote database (learning, reporting, forgetting, revoking).
CHECK command returns just a header (terminated by "\r\n\r\n") with the first
line as for PROCESS (ie a response code and message), and then a header called
"Spam:" with value of either "True" or "False", then a semi-colon, and then the
score for this message, " / " then the threshold. So the entire response looks
like either:
SPAMD/1.1 0 EX_OK
Spam: True ; 15 / 5
or
SPAMD/1.1 0 EX_OK
Spam: False ; 2 / 5
There may be additional headers following the "Spam:" header, which
are as yet undefined. Clients should ignore these, and keep looking for
headers which they do support, or the "\r\n\r\n" end-of-headers marker.
SYMBOLS command returns the same as CHECK, followed by a line listing all the
rule names, separated by commas. Note that some versions of the protocol
terminate this line with "\r\n", and some do not, due to an oversight; so
clients should be flexible on whether or not a CR-LF pair follows
the symbol text, and how many CR-LFs there are.
REPORT command returns the same as CHECK, followed immediately by the report
generated by spamd:
SPAMD/1.1 0 EX_OK
Spam: False ; 2 / 5
This mail is probably spam. The original message has been attached
along with this report, so you can recognize or block similar unwanted
mail in future. See http://spamassassin.apache.org/tag/ for more details.
[...]
Note that the superfluous-score/threshold-line bug that appeared in
SpamAssassin 2.5x is fixed.
Clients should be flexible on whether or not a CR-LF pair follows
the report text, and how many CR-LFs there are.
REPORT_IFSPAM returns the same as REPORT if the message is spam, or nothing at
all if the message is non-spam.
The PING command does not actually trigger any spam checking, and (as with
SKIP) no additional input is expected. It returns a simple confirmation
response, like this:
SPAMD/1.2 0 PONG
This facility may be useful for monitoring programs which wish to check that
the daemon is alive and providing at least a basic response within a reasonable
time frame.
TELL accepts three new headers, Message-class, Set and Remove and will return
two possible headers, DidSet and DidRemove which indicate which action was
taken. It is up to the caller to determine if the proper action happened. Here
are some examples:
To learn a message as spam:
TELL SPAMC/1.3
Message-class: spam
Set: local
To forget a learned message:
TELL SPAMC/1.3
Remove: local
To report a spam message:
TELL SPAMC/1.3
Message-class: spam
Set: local, remove
To revoke a ham message:
TELL SPAMC/1.3
Message-class: spam
Set: local
Remove: remote
|
