You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@spamassassin.apache.org by pa...@apache.org on 2005/05/07 18:13:21 UTC
svn commit: r169092 - /spamassassin/trunk/spamd/PROTOCOL
Author: parker
Date: Sat May 7 09:13:20 2005
New Revision: 169092
URL: http://svn.apache.org/viewcvs?rev=169092&view=rev
Log:
Document recently added LEARN and COLLABREPORT options
Modified:
spamassassin/trunk/spamd/PROTOCOL
Modified: spamassassin/trunk/spamd/PROTOCOL
URL: http://svn.apache.org/viewcvs/spamassassin/trunk/spamd/PROTOCOL?rev=169092&r1=169091&r2=169092&view=diff
==============================================================================
--- spamassassin/trunk/spamd/PROTOCOL (original)
+++ spamassassin/trunk/spamd/PROTOCOL Sat May 7 09:13:20 2005
@@ -56,6 +56,10 @@
PROCESS -- Process this message as described above and return modified
message
+LEARN -- Learn message as spam, ham or forget.
+
+COLLABREPORT -- Send message to any configured collaborative reporting
+ databses
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
@@ -104,6 +108,9 @@
REPORT_IFSPAM returns the same as REPORT if the message is spam, or nothing at
all if the message is non-spam.
+LEARN returns just a header, Learned:, with a Yes or a No value.
+
+COLLABREPORT returns just a header, Reported:, with a Yes or a No value
The PING command does not actually trigger any spam checking, and (as with
SKIP) no additional input is expected. It returns a simple confirmation
Re: svn commit: r169092 - /spamassassin/trunk/spamd/PROTOCOL
Posted by Michael Parker <pa...@pobox.com>.
On Sat, May 07, 2005 at 05:02:58PM -0700, Daniel Quinlan wrote:
>
> So the slightly changed version would leave:
>
> the classic report as: ASSERT CLASS=SPAM SET=LOCAL,REMOTE
> the classic revoke as: ASSERT CLASS=HAM SET=LOCAL REMOVE=REMOTE
>
I like this version better. But, I think we might want make it more
http like, so it would be something like:
ASSERT SPAMC/2.0
Class: SPAM
Set: LOCAL, REMOTE
and
ASSERT SPAMC/2.0
Class: HAM
Set: LOCAL
Remove: REMOTE
Michael
Re: svn commit: r169092 - /spamassassin/trunk/spamd/PROTOCOL
Posted by Daniel Quinlan <qu...@pathname.com>.
The juicy bit of a short discussion on IRC between Michael and me:
(16:53:26) Herkemer: here was the argument when I implemented revoke
(16:53:46) Herkemer: If you're revoking then the message must be ham, so
learn it as ham, so that is what revoke does
(16:53:52) quinlan: we could allow that operation
(16:54:16) Herkemer: how do you represent that in the protocol?
(16:54:18) quinlan: ASSERT CLASS=HAM SET=LOCAL REMOVE=REMOTE
(16:54:33) Herkemer: ahhh....changed
(16:55:01) Herkemer: I actually like that better
So the slightly changed version would leave:
the classic report as: ASSERT CLASS=SPAM SET=LOCAL,REMOTE
the classic revoke as: ASSERT CLASS=HAM SET=LOCAL REMOVE=REMOTE
Or, we could switch the order around a bit:
the classic report as: ASSERT CLASS=SPAM LOCAL=SET REMOTE=SET
the classic revoke as: ASSERT CLASS=HAM LOCAL=SET REMOTE=REMOVE
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/
Re: svn commit: r169092 - /spamassassin/trunk/spamd/PROTOCOL
Posted by Daniel Quinlan <qu...@pathname.com>.
I want to avoid cluttering (stop cluttering) up the protocol with
one-off commands for each permutation of desired actions.
There are really only a few things being communicated here. I think the
entire protocol could have been 4 commands, but I'm not intent on
designing the entire protocol. I just want to keep it clean and
incrementally move towards a 2.0 protocol we'll like. Anyway, let me
step through my thinking.
--
First, roughtly what is communicated:
spamc -> spamd:
1. an action for spamd to take: ping, check, learn, report, revoke,
skip, forget, etc.
ping, skip: protocol-level commands, no email stuff going on
learn, forget, report, revoke: I'll tell you something, you do something
check: you tell me something
2. for learn/report: information about the message (spam, ham, etc.)
3. a set of expected results: success/failure, classification
(spam/ham/etc.), symbol list, a marked-up message, etc.
4. (optional) a message
spamd -> spamc
results, maybe including a message
--
That's a bit cluttered, I think I can break down the actions a bit more
cleanly.
learn, forget, report, revoke:
learn/forget are local learning actions for local databases
report/revoke are remote learning actions for remote databases
This is key: the main difference is whether or not you want to share
the information with the world or not. forget and revoke are the
same. report and learn are the same as well too (although ham is
generally not reported). Rather than separating remote and local,
we should make those flags to a single command.
check
this one is easy, it's just how much information you want back
--
So, let me try to shift over into a possible ideal protocol:
ask =>
questions (list of desired results)
message
assert =>
how => set or remove (learn/report or forget/revoke)
where => local and/or remote
what => list of classification information (spam, ham, etc.)
message
ping
skip
As far as what local and remote mean (which places to go, whether to do
AWL or Bayes or both), I think those should be configuration lest this
protocol become too complicated.
So, does this need to be 2.0? No. For 3.1, we've only added LEARN and
COLLABREPORT. Change that to:
ASSERT [SET|REMOVE] CLASS=SPAM,PHISHING WHERE=LOCAL,REMOTE
Of course, for now class is just going to be "SPAM" or "HAM". CLASS is
also not needed (ignored if set) for REMOVE.
The "ASK" interface we could add later which would later allow us to
move to spamd protocol 2.0 and drop CHECK, PROCESS, etc.
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/
Re: svn commit: r169092 - /spamassassin/trunk/spamd/PROTOCOL
Posted by Michael Parker <pa...@pobox.com>.
On Sat, May 07, 2005 at 02:01:49PM -0700, Daniel Quinlan wrote:
> parker@apache.org writes:
>
> > Document recently added LEARN and COLLABREPORT options
>
> We should really discuss these protocol changes before making them
> permanent. I'm definitely -1 on the name "COLLABREPORT", just name it
> "REPORT".
See discussion in bug 4163.
REPORT is unavailable, it is already used for something else.
Alternatives are welcome, COLLABREPORT is much better than
LISTSREPORT.
> That being said, I'm concerned that we get these right. Does the client
> have to send a message over the wire twice to LEARN and REPORT?
COLLABREPORT and LEARN work the same they do with spamassassin -r/-k
(repot_as_spam, revoke_as_ham) and sa-learn. To answer the question,
report_as_sam learns as spam and revoke_as_ham learns as ham. This
behavior can be turned off with bayes_learn_during_report.
Michael
Re: svn commit: r169092 - /spamassassin/trunk/spamd/PROTOCOL
Posted by Daniel Quinlan <qu...@pathname.com>.
parker@apache.org writes:
> Document recently added LEARN and COLLABREPORT options
We should really discuss these protocol changes before making them
permanent. I'm definitely -1 on the name "COLLABREPORT", just name it
"REPORT".
That being said, I'm concerned that we get these right. Does the client
have to send a message over the wire twice to LEARN and REPORT?
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/