summaryrefslogtreecommitdiff
path: root/Architecture_and_Design/en-US/Terminology.xml
blob: 9aa02c3e77ee96e77b13b8d8f1e2fb44451b5c4c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
%BOOK_ENTITIES;
]>
<appendix id="appe-Architecture_and_Design-Terminology">
    <title>Terminology</title>
    <formalpara id="form-Architecture_and_Design-Terminology-Authentication_Credentials">
        <title>Authentication Credentials</title>
        <para>
            TODO
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-Authentication_Domain">
        <title>Authentication Domain</title>
        <para>
            TODO
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-Authentication_Password">
        <title>Authentication Password</title>
        <para>
            TODO
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-Authentication_Realm">
        <title>Authentication Realm</title>
        <para>
            TODO
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-Authentication_Service_Name">
        <title>Authentication Service Name</title>
        <para>
            TODO
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-Authentication_Username">
        <title>Authentication Username</title>
        <para>
            TODO
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-Base_DN">
        <title>Base DN</title>
        <para>
            An LDAP <xref linkend="form-Architecture_and_Design-Terminology-Base_DN" />, as opposed to the LDAP <xref linkend="form-Architecture_and_Design-Terminology-Root_DN" /> is the start position of an <xref linkend="form-Architecture_and_Design-Terminology-LDAP_Search" /> operation.
        </para>

    </formalpara>
    <para>
        The search results will be limited to LDAP objects residing at or under the nesting level of the <xref linkend="form-Architecture_and_Design-Terminology-Base_DN" />. A list of LDAP objects in <emphasis>ou=People,dc=example,dc=org</emphasis> can thus easily be obtained using the <xref linkend="form-Architecture_and_Design-Terminology-Base_DN" /> to restrict the search:
    </para>
    <para>

<screen>$ <userinput>ldapsearch -x -b "ou=People,dc=example,dc=org"</userinput></screen>

    </para>
    <formalpara id="form-Architecture_and_Design-Terminology-Bind_Credentials">
        <title>Bind Credentials</title>
        <para>
            Bind credentials are used with LDAP to elevate privileges beyond those typically associated with the term <emphasis>anonymous</emphasis>. Bind credentials usually add certain additional privileges to the connection, such as the modification of one's <emphasis>self</emphasis> attributes, possibly including one's LDAP object <literal>userPassword</literal> attribute.
        </para>

    </formalpara>
    <para>
        Privileges associated with bind credentials can also make sure restrictions applied to normal users do not apply to service users. In large LDAP directory trees for example, <xref linkend="form-Architecture_and_Design-Terminology-Virtual_List_View_Control" /> can be used to browse the directory, and the credentials used by services may have been authorized to use the corresponding indexes and searches. Also, the LDAP object associated with the service's bind credentials may have been configured with a different search limit and/or search timeout.
    </para>
    <para>
        Most LDAP implementations have specific <xref linkend="form-Architecture_and_Design-Terminology-Bind_Credentials" /> dedicated to server administration, often called <emphasis>Directory Manager</emphasis>, <emphasis>admin</emphasis> or, in case of OpenLDAP, confusingly <emphasis>rootdn</emphasis> referring to the <xref linkend="form-Architecture_and_Design-Terminology-Distinguished_Name" /> with 'root' privileges rather then the <xref linkend="form-Architecture_and_Design-Terminology-Root_DN" />.
    </para>
    <formalpara id="form-Architecture_and_Design-Terminology-Distinguished_Name">
        <title>Distinguished Name</title>
        <para>
            TODO
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-External_Mail_Exchanger">
        <title>External Mail Exchanger</title>
        <para>
            <emphasis>External Mail Exchangers</emphasis> are <emphasis>Internet facing</emphasis> mail exchangers. In other words, they send and/or receive mail to and/or from the Internet. Four sub-types (<emphasis>roles</emphasis>) exist for external mail exchangers: <xref linkend="form-Architecture_and_Design-External_Mail_Exchanger_Types-Receiving" />, <xref linkend="form-Architecture_and_Design-External_Mail_Exchanger_Types-Sending" />, <xref linkend="form-Architecture_and_Design-External_Mail_Exchanger_Types-Submission" /> and <xref linkend="form-Architecture_and_Design-External_Mail_Exchanger_Types-Trusted" />.
        </para>

    </formalpara>
    <note>
        <title>Combined Roles</title>
        <para>
            While an external mail exchanger is assigned at least one <emphasis>role</emphasis>, no one role is mutually exclusive with any other role. As such, all roles may be combined in to one or more external mail exchangers.
        </para>
        <para>
            Additionally, the <emphasis>External Mail Exchanger</emphasis> role can be combined with the <xref linkend="form-Architecture_and_Design-Terminology-Internal_Mail_Exchanger" /> role.
        </para>

    </note>
    <important>
        <title>FIXME</title>
        <para>
            The list below should be an ordered list, but Publican &ndash;at the time of this writing&ndash; does not align the formalpara title correctly.
        </para>

    </important>
    <para>
        <itemizedlist id="item-Architecture_and_Design-Terminology-External_Mail_Exchanger_Types">
            <title>External Mail Exchanger Types</title>
            <listitem>
                <formalpara id="form-Architecture_and_Design-External_Mail_Exchanger_Types-Receiving">
                    <title>Receiving</title>
                    <para>
                        External mail exchangers of type <emphasis>receiving</emphasis> receive email from the Internet, possibly including &ndash;not limited to&ndash; specific configuration reflecting;
                    </para>

                </formalpara>
                <para>
                    <orderedlist>
                        <listitem>
                            <para>
                                the corporate content-filtering policies,
                            </para>

                        </listitem>
                        <listitem>
                            <para>
                                firewall configuration,
                            </para>

                        </listitem>
                        <listitem>
                            <para>
                                archiving and discovery policies,
                            </para>

                        </listitem>
                        <listitem>
                            <para>
                                ...
                            </para>

                        </listitem>

                    </orderedlist>

                </para>

            </listitem>
            <listitem>
                <formalpara id="form-Architecture_and_Design-External_Mail_Exchanger_Types-Sending">
                    <title>Sending</title>
                    <para>
                        External mail exchangers of type <emphasis>sending</emphasis> send email to the Internet, typically from <emphasis>known senders</emphasis> only, employing different policies including those for content-filtering.
                    </para>

                </formalpara>

            </listitem>
            <listitem>
                <formalpara id="form-Architecture_and_Design-External_Mail_Exchanger_Types-Submission">
                    <title>Submission</title>
                    <para>
                        External mail exchangers of type <emphasis>submission</emphasis> are used by smart clients to submit email through the corporate infrastructure, to enable recipient mail exchangers to verify the canonical source of the sender email address and mail exchanger IP address and/or hostname against blacklists, whitelists, real-time DNS blacklists, greylists, SPF records and other content-filtering technologies employed at the receiving end.
                    </para>

                </formalpara>
                <para>
                    External mail exchangers of type <emphasis>submission</emphasis> include a Mail Submission Agent process listening on port <literal>587/tcp</literal> (msa), enabling users with smart clients to circumvent the all too common restrictions on the usage of port <literal>25/tcp</literal> (smtp) by many ISPs. These external mail exchangers have the Mail Submission Agent listener exposed to the Internet, and to prevent abuse require authentication before accepting the submission of email. Additionally, these MSA listener processes often require the use of <xref linkend="form-Architecture_and_Design-Terminology-Transport_Layer_Security_TLS" />.
                </para>

            </listitem>
            <listitem>
                <formalpara id="form-Architecture_and_Design-External_Mail_Exchanger_Types-Trusted">
                    <title>Trusted</title>
                    <para>
                        External mail exchangers of type <emphasis>trusted</emphasis> have been configured to relay certain email to specific hosts, that may or may not be referred to as a mail exchangers for the given domain name space by traditional DNS. A scenario implementing this type of mail exchanger would typically have a two-way trust relationship with a third party.
                    </para>

                </formalpara>
                <example id="exam-Architecture_and_Design-External_Mail_Exchanger_Types-Two_way_Organizational_Trust_Relationship_Example">
                    <title>Two-way Organizational Trust Relationship Example</title>
                    <para>
                        A dedicated procurement provider may send and receive confidential information transported from one end to the other using email, and to that end be connected to the corporate (IP-)VPN through an external, dedicated (IP-)VPN cloud. The provider's receiving mail exchangers may, as such, not be listed as mail exchangers in any existing, available DNS zone, and require an explicit relay host entry in the configured transport for the consumer's external mail exchanger MTA(s).
                    </para>

                </example>

            </listitem>

        </itemizedlist>

    </para>
    <formalpara id="form-Architecture_and_Design-Terminology-Fully_Qualified_User_Identifier">
        <title>Fully Qualified User Identifier</title>
        <para>
            TODO
        </para>

    </formalpara>
    <para>
        See also:
    </para>
    <para>
        <itemizedlist>
            <listitem>
                <para>
                    <xref linkend="form-Architecture_and_Design-Terminology-Authentication_Username" />
                </para>

            </listitem>
            <listitem>
                <para>
                    <xref linkend="form-Architecture_and_Design-Terminology-Authentication_Credentials" />
                </para>

            </listitem>
            <listitem>
                <para>
                    <xref linkend="form-Architecture_and_Design-Terminology-Authentication_Realm" />
                </para>

            </listitem>

        </itemizedlist>

    </para>
    <formalpara id="form-Architecture_and_Design-Terminology-Internal_Mail_Exchanger">
        <title>Internal Mail Exchanger</title>
        <para>
            TODO
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-Kolab_Groupware_Primary_Domain">
        <title>Kolab Groupware Primary Domain</title>
        <para>
            All Kolab Groupware deployments require a primary domain name, used to form valid recipient email addresses with. The Kolab Groupware Primary Domain represents the primary domain name space for which the groupware deployment runs. Without such domain name space, no user would be able to send or receive email messages to or from the outside world (the Internet).
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-LDAP_Access_Control">
        <title>LDAP Access Control</title>
        <para>
            TODO
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-LDAP_Search">
        <title>LDAP Search</title>
        <para>
            An LDAP Search consists for the following;
        </para>

    </formalpara>
    <para>
        <itemizedlist>
            <listitem>
                <para>
                    <xref linkend="form-Architecture_and_Design-Terminology-Bind_Credentials" />
                </para>

            </listitem>
            <listitem>
                <para>
                    <xref linkend="form-Architecture_and_Design-Terminology-Search_Scope" />
                </para>

            </listitem>
            <listitem>
                <para>
                    <xref linkend="form-Architecture_and_Design-Terminology-Search_Filter" />
                </para>

            </listitem>

        </itemizedlist>

    </para>
    <para>
        Additionally, the results of an LDAP Search are subject to;
    </para>
    <para>
        <itemizedlist>
            <listitem>
                <para>
                    <xref linkend="form-Architecture_and_Design-Terminology-Bind_Credentials" />
                </para>

            </listitem>

        </itemizedlist>
        <itemizedlist>
            <listitem>
                <para>
                    <xref linkend="form-Architecture_and_Design-Terminology-LDAP_Access_Control" />
                </para>

            </listitem>

        </itemizedlist>

    </para>
    <formalpara id="form-Architecture_and_Design-Terminology-Mailbox">
        <title>Mailbox</title>
        <para>
            A mailbox is essentially a special type of mailfolder, as it is a top-level mail folder. The only level higher then the mailbox name is the prefix (user, shared, DELETED or news). For users, the mailbox corresponds with the user's INBOX. The first level of shared folders however does not truly correspond with a type of special folder like the user's INBOX does.
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-Mailfolder">
        <title>Mailfolder</title>
        <para>
            TODO / Contrary to a mailbox, a mailfolder can be anywhere
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-Naming_Attribute">
        <title>Naming Attribute</title>
        <para>
            TODO
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-Relative_Distinguished_Name">
        <title>Relative Distinguished Name</title>
        <para>
            TODO
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-Root_DN">
        <title>Root DN</title>
        <para>
            TODO
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-Search_Filter">
        <title>Search Filter</title>
        <para>
            TODO
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-Search_Scope">
        <title>Search Scope</title>
        <para>
            Three search scopes exist:
        </para>

    </formalpara>
    <para>
        <orderedlist>
            <listitem>
                <para>
                    base
                </para>

            </listitem>
            <listitem>
                <para>
                    one
                </para>

            </listitem>
            <listitem>
                <para>
                    sub
                </para>

            </listitem>

        </orderedlist>

    </para>
    <formalpara id="form-Architecture_and_Design-Terminology-Transport_Layer_Security_TLS">
        <title>Transport Layer Security (TLS)</title>
        <para>
            TODO
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-Virtual_List_View_Control">
        <title>Virtual List View Control</title>
        <para>
            TODO
        </para>

    </formalpara>
    <formalpara id="form-Architecture_and_Design-Terminology-Unqualified_User_Identifier">
        <title>Unqualified User Identifier</title>
        <para>
            TODO
        </para>

    </formalpara>
</appendix>