Resources in multi-domain setup. Does it work in Kolab 3.4? (Bug in doc found !)

Sat May 9 14:55:13 CEST 2015

Hi,
i found out, that there's a bug in the upgrade doc 3.3 -> 3.4 as well as
in other docs.
Reading the manual of postfix, there must be no " when using a result
format in postfix ldap.
The kolab doc tells me exactly the opposite.
So, debugging the dirsrv access log, it clearly shows, that the " will
get interpreted as search term and not left out.
postfix then appends the default domain which is terrible wrong.
Nevertheless, the mail can't be delivered to the shared folder.
Also, a shared folder is not a kolabinterperson, but a kolabsharefolder
object class.

From postfix manual:
http://www.postfix.org/ldap_table.5.html

NOTE: DO NOT put quotes around the result format!

Kolab upgrade guide:
https://docs.kolab.org/upgrade-guide/kolab-3.4.html

Change the result_format to be enclosed by quotes otherwise you can’t
deliver mail messages to shared mailboxes that contains spaces in the
mailbox name.

result_format = "shared+%s"

Dirsrv accesslog shows, that " has been encoded to \22.

Wrong:
[09/May/2015:12:15:34 +0200] conn=409 op=11 SRCH
base="dc=example,dc=com" scope=2
filter="(&(|(mail=\22shared+shared/resources/buero at example.com\22 at default.domain.com)(alias=\22shared+shared/resources/buero at example.com\22 at default.domain.com))(objectClass=kolabinetorgperson))"
attrs="mail"

Changing result format to:
result_format = shared+%s

Better:
[09/May/2015:14:05:31 +0200] conn=631 op=9 SRCH base="dc=example,dc=com"
scope=2
filter="(&(|(mailAlternateAddress=resource-confroom-buero at example.com)(alias=resource-confroom-buero at example.com)(mail=resource-confroom-buero at example.com))(objectClass=kolabinetorgperson))"
attrs="mail"

Buuuuut, the shared folder is not a  kolabinetorgperson but a
kolabsharedfolder.
So, the search filter will not work with shared folders.
The duplet and triplet config shows no objectClass kolabsharefolder.

E.g.: /etc/postfix/ldap/hosted_duplet_virtual_alias_maps.cf:query_filter
= (&(|(mail=%s)(alias=%s))(objectclass=kolabinetorgperson))

The shared folder search filter should be:
(&(|(mail=resource-confroom-buero at example.com)(alias=resource-confroom-buero at example.com))(objectClass=kolabsharedfolder))" 
attrs="mail"

So, the user aliasing will not work anymore, when changing the filter,
cause it uses one filter for all deliveries (user and shared folders),
we have to use an filter, that will cover users and shared folders, like
this:
"(&(|(mail=resource-confroom-buero at example.com)(alias=resource-confroom-buero at example.com))(|(objectClass=kolabsharedfolder)(objectClass=kolabinetorgperson)))"
attrs="mail"

Test works:
/usr/lib/mozldap/ldapsearch -b dc=example,dc=com -D
"uid=kolab-service,ou=Special Users,dc=example,dc=com" -w xxxxxxxxx
"(&(|(mail=resource-confroom-buero at example.com)(alias=resource-confroom-buero at example.com))(|(objectClass=kolabsharedfolder)(objectClass=kolabinetorgperson)))"
mail
Result:
dn: cn=buero,ou=Resources,dc=example,dc=com
mail: resource-confroom-buero at example.com

I will now try some combinations in  hosted_duplet_virtual_alias_maps.cf
and triplet confs (I have some triplet domains too ;-))

Will report back.

Rgds.

Franz

Am 06.05.15 um 14:36 schrieb Cornelius Hald:
> Hi Franz,
>
> thanks for the information. So it looks like the situation with 3.4 is
> even worse as it was with 3.3. Not nice :(
>
> The issue I have with booking resources is exactly the one you're
> describing as well. It's a pity that the multi-domain setup is so buggy
> because for me this was the one single reason to (try to) switch to
> Kolab...
>
> Anyway, thanks for your help. It's very welcome!
> Conny
>
>
> On Tue, 2015-05-05 at 18:42 +0200, Franz Skale wrote:
>> Hi,
>> what i've got working is, freebusy get but not freebusy display in
>> roundcube.
>> Also, sending mail to a resource email doensn't work.
>> I think, i have the right setup but, like i mentioned in a post some
>> time ago, there's a issue regarding lmtp and verify user.
>> It simply uses the wrong notation.
>> Look at my post from 23.03.2015 for details.
>> Also, right now i'm struggling with kolabd and the Reconnect facility,
>> which simply doesn't work with imaps.
>> I couldn't get imap to work. So it would be really cool to have all
>> possible options in kolab.conf been well documented.
>> Excerpt from my post on 23.03.2015 regarding the resource issues:
>>
>> 3.) Mail to shared folder on multidomain setup, which worked in 3.3 now
>> refuses to work with 3.4.
>> I found out that, whenever a resource got booked a mail is sent to the
>> resource which doesn't work anymore.
>> Simple explanation is that the primary domain will always be added
>> regardless of the receipeint domain:
>>
>> E.g:
>> Mar 22 20:30:13 mail postfix/lmtp[12329]: C7D579274B0:
>> to=<shared+shared/Resources/buero at example.com>,
>> orig_to=<shared+shared/Resources/buero at example.com@primarydomain.com>,
>> relay=mail.example.com[/var/lib/imap/socket/lmtp], delay=0.04,
>> delays=0.02/0/0/0.01, dsn=5.1.1, status=bounced (host
>> mail.example.com[/var/lib/imap/socket/lmtp] said: 550-Mailbox unknown. 
>> Either there is no mailbox associated with this 550-name or you do not
>> have authorization to see it. 550 5.1.1 User unknown (in reply to RCPT
>> TO command))
>>
>> How to teach roundcube to not use the primary domain in adressing ?
>> Of course i read the changes and added " to the virtual alias maps which
>> changed anything !
>>
>>
>> Rgds.
>>
>> Franz
>>
>>
>>
>> Am 05.05.15 um 14:55 schrieb Cornelius Hald:
>>> Hi,
>>>
>>> from what I know it is a known bug that you can't use resources with
>>> Kolab 3.3 in a multi-domain setup. See:
>>>
>>> https://issues.kolab.org/show_bug.cgi?id=4331
>>>
>>> Did anyone try that with 3.4? Does it work there?
>>>
>>> I'm really trying to figure this out because it would be the last piece
>>> to a completely working setup.
>>>
>>> Thanks!
>>> Conny
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at lists.kolab.org
>>> https://lists.kolab.org/mailman/listinfo/users
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/users/attachments/20150509/c2ab78a8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4254 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.kolab.org/pipermail/users/attachments/20150509/c2ab78a8/attachment.p7s>