Local Delivery Module

Configuring the Local Delivery Module Routing Routing to Unregistered Accounts Unified Domain-Wide Accounts Automated Mail Processing Storing Mail in Account Mailboxes Direct Mailbox Addressing Routing Settings Sending Mail to All Accounts All-Domain Aliases The Local Delivery module processes messages routed to accounts on your Server. It uses the Mailbox manager to store messages in account mailboxes. The Local module applies account Automated Mail Processing Rules to all messages directed to that account. Rules can instruct the module to store a message in a different mailbox, to redirect a message to different address(es), etc. After a message is stored in an account mailbox, it can be retrieved using any of Access modules. The Local Delivery module can support Direct Mailbox addressing and Account Detail addressing.

---

Configuring the Local Delivery Module

Use a Web browser to connect to the CommuniGate Pro administrator port and open the LOCAL page in the Settings section.

	Log:	Crashes OnlyFailuresMajorProblemsLow LevelAll Info

Processing Processes: 01351025

Keep for 0 secondsminute2 minutes3 minutes5 minutes10 minutes15 minutes30 minuteshour2 hours3 hours6 hours12 hoursday2 days3 daysweek10 days2 weeks if the account is 05075808590959799100% full Keep for 0 secondsminute2 minutes3 minutes5 minutes10 minutes15 minutes30 minuteshour2 hours3 hours6 hours12 hoursday2 days3 daysweek10 days2 weeks if Mail Service is disabled

Send Alerts if Account is 05075808590959799100% full Alert Text:

Log

Use the Log setting to specify what kind of information the LOCAL module should put in the Server Log. Usually you should use the Major (message transfer reports) or Problems (message transfer and non-fatal errors) levels. But when you experience problems with the LOCAL module, you may want to set the Log Level setting to Low-Level or All Info: in this case protocol-level or link-level details will be recorded in the System Log as well. When the problem is solved, set the Log Level setting to its regular value, otherwise your System Log files will grow in size very quickly.

The LOCAL module records in the System Log are marked with the LOCAL tag.

Processes

When you specify a non-zero value for this setting, the LOCAL module starts to process queued messages directed to local accounts. The module can use several simultaneous threads (processes) to deliver messages to several accounts at the same time. If you have more than 1000 accounts, or if you have many accounts with time-consuming automated Rules, you should allow the module to use more than 1 process for message delivery.

Keep if the Account is full

When you specify a non-zero value for this setting, the LOCAL module checks the account mail storage before trying to deliver a message to that account. If the account storage is limited, and the specified percent of that limit is already used, the Local Delivery module delays all messages directed to the account. The module checks the account mail storage periodically and resumes message delivery when some messages are deleted from the account mailboxes.
This parameter specifies how long incoming messages should be kept in the module queue before they are rejected with the account is full error message.

Keep if the Mail Service is disabled

When you specify a non-zero value for this setting, mail sent to an account with disabled Mail Service option is not rejected immediately, but is left in the module queue for the specified period of time. When the administrator re-enables the account/domain Mail Service, the queued messages are delivered to the account.

Send Alerts

This option specifies if and when the Account Quota Alerts should be sent to account users.

Alert Text

Use this setting to specify the text of the alert message that will be sent to the account user when the account is over its quota.

---

Routing

When 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.

Example:

a message sent to the address
abcdef@nnnnn.local
will be accepted with the Local Delivery module, and the message will be stored in the nnnnn account.

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:

Example:

a message directed to the address
abcdef%xyz@nnnnn.domain
will be accepted with the Local Delivery module, and the message will be stored in the xyz account in the nnnnn domain.

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.

Examples:

a message sent to the address

abcdef

will be accepted with the Local Delivery module, and this message will be stored in the abcdef account in the main domain.

 

if subdomain.com is one of the secondary domains, a message sent to the address

xyz@subdomain.com

will be accepted with the Local Delivery module, and this message will be stored in the xyz account in the subdomain.com secondary domain.

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 the name of a secondary domain or their aliases.

---

Routing to Unregistered Accounts

When 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 sign. In this case the name of the unknown local account is used to substitute the asterisk sign.

Example:

the Reroute address is:

bad-*@monitoring.department.com

a message is sent to

james@mycompany.com

where mycompany.com is the domain name of your Server, and there is no account james on your Server.
The message is rerouted to:

bad-james@monitoring.department.com

 

---

Unified Domain-Wide Accounts

The Router can route an entire domain to a certain local account, if the .local domain suffix is used (see above).

Example:

The Router line:

client1.com = Cl1.local

All messages sent to the client1.com domain are directed to the Cl1 local account.

Unified domain-wide accounts are useful if the client systems retrieves messages from your server using the CommuniGate POP, the CommuniGate Pro RPOP, 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 Cl1 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).

Example:

The Router line:

client1.com = Cl1.local

A message is sent to:

abcdef@client1.com, xyz@client1.com

It is stored in the Cl1 account, and a header field:

X-Real-To: abcdef, xyz

is added to the stored message

Note: the
<*@client1.com>= Cl1
foreign alias record also stores all messages sent to the client1.com domain in the Cl1 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.

Messages routed to xxxx%accountname@domainname.domain will be stored in the accountname account in the domainname domain, with the xxx address being added to the message headers as the X-Real-To field.

For example, a Domain Administrator for the company.com domain may use the setting:
Mail To Unknown Addresses is Redirected to:*%Unknowns@company.com.domain
and messages to unregistered domain accounts will be stored in the account Unknowns, with all those unknown addresses stored in the message X-Real-To fields.

---

Automated Mail Processing

After an address is accepted with the Local Delivery module, the message is queued to the Module queue. The Module process(es) takes messages from that queue, open the addresses account and check if the account has Automated Rules specified.

If the account has the 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, it can be redirected to some other address(es), an automatic reply can be generated, etc.

You can use a more detailed Log Level for the LOCAL 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 Mailboxes

After 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 Addressing

The 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

Routing
Envelope Recipients field: Direct Mailbox (mailbox#account): DisabledEnabled Account Detail (account+detail): DisabledEnabledDirect Mailbox

Envelope Recipients field

This setting specifies the name of the message header field the Local module generates when it stores messages in Unified Accounts.

Direct Mailbox Addressing

This setting specifies if direct mailbox addressing is enabled.

Account Detail

This setting controls account detail addressing. Account detail address is an account name followed with the plus sign (+) and some string. You can set this settings to:

Disabled

the Local Delivery module will not process the plus signs in account names.

Enabled

the Local Delivery module will check for the plus sign in account names and delete the first plus sign and all following symbols from the address, then it will re-route the address. Users can use account detail addresses (john+jokelists) to subscribe to mailing lists. Messages sent to account detail addresses will be routed to the user accounts, and Account-level Rules (the Recipient condition) can be used to process those message automatically - for example, to store them in some jokes mailbox dedicated to these list messages.

Direct Mailbox

the Local Delivery module will check for the plus sign in account names and process the string after the plus sign as the Direct Mailbox address. The john+jokelist address will be processed as the jokelist#john address and the message will be routed directly to the jokelist mailbox of the john account, bypassing Account-Level Rules (if the Direct Mailbox Addressing option is enabled).