Every Domain in Kiwi is handled as a separate protected entity that is securely isolated from all other domains. Each domain however is a child of the "Global domain", often referred to as the "Global Policy" domain. For example in the figure below you can see that both "localhost.localdomain" and "yourdomain.co.uk" are listed underneath the "Global Policy" domain.
In practical terms this means that if you are providing the role of an ISP for example, you need only define a Global policy and then all subsequent domains that get hosted on your server will inherit the rules you have set out in the Global Policy domain. This not only applies to Domain properties but also to 'User Account' properties.
Kiwi recognises four types of domains:
Of the four domain types listed, only the last three can be created by the server administrator.
The Global Policy domain is automatically created each time Kiwi is started regardless of missing configuration data. This means that if you accidentally delete one or more of the system policy files each Kiwi service has enough information to restore a clean "Global Domain Policy".
A "Local Domain" is defined as a domain that has all it's data stored on this server instance. This includes Domain Properties, Domain Website, User Accounts Properties, User Account Website and User Account Message Stores.
A "Mail Relay" domain is a special type of domain that means the local server instance will accept potentially both inbound and outbound email for a 3rd party. Any Inbound messages will remain in the local message queue until the 3rd party mail server collects them. Other than Mail server properties the local Kiwi services will hold no other information for this domain.
Virtual Domains are simply a pointer to a "Local Domain", they can also be referred to as a "Domain Alias". These types of domain are especially useful if you are offering a SOA (Service Orientated Application) Web Application.
Kiwi recognises three types of User Accounts:
This is a special type of account that allows the Server Administrator to grant 3rd party applications access to the Local Services Management service. You must ensure that you thoroughly trust the 3rd party application prior to creating and handing over these Account details. It is recommended that you create separate accounts per Application so that you can add Application traceability in the event that problems arise.
This type of Account conforms to the SMTP RFC2821 document (Section 3.10.2) which states the following:
A mailing list may be said to operate by "redistribution" rather than by "forwarding". To expand a list, the recipient mailer replaces the pseudo-mailbox address in the envelope with all of the expanded addresses. The return address in the envelope is changed so that all error messages generated by the final deliveries will be returned to a list administrator, not to the message originator, who generally has no control over the contents of the list and will typically find error messages annoying.This is typically the type of Account you would create for each of your Users and as default inherits full access to all local services.
Adding a new Domain in Kiwi can be achieved by three different methods:
We will not go into the last option here as it is beyond the scope of this document.
The administration application allows Server Administrators to create all three Domain Types that are currently supported by Kiwi:
Note that there is no upper limit on the number of Domains you can add to a local Kiwi Instance, you're limiting factors are far more likely to be Processor speed, Bandwidth and available Storage capacity.
To create a new Domain you will need to choose the appropriate Domain Type from the System Overview page as shown below:
Once you have chosen the appropriate Domain Type all that is required to begin the process of Adding your Domain is to enter the Domain Name.
Alternatively you can also specify an IPv4 Address as the Domain name, although this is no longer recommended. If you require IPv4 support, for example to provide loopback addressing for Web clients (http://127.0.0.1) then it is recommended that you add a Virtual Domain to accomplish this.
This section is only relevant to Local Domains
Adding a new Domain in Kiwi can be achieved by three different methods:
We will not go into the last option here as it is beyond the scope of this document.
The administration application allows Server Administrators to create all three Account Types that are currently supported by Kiwi:
Note that there is no upper limit on the number of User Accounts you can add to a local Kiwi Instance, you're limiting factors are far more likely to be Processor speed, Bandwidth and available Storage capacity.
To create a new User Account you will need to either Sign-In as a Domain Administrator or choose the appropriate Domain from the Local Domains page if you are a Server Administrator. Within the Domain Administration section you can then select the Accounts page and then proceed to Add the new User Account as shown in the screenshot below:
All that is required to begin the process of Adding your Account is to enter the Account Name. In Kiwi an Account Name must be no more than 64 Alphanumeric characters in length.
As you can see from the above screenshot Kiwi currently supports the following SASL methods as standard:
These SASL methods are provided via the Kiwi Authentication plug-in and you are free to extend Kiwi with your own custom authentication handlers by using the Kiwi 3rd party API. You will notice that the SASL methods are listed above in order of preference, with PLAIN and BASIC listed last and as such you are recommended to consider these methods deprecated and not fit for purpose. As per the relevant RFC documents the PLAIN authentication method is never advertised by a Kiwi service even when it is enabled.
All Domain User Accounts will inherit this policy unless you explicitly override the Account Authentication policy.
This option is recommended to be enabled. Without this option enabled you are allowing all local clients (as defined by the Local Network Address Table) free access to relay Mail through the kiwi/Mail Server, and with Spam being as prolific as it is today you are urged never to fall into this trap.
When you add a new domain to your local Kiwi instance it will automatically inherit the Access Control from the Global policy, as default this means that it will bind to the local Network Adapter (listening on all IP Addresses) and that User Accounts have full access to all local Kiwi services.
Unlike a Domain "Access Control" is limited to just Service Access, and this is inherited from the Local Domain policy. Like the Local Domain policy this can be refined on a per User Account basis.
Kiwi/Mail Server supports both Sender and Recipient Black-Lists as standard. Subject to User permissions you can setup Global, Domain and User Account Policies, however standard User Accounts can only maintain their Sender Black List via kiwi/WebMail Account Settings.
Currently an entry on a Black List can be:
When a Black list entry has been caught you can also tell the Policy Engine what action it should take:
As shown in the figure below:
To enforce Domain & User Account security Kiwi includes built in support for the following types of User Groups:
A User Account is permitted to be a member of one or more these User Groups.
This group is typically used by Applications that run on the system that want to interoperate with the Kiwi Local Services Management system. You should not grant this group to end-users as they then inherit sweeping access to global properties.
Users that belong to this group have full access to all properties held on this Kiwi instance including the addition or removal of new user groups for their own purposes, however these will be ignored by the Kiwi services. They are also granted the rights to Add & Remove Domains.
Users that belong to this group can only change properties that belong to their respective domain, this includes the properties of all User Accounts within that domain. They are also granted the rights to Add & Remove User Accounts.
Users that belong to this group can access other Users properties and also have permission to Add & Remove User Accounts.
All Domain User Accounts created will automatically inherit this permission so that they have sufficient privilege to maintain their own properties (within reason).
This group allows you to create properties that are visible to all users of the local Kiwi instance.
As default Kiwi will only create the mandatory (as per the relevant RFC) "INBOX" mailbox in a User Account's MessageStore. However most user's today expect to see a default Personal MessageStore that contains something similar to the Outlook or Thunderbird clients default layout such as:
Some Email clients have even extended this further to include Contacts, Notes, Tasks and even Calendering. To enable this functionality you can configure Kiwi via the Domain Administration -> Default Mailboxes pane to automatically create these additional mailboxes during the Account creation phase.
As you can see from the screenshot above you can also specify the type of mailbox Kiwi should create. Note that you can further extend this to support your own custom Mailbox storage types (Calendar, Tasks, Jobs, et al.) by changing both the kiwi/Web Administration and kiwi/Webmail application. However unless you create an RFC standards based message type ie. iCalendar your clients will be restricted to your customised kiwi/Webmail application.
This section is only pertinent to Distribution List User Accounts
When you create a new Distribution List User Account you can Add/Remove List members via the following methods:
At present there are no upper limits on the number of members in a list.
A note on List expansion
The kiwi/Mail server list exploder is designed to closely (if not exactly) follow RFC2821 (Section 3.10) regarding list expansion so no heuristics are applied to your Distribution list to remove any entries (ie. Duplicate Email Addresses).
Before kiwi/Mail Server can route any Email messages you need to explicitly tell it what SMTP transport methods it should use to route both "Inbound" and "Outbound" Email messages. If you are using an ISP or 3rd party hosting provider they will supply this information.
If you are unfamiliar with SMTP Message Routing it is recommended that you familiarise yourself with the various Message routing and transport methods below. If you already comfortable with these methods or have the necessary information at hand you can skip the following few sections.
This defines a method whereby a 3rd party domain mail server will connect to your mail server and issue an ESMTP 'ETRN' command, your mail server will then check it's message queue's and either issue a 'No pending mail' or an acknowledgement that their are currently queued messages which will now added to the MTA process queue. To complete the message delivery the MTA will obtain the remote Mail Server's IP address by querying DNS (See MX method below for more information).
This is a variation of the ETRN method in that the remote mail server must authenticate prior to issuing the E-SMTP 'ATRN' command, and secondly that once authorisation has been granted the mail servers then swap roles (client becomes server, server becomes client). Your mail server swaps role and now acts like a client and begins transmitting any mail currently pending in the message queues.
This method is popular with small businesses that don't have a permanent Internet connection or a static IP address, a typical mail server will perform the following steps:
This method indicates that message transfer is resolved by querying the DNS for the recipient's MX (Mail eXchange) records, from this your MTA will obtain one or more IP addresses of the remote mail servers that are responsible for the recipient's messages.
Static routing is used in environments where an organisation may have multiple mail servers and this particular server instance is not directly connected to the Internet but maybe one or more hops behind the Internet gateway mail server. By using this method all mail will be forwarded to this statically defined server. At present only 1 IP address can be specified however, in the future this will be changed to support multiple servers with 'server scores' much like DNS MX records.
This section is only pertinent to Mail Relay Domains
When you host a Mail Relay domain you need to tell kiwi/Mail server how it should relay any pending Email messages that wind up in it's message queue(s) waiting to be delivered to this Domain. Typically the Mail Server that "owns" this Domain would be configured with a periodic 'PULL message(s)' schedule similar to the following:
kiwi/Mail server also supports a 'PUSH' method where it will automatically connect to the "owning" Mail Server via a "STATIC" configuration (See Mail Routing above) when it has pending Email messages for this domain. See figure below.
When you create a new 'Mail Relay' Domain it is not permitted to Relay Email Messages beyond the scope of this local Server instance. Which simply means that the domain will be allowed to send Email Messages (subject to individual Domain policies) to all other Domains configured on this Instance, but Messages to all other foreign/external Domain's will be rejected.
You can permit Mail Relay via the "Message Relaying" pane by simply clicking "Enable Mail Relay" checkbox and specifying a local User Account which the remote Mail server must use to authenticate itself - See screenshot below.
When a New Account is created either manually by an Administrator or Programmatically you can configure Kiwi to automatically execute the New Account kiwi/Script. This is particularly useful if you want to automatically send to newly registered users a 'Welcome' or 'Introductory' Email Message.
As default your New Account Script is run under the new User Account's context but both the Server and Domain Administrators can override this via the "New Account Script" pane as shown below:
Note that Domain's do not have to have a script defined as they will inherit the Global Policy script which the Server Administrator can predefine.
When a New Domain is created either manually by an Administrator or Programmatically you can configure Kiwi to automatically execute the New Domain kiwi/Script. This is particularly useful if you want to automatically send to newly registered Domain a 'Welcome' or 'Introductory' Email Message.
As default your New Domain Script is run under the new 'Postmaster' User Account's context but the Server can override this via the "New Domain Script" pane as shown below:
Note that Domain's do not have to have a script defined as they will inherit the Global Policy script which the Server Administrator can predefine.
Kiwi supports a number of Message based policy rules that can be applied to the Global Policy, Local Domain and individual User Accounts (see Inheritance below) so that you the control the following properties:
kiwi/Mail server supports direct Mailbox delivery as described in RFC ????, which states that a Sender can request that their Email Message be directly delivered into the named Mailbox as specified in the Recipient Email Address. For example if you have a User Account called 'test@localhost.localdomain' a Sender could address their Email message to 'test+Drafts@localhost.localdomain' requesting that the MessageStore save this message into the recipients 'Drafts' mailbox.
Of course without proper Access control this scheme is wide open to abuse, and as such the MessageStore implements an ACL (Access Control List) per mailbox whereby each Sender must be granted the 'Post' permission to succesfully perform this action. You can see the 'Folder Sharing' pane from kiwi/Webmail below that a User Account may used to maintain a mailbox's Access Control List.
In addition to the above ACL you can also extend this policy even further by telling the Policy Engine what action it should take when one of the following conditions are met:
At present the Policy Engine supports the following actions:
As shown in the figure below:
Delivery Notifications primarily get raised by the kiwi/Mail server whenever:
The policy rules that have been triggered get aggregated into a DSN (Delivery Status Notifications) Object that is exposed to the DSN script that gets started.
You can see from the figure below that you can control who and when a DSN policy message is raised.
Unfortunately whilst DSN's were a great idea to keep Users notified about message delivery problems some Mail servers would include the original message in the notification. This was then immediately grabbed upon by mailicious users using forged Sender addresses to proliferate spam from legitimate servers!
The default Kiwi DSN script does not include the original message, rather it simply states the message ID of the offending message. As a Server/Domain administrator you can create your own custom DSN script but you should familiarise yourself with the published RFC documents (of which their are many! - See references below)
When a DSN script is invoked you can set what User Account context the script should run in, as default it is run under the "Postmaster" User Account. Note that Domain's do not have to have a DSN script defined as they will inherit the Global Policy DSN script which the Server Administrator can predefine.
After an Email message has been processed by the Policy engine and is cleared for delivery to a User Account's Message Store the Server Administrator (via Global Policy), Domain Administrator (via Local Domain Policy) and User Account (via Account Policy) all get a chance to execute both Pre and Post (MessageStore) Delivery scripts.
Prior to delivering the message to a User Accounts MessageStore the Pre-Delivery scripts get processed in the following order:
Each of these scripts can directly affect what happens next to the message, for example if the Global Policy script determines that the message breaks some rule, ie. a message body contains an offensive word or confidential data it could raise a Policy error.
Now the Local Domain & User Account scripts will no longer be processed and the message will be passed back to the Policy Engine for DSN Policy & Script processing.
In addition to raising Policy errors each Pre-Delivery script can affect the MessageStore delivery with the following actions, note that the next Pre-Delivery script to execute will overwrite the previous Pre-Delivery scripts actions -- unless the message has been deleted.
Once the Email message has been successfully delivered to the User Accounts MessageStore the Post-Delivery scripts get processed in the same order as the Pre-Delivery scripts, however in this case no actions can be applied so each of these scripts is guaranteed to be processed.
You might be wondering what is the point of a Post-Delivery script?
The logic is actually quite simple:
If you want to notify a User via their Mobile phone (SMS alert) or via an Instant Messaging service of the new message arrival the only way you can guarantee successful MessageStore delivery is after it has occurred, otherwise the User ends up receiving spurious alerts to phantom messages that were rejected by the Pre-Delivery scripts.
At present both the Pre and Post Delivery scripts run synchronously, however in future the Post delivery script will be executed Asnychronously. You should also be aware that each script runs in the context of the destination User Account.
Message Auto Replying can often be referred to in 3rd party Email clients as an "Out of Office" rule and is triggered when a new message has been downloaded by the client software. This rule will subsequently auto-generate a reply based on some pre-defined message text which will then be returned to the Sender.
Unlike the above, Kiwi Auto Replying runs server side and is triggered as soon as a message is received by a User Accounts Message Store. As standard Auto Replying consists of two policies:
This policy allows you to refine who does & does not receive a message and the frequency with which they get an Auto Reply message, ie. Once or every n'th message.
In the figure above you can see the Auto Reply Policy pane for User Accounts, whilst this isn't the most comprehensive solution to Auto Replying / Out of Office message handling it is important to realise that you can easily extend this with your own custom Auto-Reply scripts.
Once the Auto Reply policy has been triggered kiwi/Mail Server will execute the Auto Reply script with the Policy details as shown below:
Auto Reply scripts run synchronously and are executed in the context of the destination User Account.
User Accounts can refine the Auto Reply policy for each Identity by additionally specifying what the return Subject & Message should be according to whether the Sender Email Address is their own Domain, a local Domain on this Kiwi Instance or for all other Domains.
Forwarding permits you to forward all Messages prior to MessageStore delivery to other recipients directly from kiwi/Mail Server, you may also choose to delete the message as part of this process.
A User Account is able to configure this using their Account Settings via Kiwi/WebMail
The Kiwi Message Policy Engine allows you to analyse both Inbound & Outbound Messages for Attachments and then apply your own custom policies on them. To create your own Attachment policy you need to tell the Policy Engine what kind of Attachments it should be applied to. As you can see from the figure below you have the following options available to you:
Only the "Attachments named" option requires more information which in this case is a filename. You can either explicitly specify a name ie. "test.exe", or you can use a wildcard to pick out certain types of files, for example if you wanted to intercept all executable Attachments you would enter the filename as '*.exe'. The Policy engine is currently being extended to automatically detect the filetype from analysing the attachment data - thus enabling you to also pick out obfuscated files that Microsoft Windows would still execute.
Once an Attachment has been identified by your Policy rule you then have to decide what you would like to happen to either the Attachment or the Message as a whole. At present have the following options available to you:
If you choose to modify the Attachment either via replacement Message body, Renaming it, or Removing it from the Message you should be aware that if this Email Message was digitally signed the signature will no longer be valid and the recipient will be alerted by the Email client software.
In addition to the above options you can also choose to trigger a DSN (Delivery Status Notification) policy message to be generated for the Sender. This message will contain the Policy text that you specified with this Attachment policy, as shown below:
Currently the Kiwi Message Policy engine processes Policy rules in the following order:
Message footers can be appended to all outbound Email Messages that are sent from local User Accounts. Depending on the Email client and preferences of the User, the kiwi/Mail Server is likely to see two different formats of Email messages:
For the purposes of illustration both the examples above exclude Attachments.
Currently the kiwi/Mail server permits you to specify alternative footers for both the 'text/plain' and 'text/html' parts of the Outbound message as illustrated in the figure below:
Note that both kiwi/WebMail and kiwi/Web Administration could be easily modified to present a single rich edit control supporting HTML which could then simply filter the input so that Kiwi/Mail Server is presented with both 'text/plain' and 'text/html' variants.
These footers are applied server-side and as such if your User Accounts are using 3rd Party Email clients that apply Digital Signatures at the time the message is sent, the addition of the footers will invalidate the signature alerting the recipient that the message may have been tampered with. Unfortunately the only fix to this issue is for the User to use kiwi/WebMail (with Digital Certificate support) or for the Message footers to be turned off.
As with the Attachment policies, Message footers are likewise processed in the following order:
Including Script code in Message Footers
The Policy Engine permits kiwi/Script code to be embedded directly in Message footers with the standard script encapsulation Start and End Tags: '<$' and '$>'. However, as default this functionaility is turned off and must be enabled via the Global, Domain or User Account properties control panel. See figure below.
An extract from RFC2821 - Section 3.10.1 Alias
To expand an alias, the recipient mailer simply replaces the pseudomailbox address in the envelope with each of the expanded addresses in turn; the rest of the envelope and the message body are left unchanged. The message is then delivered or forwarded to each expanded address.Kiwi/Mail server Identities are based upon the above citation from RFC 2821. Every User Acount in a Local Domain can have an unlimited number of unique Identities (Aliases). This has also been expanded upon so that for each unique Identity a User Account may then associate a number of policies with each of these Identities.
At present Kiwi allows a User Account to associate three policies per Identity:
At present each Identity's Directory Entry includes the follow properties (none of which are mandatory):
As a Domain or Server Administrator you are free to extend this Directory with an unlimited number of further properties, but you are responsible for ensuring the accuracy of this information as the Kiwi property store does not currently support data typing.
A Domains Directory List of which an User Accounts Identity forms will get aggregated into the local Kiwi Instances' Global Address Book. For example, we have a local Kiwi Instance which has the following configuration:
As you can see from the above Kiwi configuration each User Account has three Identities (User Account + 2 further Identities). When this information gets presented in the Global Address Book each Identity will be listed sequentially underneath their respective Domain name as shown below:
As you can see from the above list each Directory Entry (Identity) has been listed, and in this particular scenario is visible from both Domains. If you are hosting Domain's for 3rd parties the last thing you want is for every Domain's Directory Lists to be globally visible. Currently Kiwi allows you to control the visibility of an Identity and each Directory Entry section therein, at present you have the following options:
Kiwi permits you to setup Global, Domain, and User Account Quotas for the following areas:
As you can see in the Global Policy Control panel shown below:
As this is the Global policy for this Server Instance only a Server Administrator has sufficient rights to change this Quotas. When a new Domain or User Account is created these Quotas are automatically inherited.
The 'docs' folder contains all files that will be accessible to Web clients, subject to the folder properties.
The 'errors' folders permits you to specify alternative Error Document's rather than the very basic documents that are provided as standard. For example if you wanted to override the '404 Page not found' standard response document you would simply copy a '404.htm' file into this folder.
This folder has been kept for backwards compatibility to prior Web Servers and is primarily used to keep the server-side CGI scripts separately from the Web Site content.
If you permit Web clients to browse a Folder structure (Parent folder must be within 'docs') the kiwi/WebServer contains a 'Rich' Folder view showing File-Type Icons and Associated helper Icons to assist the Web User, by uploading new Images into this Folder you can override the default Icons.
If you need to override a Domain or User Accounts Web Store paths for any reason (new Hard Disks, lack of disk space, etc.) you have the option to change individual Web Store folder paths or even specify an entirely new Web Store path as shown in the screenshot below.
Initially Domain & User Account Web Site's are disabled by the Global Policy so will not be loaded by the kiwi/WebServer. You can enable a Web Site simply by checking the 'Allow Website' checkbox on the relevant 'Web Site' control panel page as shown below:
Domain Web Sites are accessible via their respective Domain name, however for Local Accounts the Server & Domain Administrators have a choice as to how their Web Site will be accessed. Currently Kiwi supports the following Access Methods:
For both Domain & User Account Web Sites you would typically access them by typing their Addresses into a Browser Address Bar. For example the domain 'localhost.localdomain' would be reached by the Address 'http://localhost.localdomain'.
However if you're clients are behind a router that doesn't provide NAT loopback you may find yourself unable to access your locally hosted Domains as the router will not pass the requests back to the local Server but instead try and process the request itself. Unfortunately there is nothing Kiwi can do itself to solve the DNS NAT routing problem but it does provide a 'Domain folder Alias' hack.
A Virtual folder is a mechanism by which you can create a Folder that points to another "Real" folder in a different location. Depending on permissions this folder may reside outside of a Domain or User Accounts Web Store.
As you can see from the above screenshot an Administrator can change how a Domain or User Account's Virtual folders will behave, currently Kiwi supports the following options:
Needless to say the last option should not be given lightly.