[SOGo] Empty string matches all in sieve's :contains

[gaz_da]

Gentlemen,

Subject contains: empty as a mail rule criterion is accepted by SOGo Web
Client and it creates an all-matching criterion in the Sieve script. 
A user of mine has unintentionally created such a rule which effectively lead
to wholly unwanted forwarding of virtually all his emails to another user.

Steps to reproduce:

SOGo 1.3.9

Preferences  Mail Options  +

Filter name: f1

Mach any of the following rules:
Subject contains: something meaningful
Subject contains: empty

Perform these actions: 
Forward the message to: anotheru...@mycompany.com

Click Save and Close twice.

Unexpected behavior:
The criterion Subject contains: empty is accepted silently by SOGo Web client
and it results in the following Sieve script:
if anyof (header :contains subject something meaningful, header :contains
subject ) {
redirect anotheru...@mycompany.com;
keep;
}

Expected behavior:
Hard to say what is expected here. When I -- being an IT professional --
consider the expected behavior of contains for the  pattern, I find it
pretty intuitive: yes, every string contains an empty string.
What I see as a problem here, is that no input in the pattern field is
silently interpreted as an empty string.
I believe nobody expects an empty criterion to match everything.
SOGo web client should at least warn what such an empty criterion does an it
should offer an option to remove such a criterion.

Thanks,

Gazda
-- 
users@sogo.nu
https://inverse.ca/sogo/lists

[SOGo] ical4j GETs 501 when checking for existence of a calendar

[gaz_da]

Gentlemen,

I am trying to access a calendar of the user gazda using ical4j 1.0.1 Java
client library.
The SOGo instance I am accessing is version 1.3.9.

Here is the piece of java code:
   
CompatibilityHints.setHintEnabled(CompatibilityHints.KEY_RELAXED_UNFOLDING,
true);
   
CompatibilityHints.setHintEnabled(CompatibilityHints.KEY_RELAXED_PARSING,
true);
   
CompatibilityHints.setHintEnabled(CompatibilityHints.KEY_RELAXED_VALIDATION,
true);
URL url = new URL(https, sogo.mycompany.com, -1, /);
CalDavCalendarStore store = new
CalDavCalendarStore(-//MacTI//WOCal//EN, url, new PathResolver() {
@Override
public String getPrincipalPath(String username) {
return /SOGo/dav/ + username + /;
}
@Override
public String getUserPath(String username) {
return /SOGo/dav/ + username + /;
});
store.connect(gazda, .toCharArray());
   
CalDavCalendarCollection col =
store.getCollection(/SOGo/dav/gazda/Calendar/personal/);

The problem is that store.getCollection() internally tries to check if the
collection exists with a GET request which fails. Here is the relevant piece of
SOGo log:

192.168.0.1 - - [29/Nov/2011:10:53:41 GMT] PROPFIND /SOGo/dav/gazda/ HTTP/1.1
401 0/90 0.013 - - 0
192.168.0.1 - - [29/Nov/2011:10:53:41 GMT] PROPFIND /SOGo/dav/gazda/ HTTP/1.1
207 593/90 0.011 - - 0
192.168.0.1 - - [29/Nov/2011:10:53:41 GMT] GET
/SOGo/dav/gazda/Calendar/personal/ HTTP/1.1 401 0/0 0.005 - - 0
192.168.0.1 - - [29/Nov/2011:10:53:41 GMT] GET
/SOGo/dav/gazda/Calendar/personal/ HTTP/1.1 501 191/0 0.013 - - 0

The question is: Who is wrong? ical4j using GET or SOGo replying 501?

The whole thing works if I comment out the GET request in the ical4j code.

Thanks in advance,

Gazda
-- 
users@sogo.nu
https://inverse.ca/sogo/lists