[Dovecot] "pipe" plugin - is anyone interested (or using it)?

[Nicolas Boullis]

Quoting Johannes Berg <johannes at sipsolutions.net>:

>
>> > 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