|
Version 5.4 |
|
|
Local Delivery Module
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.
The module can limit the number of messages each Account can receive during the
specified period of time. This feature allows the Server to minimize
damage caused by mail loops.
|
|
|
Use the WebAdmin Interface to configure the Local Delivery module.
Open the Mail pages in the Settings realm, the open the LOCAL pages.
- Log
- Use the Log setting to specify what kind of information the Local Delivery 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 Delivery 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 Delivery module records in the System Log are marked with the LOCAL tag.
- Processors
- When you specify a non-zero value for this setting,
the Local Delivery module starts to process queued messages directed to local Accounts.
The module can use several simultaneous processors (threads) 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 processor for message delivery.
- If the Account is full
- When you specify a non-zero value for this Retry setting,
the Local Delivery module checks the Account mail storage before trying to deliver a
message to that Account. If the Account mail storage size is limited, and the specified percent
of that limit is already used, or it would be used when the new message is added, the Local Delivery
module delays all messages directed to that Account. The module retries to deliver mail to that Account
periodically. It 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. If the Retry value is smaller than the Every
value, messages are not kept in the Queue when an Account is full: they are rejected immediately.
- If the Mail Service is disabled
- When you specify a non-zero value for this setting,
messages sent to an Account with disabled Mail Service option are
not rejected immediately, but they are left in the module queue for the specified period of time.
The module tries to deliver the delayed messages periodically.
When the administrator re-enables the Account/Domain Mail Service, the queued messages are
delivered to the Account.
- Suspend
- If the incoming message size is larger than the he Account mail storage limit, the message is rejected.
If the Account mail storage limit does not allow an incoming message to be stored, but the message size itself
does not exceed that limit, the message is delayed.
This setting specifies if the entire message queue for that Account should be suspended (till some messages are removed from that Account or its
quota is increased), or that only this message should be suspended individually (so smaller messages from the same Account
queue can be delivered).
- Send Warnings after
- If a message is delayed in the module queue (because the addressed Account is full or the Mail Service is
disabled for that Account), the module can generate a warning message and send it back to the message sender.
Use this setting to specify when the warning message should be generated.
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.
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 some Secondary Domain name or
its Domain Alias name.
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 (*)
symbol. In this case the name of the unknown local account is used to substitute
the asterisk symbol.
- 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
The 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:
- the domain belongs to a dial-up client system that does not have a static IP address
and thus cannot receive its mail via SMTP;
- the domain has only few POP3 users and you do not want to create a full-featured
CommuniGate Pro Domain to serve them.
- 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 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 sent to:
abcdef@client1.com, xyz@client1.com
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
Router 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 sent to unknown Domain Accounts will be stored in the Account Unknowns, with
all those unknown addresses stored in the message X-Real-To header fields.
After 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.
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.
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).
- Envelope Recipients field
- This setting specifies the name of the message header field the Local module generates
when it stores messages in Unified Accounts.
- Always Add this field
- If this option is selected, the module adds the message header field with the envelope address(es)
to all messages stored in local 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 (+) symbol and some string.
You can set this setting to:
- Disabled
- The Local Delivery module will not process the plus symbols in Account names.
- Enabled
- The Local Delivery module will check for the plus symbol in Account names and delete the first
plus symbol 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 symbol in Account names and
process the string after the plus symbol 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).
The 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.
CommuniGate® Pro Guide. Copyright © 1998-2012, Stalker Software, Inc.