Connection Diagrams

This appendix contains overview connection diagrams between functional components of Kolab Groupware as well as detailed connection diagrams per component.

Bearing in mind Kolab Groupware comes with a lot of option value, it is worth noting these connection diagrams reference functional components and roles.

Ranked

The following diagram is a full connection diagram, ranked and uncategorized.

A ranked connection diagram for a default Kolab Groupware installation.

Categorized

A categorized connection diagram for a default Kolab Groupware installation.

Kolab Web Client Traffic

Client

Internet

Transparent Reverse Proxy

Kolab Web Client

Two categories:

• Application pages,
• Assets

Connections for kolabd

kolabd -> ldapw

This is a long-lived connection that is not frequently re-established.

The functional component known as kolabd is responsible for synchronizing changes in LDAP to the rest of the environment. It therefore requires a connection to an LDAP server, and most commonly uses a writeable LDAP server for this purpose.

The kolab daemon requires the ability to write attributes back to LDAP entries, such as mail and alias for the application of the recipient policy, and the mailhost for traffic routing, and the mailquota management.

It uses the connection to listen for or detect changes to ldap and responds to such changes.

Note

kolabd could be made a functional daemon against a read-only LDAP server, by suspending the application of the recipient policy, and either ensuring the mailhost attribute is properly pre-populated or that delivery is performed through Cyrus IMAP frontends using lmtpd(8), and ensuring that LDAP entries are complete and correct.

kolabd -> int-imapf

The kolabd daemon creates a connection to the internal imap frontends to create, rename or delete user mailboxes.

One such connection is rather long-lived, and constitutes the administrative connection. This connection is used for the listing of all mailboxes and mailfolders despite the owner’s authorization realm, or the namespace.

When kolabd notices a mailbox needs to be created, renamed or deleted, it uses this administrative connection to determine whether the mailbox still or already exists.

kolabd may also create secondary connections that are authorized as user connections. These connections are used to set metadata values on entries in the /private metadata namespace, such as /private/vendor/kolab/folder-type.

kolabd -> imapb

Connections to the IMAP backend that corresponds with a user’s mailbox are required to change folder’s partition and to set quota.

Note

Note that the connection goes to the only backend, or the active backend in a active/passive environment, or either one backend of an active/active cluster.

Detailed Connection Diagram for kolabd

Connection diagram for the kolabd component.

Initial Creation of a User

• kolabd is assumed to be connected to ldapw ⁽¹⁾ and continues to listen for change notifications using a mechanism known as persistent search notification.
• An administrator uses the wap to create a user in ldapw ⁽⁵⁸⁾.

In parallel, this change triggers the following independent paths;

• ldapw replicates the changes to ldapr. The success of this replication is required for functional ptloader canonification against ldapr ⁽¹⁹⁾ for the functioning of the following systems;
  • int-imapf ⁽¹⁰⁾,
  • imapba ⁽¹⁴⁾,
  • imapbb ⁽¹⁷⁾.
• kolabd receives the change notification from ldapw [1];
  • kolabd applies the recipient policy and writes back any changes to ldapw.
  • kolabd writes the values of the nsuniqueid and modifytimestamp out to its local persistency database, including the value of the configured result attribute for the mailbox name [2],
  • kolabd connects to or re-uses an existing connection to int-imapf ⁽²⁾ to establish a mailbox for the user created.
  • kolabd awaits the propagation of the mailbox created throughout the Cyrus IMAP Discrete Murder, such that;
    • imapba (and imapbb ⁽¹²⁾) have made the reservation in imapm ^{(13, 16)},
    • imapba (and imapbb ⁽¹²⁾) have created the mailbox in their local spools,
    • imapba (and imapbb ⁽¹²⁾) have activated the reservation of the mailbox in imapm ^{(13, 16)},
    • imapm has communicated the changes to int-imapf ⁽⁹⁾.
  • kolabd obtains the /vendor/cmu/cyrus-imapd/server metadata value from the mailbox created via int-imapf ⁽²⁾,
  • kolabd writes out the IMAP backend server address to the entry attribute mailhost in ldapw ⁽¹⁾,
  • Should any additional folders need to be created, kolabd connects to int-imapf ⁽²⁾ and proxy-authenticates as the target user [3],
  • Should any default quota have been configured, but not set on the user entry, then kolabd will write out the mailquota attribute value for the LDAP entry on ldapw ⁽¹⁾,
  • Should any quota need to be set on the top-level mailbox or on any sub-folders, then kolabd connects to either imapba ⁽¹⁴⁾ or imapbb ⁽¹⁷⁾, depending on which one holds the service IP address for the server address used to address either or both, and sets the quota.

Outbound Connection Table for kolabd

Source	Target	Protocol(s)	Port(s)	Type
kolabd	ldapw	LDAP	389/tcp [4]	Long-Lived
		LDAPS	636/tcp [5]	Long-Lived
kolabd	inf-imapf	IMAPS	993/tcp [6]	Long-Lived [7]
				Short-Lived [8]
kolabd	imapb	IMAPS	993/tcp	Short-Lived [9]

guam -> ext-imapf

The client facing intelligent IMAP proxy that, at the time of this writing, filters groupware folders for clients that do not understand the contents of groupware folders uses external-facing IMAP frontends for loggingand audit requirements and access control restrictions.

Connections to guam can be made from external clients (Internet clients or road-warriors) as well as internal clients that reside on internal client network segments.

imapm -> ldapr

Authentication (through kolab-saslauthd) and username canonification (through ptloader) uses ldapr.

Source	Target	Protocol(s)	Port(s)	Type
imapm	ldapr	LDAP	389/tcp [10]	Frequent, Short-Lived
		LDAPS	636/tcp [11]	Frequent, Short-Lived

ext-imapf -> imapm

keep up-to-date with the latest news about mailboxes in the cluster

ext-imapf -> ldapr

ptloader, saslauthd

Source	Target	Protocol(s)	Port(s)	Type
ext-imapf	ldapr	LDAP	389/tcp [12]	Frequent, Short-Lived
		LDAPS	636/tcp [13]	Frequent, Short-Lived

ext-imapf -> imapb

proxied connections

int-imapf -> imapm

keep up-to-date with the latest news about mailboxes in the cluster

int-imapf -> ldapr

ptloader, saslauthd

Source	Target	Protocol(s)	Port(s)	Type
int-imapf	ldapr	LDAP	389/tcp [14]	Frequent, Short-Lived
		LDAPS	636/tcp [15]	Frequent, Short-Lived

int-imapf -> imapb

proxied connections

imapba <-> imapbb

replication

imapba -> imapm

mupdate connection in order to update the mupdate master about changes to local mailboxes.

imapba -> ldapr

authentication, routing

Source	Target	Protocol(s)	Port(s)	Type
imapba	ldapr	LDAP	389/tcp [16]	Frequent, Short-Lived
		LDAPS	636/tcp [17]	Frequent, Short-Lived

imapba -> int-mx

relay (sieve forward / autorespond), MSN, NDR

Source	Target	Protocol(s)	Port(s)	Type
imapba	int-mx	SMTP	25/tcp [18]	Frequent, Short-Lived

imapbb -> imapm

mupdate connection in order to update the mupdate master about changes to local mailboxes.

imapbb -> ldapr

authentication, routing

Source	Target	Protocol(s)	Port(s)	Type
imapba	ldapr	LDAP	389/tcp [19]	Frequent, Short-Lived
		LDAPS	636/tcp [20]	Frequent, Short-Lived

imapbb -> int-mx

relay (sieve forward / autorespond), MSN, NDR

Source	Target	Protocol(s)	Port(s)	Type
imapbb	int-mx	SMTP	25/tcp [21]	Frequent, Short-Lived

ldapw -> ldapr

replication

ext-mx-in -> ldapr

destination verification

ext-mx-in -> dbw

caching

ext-mx-in -> int-mx

relay

ext-mx-out -> ldapr

routing information for MSN and NDR

ext-mx-out -> int-mx

the actual routing

ext-subm -> ldapr

authentication, access policy

ext-subm -> dbw

cache

ext-subm -> int-mx

relay

int-subm -> ldapr

authentication, access policy

int-subm -> dbw

cache

int-subm -> int-mx

relay

int-mx -> ldapr

routing

int-mx -> ext-mx-out

relay for non-local mail

int-mx -> imapb

routing for local mail

dbr -> dbw

replication – iirc, the slave connects to the master

roundcube -> ldapr

authentication, username canonification, address book, delegation identities, identity provisioning, (...)

roundcube -> ldapw

password changes

roundcube -> dbr

read-only connections to the database

roundcube -> dbw

write connections to the database, sometimes also immediate subsequent read-only queries (dsnw_noread)

roundcube -> int-imapf

web client to imap

roundcube -> int-subm

submission of new messages

roundcube -> memc-pub

certain caches, session information, attachments (redundant)

syncroton -> ldapr

authentication, GAB searches

syncroton -> dbr

read-only connections to the database

syncroton -> dbw

write connections to the database, sometimes also immediate subsequent read-only queries (dsnw_noread)

syncroton -> int-imapf

payload connection

syncroton -> int-subm

submission of new messages

chwala -> ldapr

authentication

chwala -> dbr

read-only connections to the database

chwala -> dbw

write connections to the database, sometimes also immediate subsequent read-only queries (dsnw_noread)

chwala -> int-imapf

payload

chwala -> memc-pub

certain caches, sesssion information

irony -> ldapr

authentication, GAB

irony -> dbr

read-only connections to the database

irony -> dbw

write connections to the database, sometimes also immediate subsequent read-only queries (dsnw_noread)

irony -> int-imapf

payload

irony -> int-subm

submission of scheduling invitation

Note

This may actually not be true at all, and instead the local mx could be used, in which case this is int-mx not int-subm.

irony -> memc-pub

certain caches.

wap -> ldapw

administration of entries

wap -> dbw

wap-specific settings

wap has no dsnr

wap -> memc-pvt

the type of information the wap caches should not be on the same (pair of replicated) memcached servers

freebusy -> ldapr

authentication, user information

freebusy -> dbr

read-only connections to the database

freebusy -> dbw

write connections to the database, sometimes also immediate subsequent read-only queries (dsnw_noread)

freebusy -> int-imapf

payload

ext-mx-in -> asav

optionally scan inbound email for spam and virus

asav -> ext-mx-in

re-submission of conn 65

asav -> int-mx

re-submission of conn 74

asav -> ext-mx-out

re-submission of conn 72

wallace -> int-mx

continued delivery

wallace -> ldapr

user information

wallace -> int-imapf

payload

ext-mx-out -> asav

optionally scan outbound email for spam and virus

int-mx -> wallace

submit messages to wallace for evaluation, application of policy, etc.

int-mx -> asav

optionally, check internal email for spam and virus

roundcube -> chwala

roundcube -> freebusy

Free/Busy information for Roundcube calendaring.

imapbb -> imapba

Replication from IMAP Backend

Footnotes

[1]	This is not an outbound connection for ldapw, but rather a protocol response to a long-lived connection from kolabd to ldapw.

[2]	The recording for the nsuniqueid and result attribute value allow kolabd to respond to change notifications that modify the value of the result attribute.

[3]	Using proxy-authentication authorizes the connection as if it were the target user itself logging on to IMAP. This is important for kolabd because additional folders may need to be set metadata on, that resides in the /private namespace – only the user themselves can do this effectively.

[4]	Authenticated, as anonymous binds should not be allowed. Binds should be allowed over connections that are protected by a transport security layer such as TLS.

[5]	Implicit SSL – better.

[6]	Authentication is not allowed over connections not already protected on a different layer.

[7]	The administrative connection for top-level mailboxes is re-used for as long as it is functional.

[8]	Second connection, proxy authenticated. Occurs as frequently as there are new user accounts added to LDAP.

[9]	Some commands are not proxied through IMAP frontends correctly. The use of a connection directly to the appropriate IMAP backend ensures quota can be set, and mail-folders can be moved between partitions.

[10]	Authenticated, as anonymous binds should not be allowed. Binds should be allowed over connections that are protected by a transport security layer such as TLS.

[11]	Implicit SSL – better.

[12]	Authenticated, as anonymous binds should not be allowed. Binds should be allowed over connections that are protected by a transport security layer such as TLS.

[13]	Implicit SSL – better.

[14]	Authenticated, as anonymous binds should not be allowed. Binds should be allowed over connections that are protected by a transport security layer such as TLS.

[15]	Implicit SSL – better.

[16]	Authenticated, as anonymous binds should not be allowed. Binds should be allowed over connections that are protected by a transport security layer such as TLS.

[17]	Implicit SSL – better.

[18]	Unauthenticated, w/ STARTTLS.

[19]	Authenticated, as anonymous binds should not be allowed. Binds should be allowed over connections that are protected by a transport security layer such as TLS.

[20]	Implicit SSL – better.

[21]	Unauthenticated, w/ STARTTLS.