cyrusimap / cyrus-imapd

Cyrus IMAP is an email, contacts and calendar server
http://cyrusimap.org
Other
534 stars 146 forks source link

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

Closed brong closed 13 years ago

brong commented 13 years ago

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

brong commented 13 years ago

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

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 commented 13 years ago

From: Bron Gondwana

I'll look at this one.

brong commented 13 years ago

From: John Lane

Tested again this evening and can confirm that

brong commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

From: Jeroen van Meeuwen (Kolab Systems)

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