Bug 733187 - sieveshell quietly fails following upgrade
Summary: sieveshell quietly fails following upgrade
Alias: None
Product: Fedora
Classification: Fedora
Component: cyrus-imapd
Version: 15
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Michal Hlavinka
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-25 04:49 UTC by Philip Prindeville
Modified: 2011-11-11 10:43 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-11-11 10:43:18 UTC

Attachments (Terms of Use)
strace of failing run of sieve (141.18 KB, text/plain)
2011-11-10 18:58 UTC, Philip Prindeville
no flags Details

Description Philip Prindeville 2011-08-25 04:49:18 UTC
Description of problem:

I upgraded cyrus-imapd to the pending Koji build after encountering bug 729767.

Then when running sieveshell, I saw:

[philipp@builder ~]$ sieveshell --user philipp mail
connecting to mail
unable to connect to server at /usr/bin/sieveshell line 170.
[philipp@builder ~]$ 

Version-Release number of selected component (if applicable):


on the client, and on the server:


How reproducible:


Steps to Reproduce:
Actual results:

Fails to connect.

Expected results:

Successful connection.

Additional info:

Comment 1 Michal Hlavinka 2011-08-25 07:54:59 UTC
how did you updated cyrus-imapd? It's not installable right now, because it needs libdb-utils. libdb-utils conflict with db4-utils, requirement of rpm.

Comment 2 Philip Prindeville 2011-08-25 15:55:28 UTC
(In reply to comment #1)
> how did you updated cyrus-imapd? It's not installable right now, because it
> needs libdb-utils. libdb-utils conflict with db4-utils, requirement of rpm.

It had already been installed on the client.

On the server side, I removed db4-utils (--nodeps), installed libdb-utils, and then updated cyrus-imapd*.

Comment 3 Philip Prindeville 2011-10-23 21:26:35 UTC
Can someone call out in the bug notes what needs to be done to fix this?

Comment 4 Michal Hlavinka 2011-11-10 15:58:19 UTC
OK, I've finally got to this one, but it works for me (tested with cyrus-imapd-2.4.12-1)

$ sieveshell --user mhlavink localhost
connecting to localhost
Please enter your password: 

please retest with latest cyrus-imapd packages, if it still does not work for you:
- attach your config files
- check all log files (messages, secure and maillog), anything there?
- do you have the same version on client and server?
- does it work on server?

Comment 5 Philip Prindeville 2011-11-10 18:58:58 UTC
Created attachment 532909 [details]
strace of failing run of sieve

Builder ( is the client. Mail ( is the server. Both are running 2.4.12-1

Comment 6 Philip Prindeville 2011-11-10 19:16:40 UTC
Hmm...  Also noticed:

[philipp@builder ~]$ sivtest -u user -w 'password' -r mail -m digest-md5 mail
S: "IMPLEMENTATION" "Cyrus timsieved v2.4.12-Fedora-RPM-2.4.12-1.fc15"
S: "SIEVE" "comparator-i;ascii-numeric fileinto reject vacation imapflags notify envelope relational regex subaddress copy"
Authentication failed. no mechanism available
Security strength factor: 0
OK "Logout Complete"
Connection closed.
[philipp@builder ~]$ 

Does sieve not support MD5-based challenge/response authentication?

Comment 7 Philip Prindeville 2011-11-10 19:40:59 UTC
Ok, I'm an idiot. The problem was unrelated to the db4-utils stuff.

It had to do instead with cyrus-sasl-md5 having been orphaned then removed during the upgrade; Sendmail continued to work because you don't need cyrus-sasl-md5 to implement digest-md5, just cram-md5... so authentication was continuing to work in Sendmail but failing in sieveshell... only it didn't look like a failure until I manually ran sivtest and verified. Re-installing cyrus-sasl-md5 fixed sivtest and sieveshell.

Sieveshell was bombing out with a meaningless message that should have said "SASL required for authentication but SASL runtime not detected" or something similar instead of "unable to connect to server ...".

Given that sieveshell is built around perldoc Cyrus::SIEVE::managesieve, which in turn is poorly documented, I'm guessing there's no point in opening a separate bug to get the error reporting improved (and that would need to be done upstream anyway).

Let's go ahead and close this bug.

Note You need to log in before you can comment on or make changes to this bug.