Relationship Graph

Relationship Graph
related to related to child of child of duplicate of duplicate of

View Issue Details

IDProjectCategoryView StatusLast Update
0003636SOGoBackend Mailpublic2019-11-11 15:26
ReporterGhostbird Assigned Toludovic  
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionfixed 
OSDebianOS Version9 
Product Version3.0.2 
Fixed in Version4.2.0 
Summary0003636: SOGo Sieve architecture weird
Description

In older issues about the Sieve system I find comments by ludovic of this sort:
-- "You shouldn't manipulate Sieve scripts behind SOGo's back."

This, in my opinion, shows a weird design error in the way SOGo treats Sieve.

Sieve consists of a server and a client (e.g. SOGo). However, SOGo kind of behaves as if it is a Sieve server, even though it is a client.
My intention is not to say SOGo's functionality is wrong. I'm saying that the implementation is incorrectly executed. What SOGo currently does is server behaviour in a client.
It should either behave as a client, or it should implement a sieve server itself. It just should not connect to a server as a client, then disregard the server itself entirely, and just push its own sieves.

The biggest issue that arises is this:

If a user changes his sieve on the server, using a sieve client that is not SOGo (e.g. Thunderbird, gsieve), SOGo will blindly revert that change. That is not client behaviour. The client should accept that the server is leading, and that it is not the only client that may connect to the server (otherwise the client server architecture is meaningless)

Currently the workaround is to disable the Sieve functionality in SOGo, that way every Sieve client will work except SOGo, otherwise, no Sieve-client works, except SOGo.

Personally I think it would require the least work if SOGo worked as a pure client, and played nice with other Sieve clients. However it would be good as well if SOGo implemented a Sieve server, and let other clients connect to modify the sieves.

I don't expect this change to come quickly (or at all), but I would expect the SOGo developers to give this some serious consideration, since the current behaviour is (in my opinion) ugly and hackish, by using a client-server protocol the wrong way around.

Note: I do not have any problems with SOGo features such as automatically disabling vacation auto-replies, because in doing this SOGo correctly functions as a Sieve client.

TagsNo tags attached.

Relationships

has duplicate 0003871 resolvedludovic Sogo overwrites sieve configuration 

Activities

RichiH

RichiH

2016-06-06 07:07

reporter   ~0010300

I agree with Ghostbird, though this comment is mainly to subscribe myself to updates on this issue.

ggiesen

ggiesen

2017-07-06 15:59

reporter   ~0012047

I'm encountering the same problem, using manually edited sieve files or thunderbird. Ideally using the managesieve protocol I should be able to edit the same ruleset from any of the above or SoGo and the changes would all be reflected in the others.

aort

aort

2018-08-13 16:50

reporter   ~0012995

I fully agree, the Sieve implementation has a design issue. It is a pity because the web interface is pretty well designed for rules that most users need.

But with the managesieve protocol, I can import/export large number of sieve rules. I can also view & edit them from any email client, such as thunderbird, as the web interface is not the only mail client I will be using.

If too complex, maybe a simplified version (e.g. externally imported rule are read only in the web interface) ?

ludovic

ludovic

2019-11-11 15:26

administrator   ~0013888

https://github.com/inverse-inc/sogo/commit/ac91a303c9e688790410180e4b50afe5a0a86414

Issue History

Date Modified Username Field Change
2016-04-21 09:08 Ghostbird New Issue
2016-06-06 07:07 RichiH Note Added: 0010300
2016-10-27 06:54 Christian Mack Relationship added has duplicate 0003871
2017-07-06 15:59 ggiesen Note Added: 0012047
2018-08-13 16:50 aort Note Added: 0012995
2019-11-11 15:26 ludovic Note Added: 0013888
2019-11-11 15:26 ludovic Status new => resolved
2019-11-11 15:26 ludovic Fixed in Version => 4.2.0
2019-11-11 15:26 ludovic Resolution open => fixed
2019-11-11 15:26 ludovic Assigned To => ludovic