guam status

[hede]

Hi all,

is there anyone using guam? I'm testing a debian build of guam 0.9.2-3
and it seems there's no fault tolerance at all. It simply halts in many
many cases - stalling the whole connection.

For example Claws Mail is sending special headers without a space after
the colon (within the imap APPEND command), like starting with:

X-Claws-Account-Id:2

I can reproduce this with telnet / openssl s_client and guam is
accepting "X-Claws-Account-Id: 2", it stores my demo mail. But without
the white space it's simply stalling the connection - no reaction at
all. Not even any error message. From that point on there's no reaction
at all, not even to valid commands. The crazy thing is, other headers
without a space are fine, like "X-Claws-Sign:0".

The bottom line is: currently it's impossible to send mail with claws
mail because it cannot store any mail to guam, neither drafts nor queued
mail.

I don't know if these type of headers are rfc conform, but even if not:
stopping the connection like guam does on any kind of things it doesn't
understand is a really bad habit. It's a fundamental paradigm to first
implement some kind of error handling before any other feature gets
implemented. This seems missing with guam.

regards
hede

[m***@chrisfleming.org]

I've disabled Guam, I think most people have disabled guam in
production.

Cheers
Chris

Post by hede
Hi all,
is there anyone using guam? I'm testing a debian build of guam 0.9.2-3 and
it seems there's no fault tolerance at all. It simply halts in many many
cases - stalling the whole connection.
For example Claws Mail is sending special headers without a space after the
X-Claws-Account-Id:2
I can reproduce this with telnet / openssl s_client and guam is accepting
"X-Claws-Account-Id: 2", it stores my demo mail. But without the white space
it's simply stalling the connection - no reaction at all. Not even any error
message. From that point on there's no reaction at all, not even to valid
commands. The crazy thing is, other headers without a space are fine, like
"X-Claws-Sign:0".
The bottom line is: currently it's impossible to send mail with claws mail
because it cannot store any mail to guam, neither drafts nor queued mail.
stopping the connection like guam does on any kind of things it doesn't
understand is a really bad habit. It's a fundamental paradigm to first
implement some kind of error handling before any other feature gets
implemented. This seems missing with guam.
regards
hede
_______________________________________________
users mailing list
https://lists.kolab.org/mailman/listinfo/users

[hede]

It is actually a pity since most of the things are working. It's a pity
like with so many other things - first of all unreliable infrastructure
(OBS anyone?) and orphand dev list (last mail half a year ago).

With guam I'm hit only by the problem with claws mail not being able to
store mails. Even squirrelmail is working fine. Btw: I've compiled kolab
and missing dependencies for debian 9 including a php7 compliant
squirrelmail (indeed right now without any plugins, I'm using them from
jessie right now). There's no official package for squirrelmail in
debian stretch, so I've downloaded current stable sources from SVN and
mixed them with the good old debian package in jessie. It's a really
clean folder view with guam.

http://packages.der-he.de/packages/
(currently I'm building for armhf only, for x86/AMD64 see official OBS
repository)

regards
hede

Post by m***@chrisfleming.org
I've disabled Guam, I think most people have disabled guam in
production.
Cheers
Chris

[hede]

PS: There's another one. Kolab Notes (Android) doesn't like
guams/erlangs ssl. Fo me it's working with cyrus directly but not with
guam, at least when using ssl. Unencrypted is fine with guam also, but
that's only practicable for local testing purpose.

[Skale, Franz]

Hi,
guam can be deactivated easily.
Check, that the cyrus.conf looks like this:
Services Snip:
# UNIX sockets start with a slash and are put into /var/lib/imap/sockets
SERVICES {
# add or remove based on preferences
imap cmd="imapd" listen="imap" prefork=10
imaps cmd="imapd -s -T 660" listen="imaps" prefork=10
pop3 cmd="pop3d" listen="pop3" prefork=5
pop3s cmd="pop3d -s -T 660" listen="pop3s" prefork=5
sieve cmd="timsieved" listen="sieve" prefork=0

ptloader cmd="ptloader -d9"
listen="/var/lib/imap/ptclient/ptsock" prefork=1

# these are only necessary if receiving/exporting usenet via NNTP
#nntp cmd="nntpd" listen="nntp" prefork=3
#nntps cmd="nntpd -s" listen="nntps" prefork=1

# at least one LMTP is required for delivery
#lmtp cmd="lmtpd" listen="lmtp" prefork=0
lmtpunix cmd="lmtpd" listen="/var/lib/imap/socket/lmtp" prefork=1

# this is only necessary if using notifications
notify cmd="notifyd" listen="/var/lib/imap/socket/notify"
proto="udp" prefork=1
}

Also , there's was unresolved dependency for maticore.
It has been resolved by removing the package dependency.
if you rely on manticore, you have to install it on your own.
It's a complex undertaking on debian. (node js modules).
Rgds.
Franz

Post by hede
PS: There's another one. Kolab Notes (Android) doesn't like
guams/erlangs ssl. Fo me it's working with cyrus directly but not with
guam, at least when using ssl. Unencrypted is fine with guam also, but
that's only practicable for local testing purpose.
_______________________________________________
users mailing list
https://lists.kolab.org/mailman/listinfo/users

[Matthias Busch]

I hope we all realise that directly contacting cyrus without guam is a
workaround and that guam should be fixed and not orphaned because it can
be deactivated.

it is a great piece which made the switch from kolab 3.4 to 16 well worth.