Quoting Johannes Berg <[EMAIL PROTECTED]>:
> plugin { > (...) > pipe = /var/learn/%u/.spam:spamc -d some.host -L spam > pipe2 = /var/learn/%u/.ham:spamc -d some.host -L ham > (...) And here I define that any message stored to /var/learn/%u/.spam where %u is the username (that is learn.spam in the user's IMAP namespace) has to be piped to the "spamc -d some.host -L spam" command. And the same for ham.The above is why I like my antispam plugin much better: you can push into *any* folder *from* spam to train as ham.
It certainly is a matter of taste, but that also was the reason why I did not like your plugin... ;-)
Firstly, if a message is correctly identified as a spam, but I want to keep it a copy for some reason, copying outside the spam plugin means learning as ham, so I have to copy it again into the spam plugin to re-learn it as ham.
Sencondly, I don't know how dspam works, but spamassassin can identify a message as HAM or SPAM without learning it. If I want to learn a message correctly identified as spam but not auto-learnt, I have again to move it out of the spam folder and then back in. The same if a message is correctly identified by ham but not auto-learnt, I have to move it to the spam folder and then out of it.
Lastly, I'd prefer my user to make some explicit action to learn a message rather than have a system that somewhat "guesses" for them...
I do think, however, that the two plugins could possibly converge.
I don't think they can converge, they work in very different ways, since yours work at the IMAP level while mine works at the storage level.
Hence, mine can also be triggered by a delivery with dovecot's deliver, but when a message is copied or appended, it does not know where it comes from (but as far as I am concerned, since I don't like triggering when moving a message out of a folder, it does not matter). On the other hand, yours only works with IMAP, overriding the COPY command.
That would entail being able to specify pipes with two endpoints, right now you just have the destination folder. In order to do that, the plugin would have to be configurable like this, with the pipes tried in the order they are numbered: # learn into spam as spam pipe.1 = *>SPAM |/learn/as --spam pipe.2 = UNSURE>SPAM |/learn/as --spam # forbid into unsure pipe.3 = *>UNSURE - # learn from unsure or spam folder as ham pipe.4 = UNSURE>* |/learn/as --ham pipe.5 = SPAM>* |/learn/as --ham
Those only work if you consider messages that are copied from a folder to a different one. But how do you deal with messages that are appended from another source (such as messages being delivered or appended by an IMAP client)?
This would allow writing a simple plugin, having dovecot load it (before the pipe plugin) and having a function in that plugin called, splitting the work the antispam plugin would do in that case into two plugins. I guess that such a plugin is actually more generic than "pipe" then.
It looks to me that you only consider spam/ham learning as a use for such a plugin. I think other uses are possible. For example, I remember someone who was willing to implement an outbox.
Do you have the pipe plugin code in git anywhere I can pull from and see if I can do such modifications?
No, I have never used git. But you have the tarball. Cheers, Nicolas
