|
Version 6.3 |
|
| ||||||||||||||||||||||
Configuring the Local Delivery ModuleUse the WebAdmin Interface to configure the Local Delivery module. Open the Mail pages in the Settings realm, the open the LOCAL pages.
Incoming Message Flow Control
While CommuniGate Pro employs many built-in techniques to prevent mail loops,
in some situations (usually involving other servers) mailing loops still can occur.
To minimize the damage caused by those loops, the Local Delivery Module counts all
messages received by each Account. If this number exceeds the specified limit,
the incoming messages queue for that Account is suspended.
Note: The module counts the number of messages to be delivered to the Account, not the number of messages stored: even if an incoming message is not stored in the Account INBOX because an Account Rule has discarded it, the message is still counted. The Account Mail Transfer Settings specify the incoming flow control limits for each Account. RoutingWhen the Router passes an address to the Local Delivery module, the module checks the domain name: if the domain name ends with the string .local, the Local Delivery module accepts the address, removes the .local suffix from the domain name, and stores the message in the Main Domain Account with that name. This feature is used to create Unified Domain-Wide Accounts.
Sometimes, a Unified Domain-Wide Account should be created in a Secondary Domain, rather than in the Server Main Domain. Use the .domain suffix to direct mail to an Account in a secondary Domain. The last component of the address "local part" will be used to specify the name of the Secondary Domain Account:
When the Router calls the Local Delivery module for "first attempt", the module does not process any other addresses. When the Router calls the Local Delivery module for "final delivery" attempt, it accepts all addresses with an empty domain name part or with the domain part equal to the name of a Secondary Domain, and it routes the messages to the Account specified with the "local part" of the address.
To provide the domain-only routing feature used within the HTTP module, the Local Delivery module accepts all addresses with the LoginPage local part, and an empty domain part or a domain part equal to some Secondary Domain name or its Domain Alias name. Routing to Unknown AccountsWhen the Local Delivery module decides that an E-mail address is a local address, it checks that the Account with the specified name exists. Each Domain (the Main one and each Secondary Domain) has a setting that instructs the Local Delivery module on what to do if a specified Account does not exist. If the selected option is "Rejected", all messages sent to unknown Accounts are rejected, and the error message "unknown account" is returned to the sender. If the selected option is "Discard", all messages sent to unknown Accounts are rerouted to the NULL address, and the Server discards them without generating any error messages. If you select the "Reroute to" option, all messages sent to unknown Accounts will be rerouted to the specified address. That address can be a name of a registered local Account, or it can be an E-mail address of an account on another server: the unknown Account address is substituted with the specified address, and the Router restarts the address processing procedure. The specified "rerouting" address may contain the asterisk (*) symbol. In this case the name of the unknown local account is used to substitute the asterisk symbol.
Unified Domain-Wide AccountsThe Router can route an entire domain (domain name) to a certain local Account, if the .local domain suffix is used (see above). This method is useful if:
Unified domain-wide Accounts are useful if the client systems retrieves messages from your Server using the CommuniGate Pro RPOLL or similar software that distributes retrieved messages locally. Alternatively, the client system can use a regular single-user mailer and then distribute retrieved messages manually. While the information in the local part of the client1.com addresses is not used for routing, it is not discarded. When the Local Delivery module stores the message in the client1 Account, it stores the local parts of the addresses in the X-Real-To: message header field (or other field specified in the Local Delivery module settings).
<*@client1.com>= client1
Router alias record also stores all messages sent to the client1.com
domain in the client1 Account, but if such a record is used, the information
about the local part (Account name) would be lost, and no X-Real-To: head
fields would be generated. The client software that retrieves messages
from this Unified Account would have to rely on the To: and Cc: message
header fields. Those fields do not always contain the correct information,
and they never reflect any change in the local part of the address you
could have done with some additional routing records.
The POP module allows individual users to retrieve mail from a Unified Account, by hiding out all messages that do not contain the specified username in the X-Real-To header field. You usually create Unified Domain-Wide Accounts in the Main Domain.
Use the .domain suffix to create an UDWA in a Secondary Domain.
Automated Mail ProcessingAfter an address is accepted with the Local Delivery module, the message is queued to the Module queue. Each Module process takes messages from the queue, and opens the addressed Account. If the Account has some Automated Rules specified, these Rules are applied: for each rule its conditions are checked, and if they are met, the specified Rule actions are performed. As a result of those actions, the message can be copied to some Mailbox, a copy of the message can be redirected to some other addresses, an automatic reply can be generated, etc. You can use a more detailed Log Level for the Local Delivery module to see which Rules are applied to messages, why some conditions are not met, and what actions have been taken when all Rule conditions have been met. Storing Mail in Account MailboxesAfter Account Rules (if any) have been applied, and these Rules have not specified that the message should be discarded, the message is stored in the Account INBOX. The Local Delivery module checks the current size of the Account Mailboxes and rejects a message if the Account storage quota would be exceeded. Direct Mailbox AddressingThe Local Delivery Module can deliver messages directly to non-INBOX Mailboxes. If the local part of the address is specified as box#name, then the message will be stored in the box Mailbox in the name Account. The Account-Level rules are NOT applied if such an address is used. You can use Direct Mailbox Addressing in the Router Table:; store messages to sales@maindomain ; in the sales Mailbox in the Account public@maindomain <sales> = sales#public ; ; store messages to support@client.com ; in the requests Mailbox in the Account staff in the hq.client.com Domain <support@client.com> = "requests#staff"@hq.client.com Note: remember that Mailbox names are case-sensitive. Note: the Direct Mailbox Addressing feature can be used via the POP module, too. With the sample Router records listed above, when a user logs in using the name sales, the client POP mailer is connected to the Mailbox sales in the public Account (if the user has provided the correct password for the public Account). Routing Settings
Sending Mail to All AccountsThe Domain Settings can be used to enable the virtual object All. Messages sent to the all@domainname address are stored in INBOXes of all Domain Accounts that have the Accept Mail To All option enabled. Note: the individual Account Rules are not applied to messages sent to the all address. The alldomains@maindomain address can be used to send messages to all Accounts in all Domains. |