It certainly is a matter of taste, but that also was the reason why I
did not like your plugin... ;-)
Aha, but with what I proposed that becomes a matter of configuration, hence my SPAM>* rule in there.
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...
You can still have that, I was just expressing how my plugin works in terms of some "rules".
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.
Actually, I work at storage level too now, I modified it.
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).
Yeah, if you load it into deliver which I'd consider somewhat stupid to do with my plugin.
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)?
Good point. You could treat that as the "empty" source, like
pipe.3 = >SPAM do something
and have a wildcard that matches all (like .* RE) and one that matches "all not empty" (like .+ RE)
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.
No, but I'm using spam as an example of how your plugin could be generalised to work the same as mine with a different configuration. It seems to me that you only consider use cases that depend on the target folder while my generalisation was to make it depend on the pair (source, target).
johannes