[Kolab-devel] Kolab 3.x Extension to handle secondary domains internally (Multi-domain patched)

Hi,

I wrote the following in the users list but Torsten Grote thought it
might have a better fit here.

Best regards,
Rickard
==============================================================
Hi,

I've been looking into this a bit more and found out what is going on
behind the scene.

(I'm talking about the files in /etc/postfix/ldap)
In mydestination.cf there is a check in cn=kolab,cn=config if the domain
is related and if so it returns all related domains.

This is called from for example mailenabled_distgroups.cf with the
domain line.

This really doesn't do anything except check if the reciever domain
exists inside the LDAP and then returns control to the calling script.

I would like to add the main domain dn to cn=kolab,cn=config for each
domain and thus be able to extract that to use as the search_base inside
postfix. That would help to have different users/lists/shared folders
using secondary mail-addresses to receive e-mail without mapping each
secondary domain to the main domain. 

I know this isn't possible as postfix looks today but that would be a
nice extension for all of us using multi-domain setups. In the case of
Kolab that would make it possible to handle all main as well as
secondary domains inside the kolab-webadmin and be a lot more flexible.

I could take a look at the source code of postfix but I have to admit
that I'm not the best programmer in the world to solve this.

THe mydestination.cf would look like for example this:

server_host = localhost
server_port = 389
version = 3
search_base = cn=kolab,cn=config
scope = sub
expansion_limit = 0
size_limit = 1
bind_dn = uid=kolab-service,ou=Special
Users,dc=<host>,dc=<domain>,dc=<top-level domain>
bind_pw = <password>

query_filter = (&(associatedDomain=%s))
result_attribute =
special_result_attribute = inetdomainbasedn

Which would return the main domain to be used as the search_base in the
other scripts. If nothing is returned then it will be used as usual and
deny the message.

I hope this is of interest for others as well!

Best regards,
Rickard

On tis, 2014-03-25 at 19:43 +0100, Rickard Osser wrote:
> Hi,
> 
> I'm not sure I fully grasp what's going on inside of 389-dir and with
> postfix but I see a big problem with actually handling secondary
domains
> in virtual_alias_maps_manual.cf manually in a hosting setting.
> 
> Especially if you put the responsibility for adding customers to some
> "not so CLI oriented".
> 
> Maybe this could be solved by extending the ldap schema with
> "domainRelatedObject" and populate it with the secondary domain-names
> associated with the domain.
> 
> And then put something like:
> 
> query_filter = (&(associatedDomain=%s))
> result_attribute = associateddomain
> 
> to find the domains in mydestination.cf 
> 
> As I said, this is just a suggestion or a test-balloon... 
> So, shoot it down? or let it find freedom! :)
> 
> Best regards,
> 
-- 
Rickard Osser 
Manager
----------------------------------------------------------------------- 
| Lindist AB                  | Swedens No 1 distributor of Linux     |
|                             | and Linux related products!           |
-----------------------------------------------------------------------
| Osser Brosoft AB            | Computer Consultants                  |
-----------------------------------------------------------------------
| Solberga Ängsväg 3          | S-125 44 Älvsjö, Sweden               |
| Tel: +46-8-669 75 75        | E-mail: [email protected]      |
| Fax: +46-8-668 89 10        | http://www.lindist.se                 |
|                             | https://www.linkedin.com/in/ricky     |
-----------------------------------------------------------------------

_______________________________________________
devel mailing list
[email protected]
https://lists.kolab.org/mailman/listinfo/devel