sieve doesn't work

Phil Pennock info-cyrus-spodhuis at
Fri Aug 25 13:22:22 EDT 2006

On 2006-08-25 at 15:45 +0200, Martin G.H. Minkler wrote:
> sasl_mech_list: PLAIN LOGIN
> sasl_minimum_layer: 256

> :~# sieveshell --user=cyrus --auth=cyrus localhost
> connecting to localhost
> unable to connect to server at /usr/bin/sieveshell line 174.

It would be good if you can make that change which I suggested, of
adding "$!" into the die line.  The Cyrus::SIEVE::managesieve XS code
very carefully sets globalerr to an informative message, which
sieveshell doesn't bother reporting.

> Could it have to do with the sasl_minimum_layer setting?

Everything, yes.

> If TLS is disabled for sieve via the key file settings, does the 
> sasl_minimum_layer setting still override this?

Yes.  SASL introduces its _own_ security layers.  Implementations can
also map external protection into SASL layers and this is normally done
with TLS, so that SASL is aware of the external protection.  Without
TLS, this effectively means you need to be using GSSAPI, DIGEST-MD5 or
some other SASL mechanism which can negotiate a confidentiality layer.

If you're only supporting PLAIN and LOGIN then without TLS you need a
minimum of 0.

What you can do is set service-specific values in imapd.conf.  For
instance, on a server at work I set:

sasl_minimum_layer: 1
sieve_sasl_minimum_layer: 0

So most access needs to do something to at least ensure integrity,
whilst sieve access lets us use a sieve extension to squirrelmail, which
can't handle the concept of security layers.

"Everything has three factors: politics, money, and the right way to do it.
 In that order."  -- Gary Donahue

More information about the Info-cyrus mailing list