Re: uppercase usernames

2013-03-11 Thread Joerg Maier
Hi Dan,

Thanks for you suggestion!

Unfortunately, testing the solution i have in mind, i renamed and 
finally deleted my one CamelCase testaccount. And now, when I try to 
create a mailbox with CamelCase with cyradm, the default acls are set to 
a user with lowercase username, and I am not able to set additional acls 
to a user with CamelCase with sam.

I suppose that "username_tolower: 0" just does not does what I thiought 
it did in the source installation.

The solution I want to use for my users now is:
- renaming user to lowercase in userdatabase
- renamin cyrus account with cyradm rename to lowercase
- creating a virtual forward rule, so postfix delivers the mail sent to 
CamelCase address -> camelcase (and keep lmtp_downcase_rcpt: 0 and 
username_tolower: 0 until last CamelCase adress is converted.

Thanks, Joerg


On 2013-03-11 0:29, Dan White wrote:
> On 03/10/13 23:28 +0100, Joerg Maier joerg.maier wrote:
>>Hi List,
>>
>>I am using cyrus since ~8 years for a mailserver with ~200
>>mailaccounts.
>>
>>After transferring a mailserver from cyrus 2.2 to 2.4, I have an 
>> issue
>>with usernames containing uppercase letters. Up to now, i did tread 
>> the
>>part before the @ as case sensitive, and i allowed users to create
>>mailboxes like TestCApital.
>>
>>I have set:
>>lmtp_downcase_rcpt: 0
>>username_tolower: 0
>>
>>When I try:
>>testsaslauthd -u TestCApital. -p 
>>I get
>>0: OK "Success."
>>
>>But when I try to logon via imap, i see in the logs:
>>... saslauthd[24118]: do_auth : auth failure:
>>[user=testcapital.] [service=imap] [realm=] [mech=pam]
>>[reason=PAM auth error]
>>
>>What is the best solution to work around this?
>
> Do you get the same result with imtest?

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Good webmail client software for cyrus?

2013-03-11 Thread Michel Blanc
On 10/03/2013 21:08, Charles Bradshaw wrote:
> Hi all,
>
> After much pain I have my cyrus-imap server up and working with
> sendmail. I have penetrated the configuration subtleties of serving
> virtual domains and  persuading cyrus and sendmail to co-operate using
> today's security protocols.(MD5 and TLS/SSL). 
> 
> I am now researching how to provide a HTTP (webmail style) MAU as an
> alternative to a bunch of IMAP feature lacking, or otherwise broken,
> desktop user agents.

Hi Charles / list,

Here we use RoundCube too. It's quite flexible (we achieved to use CAS
authentication in Roundcube using pam_cas with few liters of coffee), so
I suppose writing/finding a MySQL password changing tool is quite easy;
there are a few password changing plugins around
http://trac.roundcube.net/wiki/Plugin_Repository#Settings

It also supports sieve quite well, so, while we're still investigating
large scale deployment, we are quite pleased with it.

Yes, it's PHP, and I don't like it much either. However, the code is
very clear and it's quite easy to write or hack on plugins.

> I also need to source a GUI mailbox/password server management tool.
> Currently I'm using MySql Workbench for password management and cyradm
> command line for mailbox configuration.

We also use MySQL for the user database (through a custom pam_mysql).
Here we're rewriting our old management software using Ramaze (a great
Ruby web framework, much lighter than Rails). It is in it's humble
beginnings, but if you're interested, we can push the code publicly so
you can peek at it.
We might have to fiddle a bit to make things more usable for the rest of
the world before. The development is quite slow, as we are chasing many
rabbits (?) at the same time, and it's linked to our mail architecture
overhaul which takes some time too.

Our old management system used mod_perl/mysql. While you might like the
idea, the thing is really old and ugly. But it works and proved quite
reliable over the years with ~150k users. It allows password management,
virtual domains management, aliases, quota. I suppose we can publish
this one too after a code review, but don't expect any further
development on this one.

Good luck in your research.

M
-- 
Michel Blanc - Systèmes/Réseaux Erasme
Erasme/CG69/Saint Clément les Places/FR69930
T +33-474706840 
http://reseau.erasme.org
FA67 4EDA D648 9E50 BFA4 3F29 FDF5 4971 24B3 5C22

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


ACLs and cross-namespace move problem

2013-03-11 Thread Thomas Cataldo
Hi,

I have a problem with shared user mailboxes and permissions on cyrus 2.4.16.

User A has read/write access on user B ("lrswipkxte")

Folders looks like this for user A:

   INBOX
   Archive
  2012
   Other Users/ <== the user's namespace
B (user B inbox)
Sent
Drafts
Trash

User A wants to move the Archive folder to User B. He does a simple
drag&drop in thunderbird for his box to Other Users/B.

With its knowledge of permissions, thunderbird issues a RENAME :

RENAME Archive OtherUsers/B/Archive

Cyrus does not detect completely that the rename crosses a namespace
boundary. The Archive folder is at the right place on the filesystem :

/var/spool/cyrus/willow_vmw/domain/w/willow.vmw/b/user/b/Archive

But only A has permissions on it whereas the documentation states that:

"Note that some rights are available implicitly, for example 'anonymous'
always has 'p' on user INBOXes, and users always have rights on mailboxes
within their INBOX hierarchy."

I think Archive should qualify as "user B always has rights on mailboxes
within the INBOX hierarchy, like the Archive folder".
When I look at the permissions with cyradm, I have :

localhost> lam user/b...@willow.vmw
b...@willow.vmw lrswipkxtecda
admin0 lrswipkxtecda
a...@willow.vmw lrswipkxtecd

localhost> lam user/b/arch...@willow.vmw
admin0 lrswipkxtecda
a...@willow.vmw lrswipkxtecda


Do I mis-understand something or should I file a bug ? (I am using unix
hierarchy sep + altnamespace)

Regards,
Thomas.

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: uppercase usernames

2013-03-11 Thread Julien Coloos
Hi,

Is your system RedHat/CentOS/Fedora ?
I think their version (since 2.3.x) have a patch that "normalize" 
(lowercase + strip leading and trailing whitespaces) authentication ids. 
From what I could see it appears it was added as a configuration option, 
but the code is not complete and so the default value (enabled) applies.


Le 11/03/2013 08:49, Joerg Maier a écrit :
> Hi Dan,
>
> Thanks for you suggestion!
>
> Unfortunately, testing the solution i have in mind, i renamed and
> finally deleted my one CamelCase testaccount. And now, when I try to
> create a mailbox with CamelCase with cyradm, the default acls are set to
> a user with lowercase username, and I am not able to set additional acls
> to a user with CamelCase with sam.
>
> I suppose that "username_tolower: 0" just does not does what I thiought
> it did in the source installation.
>
> The solution I want to use for my users now is:
> - renaming user to lowercase in userdatabase
> - renamin cyrus account with cyradm rename to lowercase
> - creating a virtual forward rule, so postfix delivers the mail sent to
> CamelCase address -> camelcase (and keep lmtp_downcase_rcpt: 0 and
> username_tolower: 0 until last CamelCase adress is converted.
>
> Thanks, Joerg
>
>
> On 2013-03-11 0:29, Dan White wrote:
>> On 03/10/13 23:28 +0100, Joerg Maier joerg.maier wrote:
>>> Hi List,
>>>
>>> I am using cyrus since ~8 years for a mailserver with ~200
>>> mailaccounts.
>>>
>>> After transferring a mailserver from cyrus 2.2 to 2.4, I have an
>>> issue
>>> with usernames containing uppercase letters. Up to now, i did tread
>>> the
>>> part before the @ as case sensitive, and i allowed users to create
>>> mailboxes like TestCApital.
>>>
>>> I have set:
>>> lmtp_downcase_rcpt: 0
>>> username_tolower: 0
>>>
>>> When I try:
>>> testsaslauthd -u TestCApital. -p 
>>> I get
>>> 0: OK "Success."
>>>
>>> But when I try to logon via imap, i see in the logs:
>>> ... saslauthd[24118]: do_auth : auth failure:
>>> [user=testcapital.] [service=imap] [realm=] [mech=pam]
>>> [reason=PAM auth error]
>>>
>>> What is the best solution to work around this?
>> Do you get the same result with imtest?
> 
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> To Unsubscribe:
> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: ACLs and cross-namespace move problem

2013-03-11 Thread Marc Patermann
Thomas,

Thomas Cataldo schrieb (11.03.2013 10:21 Uhr):

> I have a problem with shared user mailboxes and permissions on cyrus 2.4.16.
> 
> User A has read/write access on user B ("lrswipkxte")
> 
> Folders looks like this for user A:
> 
>INBOX
>Archive
>   2012
>Other Users/ <== the user's namespace
> B (user B inbox)
> Sent
> Drafts
> Trash
> 
> User A wants to move the Archive folder to User B. He does a simple 
> drag&drop in thunderbird for his box to Other Users/B.
> 
> With its knowledge of permissions, thunderbird issues a RENAME :
> 
> RENAME Archive OtherUsers/B/Archive
> 
> Cyrus does not detect completely that the rename crosses a namespace 
> boundary. The Archive folder is at the right place on the filesystem :
> 
> /var/spool/cyrus/willow_vmw/domain/w/willow.vmw/b/user/b/Archive
> 
> But only A has permissions on it whereas the documentation states that:
> 
> "Note that some rights are available implicitly, for example 'anonymous' 
> always has 'p' on user INBOXes, and users always have rights on 
> mailboxes within their INBOX hierarchy."
Do you have a link?

> I think Archive should qualify as "user B always has rights on mailboxes 
> within the INBOX hierarchy, like the Archive folder".
> When I look at the permissions with cyradm, I have :
> 
> localhost> lam user/b...@willow.vmw
> b...@willow.vmw lrswipkxtecda
> admin0 lrswipkxtecda
> a...@willow.vmw lrswipkxtecd
> 
> localhost> lam user/b/arch...@willow.vmw
> admin0 lrswipkxtecda
> a...@willow.vmw lrswipkxtecda
> 
> 
> Do I mis-understand something or should I file a bug ? (I am using unix 
> hierarchy sep + altnamespace)
I think this has always been this way.
If you create a subfolder it inherits the rights from the upper level 
and so you have the same right for INBOX and subfolders, as long as you 
do not change the rights. You can always revoke your own rights, I think.
Moving/renaming a folder has always (as far I remember for 2.2. und 2.3) 
  been keeping the rights with the folder.


Marc

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


Re: uppercase usernames

2013-03-11 Thread Joerg Maier
Hi Julien,

Thanks for the hint!

My system is (now) Ubuntu 12.04.2 LTS. I found normalizeuid in the 
docs, which I set to 0. Still with the same result.

I scanned the code a bit as well, I find such a patch in the Ubuntu 
distribution patches 
(cyrus-imapd-2.4.2-903-normalize-authorization-id.patch). If I 
understand the code, it is initialized with 0, and only if set to 1 if 
config says.

I think now, the best solution would be to install a debug version 
somewhere and see which of the 68 tolower calls in the code performs my 
unwanted tolower and why.

As I only have 20 mailboxes with UpperCase letters in them, and after 
testing I found that a combination of "rename user/CamelCase 
user/camelcase" plus "sam user/camelcase camelcase lrswipcda" plus some 
account changing in the database will fix my issue,
- without any manual configuration steps for the users
- still the rcpt to:CamelCase mails will get to the renamed account

Thanks for all your help. I guess the next person who runs into this 
and reads this thread needs to debug a bit or study the code investing 
more time.

Joerg

On 2013-03-11 13:19, Julien Coloos wrote:
> Hi,
>
> Is your system RedHat/CentOS/Fedora ?
> I think their version (since 2.3.x) have a patch that "normalize"
> (lowercase + strip leading and trailing whitespaces) authentication
> ids. From what I could see it appears it was added as a configuration
> option, but the code is not complete and so the default value
> (enabled) applies.
>
>
> Le 11/03/2013 08:49, Joerg Maier a écrit :
>> Hi Dan,
>>
>> Thanks for you suggestion!
>>
>> Unfortunately, testing the solution i have in mind, i renamed and
>> finally deleted my one CamelCase testaccount. And now, when I try to
>> create a mailbox with CamelCase with cyradm, the default acls are 
>> set to
>> a user with lowercase username, and I am not able to set additional 
>> acls
>> to a user with CamelCase with sam.
>>
>> I suppose that "username_tolower: 0" just does not does what I 
>> thiought
>> it did in the source installation.
>>
>> The solution I want to use for my users now is:
>> - renaming user to lowercase in userdatabase
>> - renamin cyrus account with cyradm rename to lowercase
>> - creating a virtual forward rule, so postfix delivers the mail sent 
>> to
>> CamelCase address -> camelcase (and keep lmtp_downcase_rcpt: 0 and
>> username_tolower: 0 until last CamelCase adress is converted.
>>
>> Thanks, Joerg
>>
>>
>> On 2013-03-11 0:29, Dan White wrote:
>>> On 03/10/13 23:28 +0100, Joerg Maier joerg.maier wrote:
 Hi List,

 I am using cyrus since ~8 years for a mailserver with ~200
 mailaccounts.

 After transferring a mailserver from cyrus 2.2 to 2.4, I have an
 issue
 with usernames containing uppercase letters. Up to now, i did 
 tread
 the
 part before the @ as case sensitive, and i allowed users to create
 mailboxes like TestCApital.

 I have set:
 lmtp_downcase_rcpt: 0
 username_tolower: 0

 When I try:
 testsaslauthd -u TestCApital. -p 
 I get
 0: OK "Success."

 But when I try to logon via imap, i see in the logs:
 ... saslauthd[24118]: do_auth : auth failure:
 [user=testcapital.] [service=imap] [realm=] [mech=pam]
 [reason=PAM auth error]

 What is the best solution to work around this?
>>> Do you get the same result with imtest?
>> 
>> Cyrus Home Page: http://www.cyrusimap.org/
>> List Archives/Info: 
>> http://lists.andrew.cmu.edu/pipermail/info-cyrus/
>> To Unsubscribe:
>> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: uppercase usernames

2013-03-11 Thread Julien Coloos
Le 11/03/2013 23:00, Joerg Maier a écrit :
> Hi Julien,
>
> Thanks for the hint!
>
> My system is (now) Ubuntu 12.04.2 LTS. I found normalizeuid in the 
> docs, which I set to 0. Still with the same result.
>
> I scanned the code a bit as well, I find such a patch in the Ubuntu 
> distribution patches 
> (cyrus-imapd-2.4.2-903-normalize-authorization-id.patch). If I 
> understand the code, it is initialized with 0, and only if set to 1 if 
> config says.
>
> I think now, the best solution would be to install a debug version 
> somewhere and see which of the 68 tolower calls in the code performs 
> my unwanted tolower and why.
>
> As I only have 20 mailboxes with UpperCase letters in them, and after 
> testing I found that a combination of "rename user/CamelCase 
> user/camelcase" plus "sam user/camelcase camelcase lrswipcda" plus 
> some account changing in the database will fix my issue,
> - without any manual configuration steps for the users
> - still the rcpt to:CamelCase mails will get to the renamed account
>
> Thanks for all your help. I guess the next person who runs into this 
> and reads this thread needs to debug a bit or study the code investing 
> more time.
>
> Joerg

Maybe it's the same patch than in RedHat. There the issue is that cyrus 
configuration code is separated in 2 parts: one in the core library 
(pretty much static; values accessed with 
libcyrus_config_getxxx/libcyrus_config_setxxx), the other being 
accessible in all services and populated from the content of imapd.conf 
(values accessed with config_getxxx).
The patch declares the option in both parts and uses 
libcyrus_config_getxxx to query the value because it is needed in the 
core library. From what I could see, what is lacking is a line of code - 
usually in imap/global.c:cyrus_init - do get the value from imapd.conf 
and set it in the core library, like it is already done for some other 
options. Example with username_tolower:

 libcyrus_config_setswitch(CYRUSOPT_USERNAME_TOLOWER,
   config_getswitch(IMAPOPT_USERNAME_TOLOWER));

I don't know who is in charge of this patch, but maybe Jeroen can help 
fix the issue on RedHat side. Actually he seems also linked to the patch 
on Debian ? 
(http://git.kolabsys.com/apt/cyrus-imapd/diff/debian/patches/cyrus-imapd-2.4.2-903-normalize-authorization-id.patch?h=debian/master&id=e3af2e17dc0d31ad8c8f7360970f93fe7fbf6d3e)


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus