1

Topic: Cluebringer internal_domains

======== Required information ====
- iRedMail version: 0.8.7
- iRedAdmin-Pro-LDAP version 2.1.2
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): LDAP
- Linux/BSD distribution name and version: CentOS 6.5
- Related log if you're reporting an issue:
====

Dear iRedAdmin-Pro Support,

I'm planning to update from policyd 1.8 to cluebringer on our mail infrastructure. I did a bit of testing and I've found that cluebringer uses a mysql table to list all domains that it considers "internal". Each domain added with iRedAdmin is added to this table.

We currently have ~25k domains. I have the following questions:
- has anyone ever used cluebringer with that many domains? I'm worried about performance here: does it use some sort of caching so that such a table is ok performance-wise?
- would it be possible to have cluebringer use a ldap lookup instead?

Regards,

Andrea

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2

Re: Cluebringer internal_domains

AndreaC wrote:

We currently have ~25k domains. I have the following questions:
- has anyone ever used cluebringer with that many domains? I'm worried about performance here: does it use some sort of caching so that such a table is ok performance-wise?

I didn't host so many domains before, so i suggest you ask in Cluebringer mailing list to get support from Cluebringer developers directly: http://wiki.policyd.org/support

AndreaC wrote:

- would it be possible to have cluebringer use a ldap lookup instead?

Cluebringer uses SQL database to store data, i don't think it supports LDAP lookup.

3

Re: Cluebringer internal_domains

Hello,

cluebringer mailing list suggests to use a different schema to differentiate between incoming and outgoing by using SASL (and thus only "Source" ):

- Inbound with Source members being: !SASL or !internal_ip
- Outbound with Source members being: SASL or internal_ip

I will give it a try.
With this setup, though, it will be unfortunately impossible to discriminate "Internal".

Regards,

AndreaC

4

Re: Cluebringer internal_domains

Hi AndreaC,

any update?

5

Re: Cluebringer internal_domains

Hi ZhangHuangbin,

we've finally decided to use a variation of your schema: we'll add all 25k domains to the "internal_domains" mysql table and test how it goes. We'll let you know.

Regards,

6

Re: Cluebringer internal_domains

What's the problem with 'SASL' to identify internal users?

7

Re: Cluebringer internal_domains

ZhangHuangbin wrote:

What's the problem with 'SASL' to identify internal users?

We have some custom requirements: we need to be able to assign the domains to several class of service each one has different limits. This is why we need to have Internal_Small, Internal_Medium and Internal_Large classes each with different quotas.

Also, we'd like to be able to track "Internal" mails.

We're going to test performance in the next few days.

AndreaC

8

Re: Cluebringer internal_domains

AndreaC wrote:

We have some custom requirements: we need to be able to assign the domains to several class of service each one has different limits. This is why we need to have Internal_Small, Internal_Medium and Internal_Large classes each with different quotas.

Would you mind sharing how you're going to define policies? And policy members, policy groups, policy group members.

The more policies and policy groups you defined, Cluebringer will perform more SQL queries to get policy members and policy group members.