Authorization id specified on Cyrus Deliver (-a argument) is ignored

[brong]

From: John Lane
Bugzilla-Id: 3438
Version: 2.4.7
Owner: Bron Gondwana

[brong]

From: John Lane

Following upgrade from Cyrus-IMAP 2.3.15 to 2.4.7 delivery of messages to specified mailboxes has stopped working.

Investigations would indicate that the authorization ID specified as a "-a" parameter to Cyrus "deliver" is being ignored.

System configuration information:

configdirectory: /srv/mail/cyrus
partition-default: /srv/mail/cyrus/mail
admins: cyrus
sasl_pwcheck_method: saslauthd
altnamespace: yes
unixhierarchysep: yes

This uses "altnamespace" to give folders at the same level as INBOX and uses
"unixhierarchysep" to give folder separator of "/" rather than "." (the "." is used in some folder names).

This configuration worked fine for a very long time until the upgrade.

The ACLs in place (for the auth id specified on "deliver"):

localhost.localdomain> lm user/john
user/john (\HasChildren)
localhost.localdomain> lm user/john/folder.name/subfolder
user/john/folder.name/subfolder (\HasChildren)
localhost.localdomain> lam user/john/folder.name/subfolder
john lrswipcda
localhost.localdomain> lam user/john
john lrswipcda
localhost.localdomain>

So cyradm lam shows folder.name/subfolder has p rights (amongst others) for
user john.

I have tested by applying "anyone p" to the ACL for some mailbox folders:

localhost.localdomain> sam user/john anyone p
localhost.localdomain> lam user/john
john lrswipcda
anyone p

localhost.localdomain> sam user/john/folder.name/subfolder anyone p
localhost.localdomain> lam user/john/folder.name/subfolder
john lrswipcda
anyone p

Initially on doing the above I thought "anyone p" made no difference but since then it works with "anyone p" in place (probably late night testing!).

I have now been able to switch the behaviour on/off by adding/removing "anyone p" from specific folders. I will do more testing however and report back.

Some mailbox folders have periods in the names, others don't.

The folder list is sane in imap client. Everything is working fine
except delivery into folders. All mail already delivered prior to
upgrade is in folders and perfectly readable as I would expect.

My procmail log reports like this:
procmail: Executing
"/usr/cyrus/bin/deliver,-r,xxx@xxx.com,-a,john,-m,folder.name/subfolder,john"

To test from command line I used this command
/usr/cyrus/bin/deliver -r xxx@xxx.com -a john,-m folder.name/subfolder john < testmessage

I will perform further tests to be sure, I will check

• the problem exists for all folders (regardless of the presence of periods).
• adding "anyone p" to any folder allows delivery to that folder.
• removing "anyone p" from any folder causes mail to deliver to INBOX.

Please let me know if I can provide any more information.

(initially mailing list discussion http://asg.andrew.cmu.edu/archive/message.php?mailbox=archive.info-cyrus&amp;msg=52560)

[brong]

From: Bron Gondwana

I'll look at this one.

[brong]

From: John Lane

Tested again this evening and can confirm that

• the problem exists for all folders (regardless of the presence of periods).
• adding "anyone p" to any folder allows delivery to that folder.
• removing "anyone p" from any folder causes mail to deliver to INBOX.

[brong]

From: Ingar Vindenes

We are experiencing the same bug in 2.4.8.

For users with spam-filtering activated we use exim to call the "deliver"-program with the "-m" and "-a" options to make a delivery to a "spam"-mailbox, and this does not work after upgrading to 2.4.8. I.e. the delivery is done to the inbox, unless an ACL with "anyone p" is set.

A workaround/patch for this bug would be appreciated.

[brong]

From: Øyvind Kolbu

We worked around this by letting exim deliver via lmtp over tcp instead of using
deliver(1) and a lmtp socket. This was done by adding:
lmtp cmd="lmtpd -a" listen="IP:lmtp" prefork=2
to cyrus.conf and rerouting spam mails from username@domain to
username+spam@domain, and thus let lmtpd implicitly deliver it to the
user.username.spam folder.

This solution does not require "anyone p" on the spam folder.

[brong]

From:

Just a FYI: I hit this bug too on 2.4.8 (Debian testing's 2.4.8-1 package), after upgrade from 2.2.13p1.

[brong]

From: Bron Gondwana

Can you please test with 2.4.9. I believe this was fixed by:'

Bug #3438 - offer "AUTH" capability even if preauthed

Thanks,

Bron.

[brong]

From: Øyvind Kolbu

(In reply to comment #6)
> Can you please test with 2.4.9. I believe this was fixed by:'
>
> Bug #3438 - offer "AUTH" capability even if preauthed

It works fine now, thanks!

[brong]

From: Jeroen van Meeuwen (Kolab Systems)

Updating milestone and status for the bug ;-) Thanks!