![]() |
CommuniGate Pro: How To |
||||||||||||||||||||||||
|
|
To use a Shared Mailbox, two steps must be taken: first, potential users of the shared mailbox should be granted access rights for that mailbox. On the second step the user mailers should be configured to access shared mailbox(es). Since these shared mailboxes belong to a different account, they are called foreign mailboxes.
First, the owner of the shared mailbox should create a regular mailbox within his/her account. It is useful to create a special account public and create shared mailboxes in that account. To grant others access rights to the shared mailbox, the account owner should use either a decent IMAP client that can deal with ACL (Access Control Lists) or the WebUser Interface. The WebUser Interface section describes how you can set the desired Mailbox Access Rights.
If a shared mailbox is created inside the public account, it is useful to grant all Mailbox Access Rights to the real shared mailbox owner, so the owner can perform all operations with that mailbox without logging in as the user public.
To access shared mailboxes, user mailers should be configured to display both the user account's own mailboxes, and the available shared (foreign) mailboxes. The most universal method is to use the account Mailbox Subscription list. This list is a simple set of mailbox names, and both account own mailboxes and foreign mailbox names can be included into that list.
Many IMAP clients can only use the Mailbox Subscription list, but they cannot modify it if they do not allow a user to enter foreign mailbox names into that list. In this case, the IMAP users should use the Webuser Interface to fill their subscription lists. If a shared mailbox announce has been created in the account marketing, users should put the ~marketing/announce foreign mailbox name into their subscription lists.
The domain administrator can use the Account Template to specify the initial Mailbox Subscription list, so all new accounts automatically get subscriptions to some shared mailboxes.
When shared mailboxes are included into the Account Subscription List, the users should configure their mail clients to display all mailboxes listed in the Subscription List:
The Server Administrator with the All Accounts access right has unlimited access rights to all mailboxes in all accounts on the Server. The Domain Administrator with the CanAccessMailboxes access right has unlimited access rights to all mailboxes in that domain accounts.
Administrators can use any decent IMAP client to access user mailboxes. That client should be able to let users enter the mailbox name directly. To open the INBOX in the username account, administrators should log in under their own names and tell the IMAP client to open the ~username/INBOX mailbox.
The WebUser Interface can be used for the same purpose. Administrators can log in under their own names, open the Subscription page and type the user mailbox name in the Open Mailbox panel.
To safely back-up the friend.com domain place the following record into the Router table:
Read the Protection section to learn the meaning of the Relay: prefix (you can omit it, or you may want to use the RelayAll: prefix instead).
If you want to relay mail for the friend.com domain, but it should go to via a different server firewall.friend.com, use the following Router record:
If you want to bypass the MX records and relay all mail to a certain IP address (specified explicitly or using a DNS A-record), then see the Bypassing MX section.
The SMTP module does not look at the MX records if the port number of a remote host is explicitly specified. By specifying the standard (25) SMTP port number, you tell the SMTP module to look for the relay.domain DNS A-record, and ignore its MX records.
Note: You may want to add a Relay:, NoRelay: or RelayAll: prefix
To serve such a customer (the client.com mail domain), you should:
To relay mail to the "sibling" server running on the port 26, you can redirect to the domain other-port if you put the following record into your Router table:
To relay mail to the "sibling" server running on the port 25, but on a different IP address 11.22.33.44, you can redirect to the domain other-ip if you put the following record into your Router table:
For example, if all mail to the domain client57.com should go to the sibling server running on a diffent port, place the following records into the Router:
or simply:
To let mail to all customer domains being released with one ETRN command, you should enqueue mail sent to the customer "secondary" domains into the customer "main domain" queue.
If the remote server should receive mail for the domain1.dom, domain2.dom, and domain2.dom domains, but it sends ETRN commands only for the domain1.dom domain, use the following Router domain-level records:
Note: if your company chooses to copy employee mail, it MUST notify all server users about this policy.
To copy mail sent from certain domains, use a Server-wide Rule:
The account security should already exist in the main domain, and the mailbox outgoing should already exist in that account.
The simplest way to implement restrictions is to orginize these groups of users into CommuniGate Pro domains. If all users in the domain dept1.company.dom (expect the user boss) are allowed to send mail only to the users in the same domain and to the address supervisor@hq.company.dom, then the following Server-wide Rule should be used: