Separate sieve script

[Op3rat0r]

The sieve program (windows) gives me the opportunity to create several scripts. However, only one script can be active at a time. The behavior is correct because all rules are in one file.

I have the possibility (dovecot mailserver) to create several scripts in my webmailer "SOGo" (this is how it is suggested to the user). The individual queries / rules can be seen one below the other and can be edited / deleted individually.

It would be a great feature if you could see these individual queries / rules among each other and edit them individually. You could even deactivate individual queries by commenting out.

That would be an incredibly big plus for clarity!

Regards,
Daniel

[thsmi]

well, the manage sieve RFC explicitly limits the active script to exactly one or zero.

1.4.  Active Script

   A user may have multiple Sieve scripts on the server, yet only one
   script may be used for filtering of incoming messages.  This is the
   active script.  Users may have zero or one active script and MUST use
   the SETACTIVE command described below for changing the active script
   or disabling Sieve processing. 

And there is a good reason for that. Having more than one script active you mean you need to specify the precedence between the scripts in some way. Which would add an unnecessarily layer of complexity to the sieve protocol. Thus the specification limits this to at most one.

If you want to split the code among different scripts the normal and portable way is to use the "include" command. But this needs to be supported by your server.

If you want to deactivate a block. The normal and portable way would be to wrap this block into a if false statement. Or comment it in code but then it is no more displayed in the Graphical Editor.

And yes I know some of the Sieve UIs offer a special logic, which abuses comments to embed proprietary meta information into the sieve script and at the same time they artificially limit the complexity of scripts to a tiny subset. So that they can offer a simplified UI.

The problem with such an approach is that it is designed to fail and works horribly bad in real world scenario where you edit a script with more than one editor. This is because it is not standardized thus not portable.

It would also mean, the sieve editor would have to implement a parser for any of those meta information languages and guess correctly in which dialect was used to create this and which subset is used by the UI on the server. Or even worse define it own proprietary subset of commands which can be only understood by this sieve editor.

[Op3rat0r]

Thanks for your reply!

I understand the RFC in general. The behavior is clear to me. It's a constructive suggestion that I think would do a lot to improve usability. Means, you can see every filter/rule on by one, even if it's only one in the background. I also understand the point of view that every programm will create their own filters. Mb I can't change this rules in another editor anymore. Mb it works and you break the view in the programm you first used. I think if you are aware of this and only use one program, there are no problems.

I can manage multiple filter like in this example. For the user it looks like there are different filter rules.

Now I can have a look at this rule with the Sieve Filter tool and it shwos me only one rule. This rule I created in my SOGo backend for sure. And this provides me with a view of this different filters.

When we look into the code of this one rule

require ["fileinto"];
if allof (address :contains "from" "[email protected]") {
    fileinto "Junk";
}
if allof (address :contains "from" "[email protected]") {
    fileinto "Archive";
}

And the UI (script) view looks like this

As you mentioned, when I user the Sieve Filter tool to change the filter rule. I added another fileinto operation, I wont show up in the SOGo backend. I know, when I use the Sieve Filter tool I get the full output of the whole filter rule.

Isn't it a nice to have for the sieve filter tool, to show this one sieve script as multiple different filter rules. Mb there is a special "#name" between the filter rules egg. Sieve may not be able to do this by default. But you could at least make the appearance of the filter individually. For example there is an absence filter. This is only active on certain dates. I can go here, define it somewhere in the script and then manually comment it out. But this filter is somewhere in between all the other filters that grow over time. It was about usability / user friendliness. We as IT people can do this very easily, a normal user cannot use it.

[thsmi]

Isn't it a nice to have for the sieve filter tool, to show this one sieve script as multiple different filter rules. Mb there is a special "#name" between the filter rules egg. Sieve may not be able to do this by default. But you could at least make the appearance of the filter individually. For example there is an absence filter. This is only active on certain dates. I can go here, define it somewhere in the script and then manually comment it out. But this filter is somewhere in between all the other filters that grow over time. It was about usability / user friendliness. We as IT people can do this very easily, a normal user cannot use it.

No, honestly this would be horrible. It would be like using a hammer to get a screw into a wooden beam. If you want to have it simple just use a hammer. If you want to have it more robust and sustainable you take the screw and a screwdriver or drill.

Instead of using the existing sieve syntax you are suggesting to abuse comments to add an additional (completely proprietary) syntax and complexity layer. This is the perfect example of an anti pattern. And is designed to fail. Thus any UI which is based on this approach is also designed to fail. And the worst thing to happen to IT or non IT people is having a UI which is broken. And it is even worse if the UI is broken by design. Most IT people can help them selves but non IT people are lost.

Which was exactly the reason why this editor was created almost two decades ago. Squirrel mail screwed up and displayed wrong data in the UI because it was using comments to store meta data and because of this users lost mail and where confused why...

And honestly the target audience for this editor are IT people. They know how sieve works and know how to use it and would be confused if they won't see their scripts anymore. If you want an artificially limited editor which is simple, just use one of the numerous web UIs. If you want to unleash the full sieve power use this editor. This editor was designed to be able to display complex and deeply nested scripts. And it is doing pretty good there, but this does not come for free. So it is a matter of scopes. Combining both is like squaring the circle, and most likely none will be happy with the result.

Sieve is a complex and almost complete programming language. Way more sophisticated that other filter description languages. But this does not come for free.

Let's take a look at your example and you will see why this it the perfect example how an overly simplified UI can completely screw up a sieve filter in a single line (I have removed the useless any anyof. No idea what this should be good for, most of my test start with an allof).

if address :contains "from" "[email protected]" {

Why the heck the contains? This is strangely odd. It is an unsharp match on the address header.
It matches [email protected] matches but also [email protected] will be a perfect match.

I guess not what you wanted and not what the UI pretends it does. It is by the way technically identical to the following lines:

if address :matches "from" "*[email protected]*" {
if header :matches "from" "*[email protected]*" {
if header :contains "from" "[email protected]" {

Now let's correct the example and fix it then we endup at the following:

if address :is "from" "[email protected]" {

if header :contains "from" "<[email protected]>" {

Both lines behave similar. But they are still not doing what want them to do.
They just look at the first "from" header. They are typically nicely formatted and can be easily faked.

Instead you want to always to test the envelope. Which contains the raw mail information and is comparably difficult to fake:

if envelope :is "from" [email protected] 

As you can see we have now three different way how to test the from. And there are many more.

A header check is less reliable than an address check which is less reliable than the envelope check.
But all in all most of the time they will do the very same but are designed for different use cases.

Most sieve editors I am aware of prefer the envelope test, and thus they are most likely incompatible to the limited SOGo UI.
And this is only the tip of the ice berg in your example. The other lines do not look any better...