| Oracle® Beehive Administrator's Guide Release 1 (1.4) Part Number E13797-02 |
|
|
View PDF |
| Oracle® Beehive Administrator's Guide Release 1 (1.4) Part Number E13797-02 |
|
|
View PDF |
This module presents instructions for performing a variety of configuration tasks involving how Oracle Beehive handles e-mail. The instructions in this module assume that you are already familiar with the use of beectl commands to set properties of the E-mail Service. For detailed instructions on setting E-mail Service properties, see "Managing the E-mail Service".
This module contains the following topics:
This section contains the following topics:
Broadly, there are two general methods by which you configure Oracle Beehive E-mail:
Most configuration of Oracle Beehive E-mail not related to setting server-side rules is accomplished by setting parameters of the E-mail Service. The commands, syntax, and a reference of parameters for the E-mail Service are provided in "Managing the E-mail Service". You can also configure many of these parameters using Oracle Beekeeper.
Oracle E-mail stores server-side e-mail rules by using XML-formatted code, stored in various E-mail Service parameters. Manual edits to this XML is not supported.
Beginning with Oracle Beehive Release 1, version 1.4, you should configure Oracle E-mail rules using the Oracle Beekeeper administration console. The console will make changes to the XML in the background.
You must first install and configure Oracle Beekeeper, following the instructions in the Oracle Beehive Installation Guide for your platform.
Oracle Beekeeper includes integrated help topics for many of the configuration options for the E-mail Service. You should refer to the online help for details about the various configuration options.
The SMTP Server component is a robust, scalable, and flexible component of Oracle Beehive that provides open protocol access to the Oracle Beehive E-mail Service. The SMTP Server has been designed to be both Internet and internal facing. The SMTP server can be divided into Virtual Mail Servers (VMSes). Oracle Beehive SMTP Servers may have multiple "Endpoints", and are configured with dispatch rules. These configuration options provide flexibility to facilitate servicing Internet and internal SMTP clients.
Virtual Mail Servers
A virtual mail server is a component which engages in SMTP conversations with clients. Two VMSes are differentiated by their behavior, which is controlled by many properties. For example, SMTP defines a time-out for inactivity. A VMS servicing the Internet may be configured with a low value for this time-out, to prevent service loss. A VMS servicing internal clients may permit a longer time-out (because internal clients are assumed not to be hostile). Time-outs are only one of more than a dozen properties of a VMS. Note that the primary driver for having VMSes is to facilitate different behavior for internal clients compared to external clients.
In Oracle Beekeeper, configuration options for VMSes are found by selecting the E-mail Service, the Configuration tab, and then the SMTP Properties subtab.
The following general concepts apply to Virtual Mail Servers in Oracle Beehive:
SMTP Mail (into and out of Oracle Beehive) is processed by a Virtual Mail Server (VMS)
A VMS is capable of various rule-based processing choices
In a default Oracle Beehive installation, there are two default VMSes configured: Inbound VMS and Outbound VMS
Each VMS has two 'matchers,' which can be used to filter which addresses are acceptable:
a Sender Matcher
a Recipient Matcher
By default, both matchers are enabled for both default VMSes.
The Virtual Mail Server components of Oracle Beehive make use of an Evaluator to determine where and how e-mail messages are relayed. The VMS Evaluator picks which VMS will be used to process the message based on the source of the message or the Endpoint the client connects to.
In Oracle Beekeeper, the VMS Evaluator is configured using the VMS Routing section of the SMTP Properties tab.
The rules for the VMS Sender and Recipient matching decide which e-mail messages are allowed to be delivered to an Oracle Beehive recipient, are permitted by Oracle Beehive to be relayed, or will be rejected.
The following are typical types of rules for how Oracle Beehive relays e-mail messages:
Oracle Beehive accepts e-mail to addresses that it is configured to recognize as local. This generally means Oracle Beehive users, but there may be some special cases where a single domain includes some users in Oracle Beehive and some in another system. In this case, the Oracle Beehive VMS evaluators should be configured so that e-mail may be sent to any address in the domain, and the server determines the correct destination to deliver the message
Messages that aren't addressed to recipients in your local domains are routed to their destination. If the Oracle Beehive server is connected directly to the Internet, then the server can perform MX resolution through DNS to find the IP address of the recipient's server. If the Oracle Beehive e-mail server is behind a gateway or proxy, Oracle Beehive should relay all outbound traffic to some other "smart host" to send it out to the public Internet
Messages that aren't to your domains, and are also not from your local domains, are most likely spam or malicious, and e-mail servers should be configured to prevent or block such traffic
Endpoints
In addition to one or more virtual mail servers, the SMTP server presents "endpoints." Endpoints represent a logical listening point. In this terminology, a web server has two endpoints, one for SSL (port 443) and one for regular HTTP (port 80). In Oracle Beehive, the SMTP server can listen for both traditional TCP traffic from clients (on the traditional port 25 default, or on other ports as well or instead), and for internal traffic from other Oracle Beehive services.
A given SMTP Server may listen for SMTP connections on more than one endpoint, and each endpoint is uniquely identified by a logical name. In most cases, an endpoint works the same as a TCP port. By default, the E-mail Service is configured to "assume single endpoint," meaning it assumes all SMTP connections will be made over a single port.
In Oracle Beekeeper, you can configure endpoints by selecting the E-mail Service, selecting the Configuration tab, and selecting the SMTP Properties subtab.
Dispatch Rules
Dispatch rules map incoming connections to a VMS. The mapping is based on one of the following properties of the incoming connection:
The Endpoint at which the connection arrived (if you have multiple endpoints)
The network (IP) address of the client
The sender's e-mail address contained in the e-mail header
The dispatch rules accept as input these data points, and return the appropriate VMS. Note that in the configuration, the dispatch rules are called "VMSEvaluators".
In Oracle Beekeeper, you can configure dispatch rules by selecting the E-mail Service, selecting the Configuration tab, and selecting the SMTP Properties subtab. Expand the VMS Routing section to view the current rules.
See "Setting Up E-mail Relay Routing" for details about configuring VMS routing.
This section contains procedures for accomplishing a variety of tasks using rules configuration with Oracle Beehive. It contains the following topics:
By default, sent e-mails are not auditable, and are not eligible to be filed as records for Records Management. You can configure either or both of these capabilities, but only after you enable this functionality by setting a property of the Email Transport Properties component. By doing so, you cause an event to be raised whenever an e-mail is sent, and that event can be used in audit or records management policies.
To enable audit policies and records management policies to include sent e-mail messages, use the beectl modify_property command:
beectl> modify_property --component _EmailService:TransportProperties --name SentEmailPluginEnabled --value true
To apply this proposed configuration change, you must run the beectl activate configuration command:
beectl> activate_configuration
You can also modify this property using Oracle Beekeeper.
Note:
After setting the SentEmailPluginEnabled property, you still must create or modify audit policies and records management policies to include sent e-mails.See Also:
For more information about auditing sent e-mails, see:
For more information about filing records for sent e-mails, see:
This section describes how to configure the VMS Evaluator to decide which VMS should process a given message, based on the source of the message (by its hostname or IP address) or the Endpoint the client connects to (if you have multiple Endpoints).
Configure VMS routing using Oracle Beekeeper. Log in to Oracle Beekeeper, select the E-mail Service from the list of services, select the Configuration tab, and then select the SMTP Properties subtab. You can view the existing configuration by expanding the VMS Routing section. You can make changes to the current configurtation by clicking the Manage button.
Note:
Messages internal to Oracle Beehive (from one Oracle Beehive user to another Oracle Beehive user using native clients such as Oracle Beehive Integration for Outlook) are never routed to a VMS Evaluator. They are delivered directly to recipients without requiring the E-mail Service to evaluate or route them.Messages sent using a client that connects to Oracle Beehive using SMTP are routed through the VMS Evaluator.
You can perform the following routing tasks using Oracle Beekeeper:
Modify an Endpoint Filter Rule to configure which VMS messages from a given Endpoint should be routed to
Modify a Host Filter Rule to configure which VMS messages from one or more hosts or IP address ranges should be routed to
Modify the Catchall Rule to configure which VMS messages that do not match any previous rule should be routed to
Add additional Endpoint Filter Rules or Host Filter Rules, by selecting one or the other from the Type dropdown list under Add Mapping Rule, and then clicking the plus sign
Change the order in which filter rules will be evaluated, by clicking the up or down arrows on any rule to promote or demote it in the order
Remove any Endpoint Filter Rule or Host Filter Rule by clicking the red X
When you have finished making configuration changes, be sure to click Apply to apply your changes, or Save and Close to save this proposed configuration without applying it.
In order to prevent your Oracle Beehive deployment from acting as an open relay, you should use a configuration similar to the following:
The Inbound VMS should reject recipients that are not in recognized local domains, and
The Outbound VMS should reject senders that are not allowed (either by mail address or by network location).
Note:
The terms Inbound VMS and Outbound VMS are conventions used as labels for two arbitrary VMSes. In all examples in this module, the Inbound VMS is a VMS being used for inbound e-mail messages, and the Outbound VMS is a VMS being used for outbound e-mail messages. But in both cases, there is nothing special about either VMS other than its particular configuration, which you can modify. You can set up additional VMSes, and remove VMSes, according to your needs.To prevent Open Relay, any VMS that is accepting emails with destinations outside your domain (such as the default sender matcher) should only accept messages from senders that are permitted (local e-mail patterns).
By default, there are no restrictions on the sender pattern matcher, so you should configure it to restrict sender matching as needed.
"Outbound VMS" is for anything originating from Oracle Beehive (either by an Oracle Beehive user through internal Oracle Beehive services, or an Oracle Beehive user through SMTP) and "Inbound VMS" is for anything originating outside of Oracle Beehive (whether sent to an Oracle Beehive user or for relay, if allowed).
There are other ways you could configure Oracle Beehive. For example, you could have multiple end-points and different ports, secured behind port-mappings behind a load balancer or router, and so forth.
One method for preventing Oracle Beehive from acting as an open relay is to set the Inbound and Outbound VMSes using the settings shown in Figure 8-1, Figure 8-2, and Figure 8-3. This example may or may not be appropriate for your own deployment.
In Figure 8-1, "Configuring the Outbound VMS Sender Matcher", the Outbound VMS is set to accept messages sent to any address (in the Recipient Matcher), and accepts messages originating from the internal IP addresses (123.45.67.8 through 123.45.67.10) and a trusted foreign domain foreignhost.us.example.com (in the Sender Matcher). This means that traffic from these sources are considered safe, and acceptable to relay.
Additionally, the Match local e-mail patterns checkbox is checked. This means that local e-mail patterns (set on the General Properties tab) will also be accepted as valid senders by the Outbound VMS.
In a default Oracle Beehive install, *@* is used as the initial setting, which means any client connecting to the SMTP Server will be allowed to send messages, regardless of IP address or sender domain.
Figure 8-1 Configuring the Outbound VMS Sender Matcher
The Inbound VMS Evaluator, as shown in Figure 8-2, "Configuring the Inbound VMS Evaluator", may be left at its default settings. In this configuration example, any external sender (as defined by the Sender Matcher) may send e-mail messages to the Oracle Beehive SMTP Server; however, only e-mail messages with a recipient that matches the local e-mail patterns will be delivered.
Figure 8-2 Configuring the Inbound VMS Evaluator
The Inbound VMS Evaluator by defualt uses the Match local email patterns setting. Local e-mail patterns are set on the General Properties tab. Unless you set a more specific local e-mail pattern, all e-mail addresses are accepted, so the Inbound VMS will accept any e-mail message: even those addressed to external addresses.
Both the Inbound and Outbound VMSes are now making use of the Match local email patterns setting, to determine which domains or patterns are recognized as valid internal recipients and senders of e-mail messages. Figure 8-3, "Configuring Local E-mail Patterns", shows how to set the local e-mail patterns using Oracle Beekeeper.
On the General Settings tab, click the Add Pattern button to add local e-mail pattern(s), according to your internal e-mail domain(s).
Figure 8-3 Configuring Local E-mail Patterns
For any VMS, you can specify a "whitelist". E-mails that match the specified list, which may contain wildcards, are accepted; those that do not match are blocked.
The VMS Evaluator reads the sender's e-mail address, IP, and hostame, and decides which VMS will be used to process the message. Then each VMS has a set of sender and recipient matching algorithms, which act to accept or block e-mail. For example, a typical configuration of the Outbound VMS allows only "internal" users (users with an internal e-mail address) to send e-mail out of the system, which prevents unauthorized users from relaying through the server (a form of spam control).
Each VMS has two properties, Sender Matcher and Recipient Matcher, which are checked during the SMTP transaction between client and server.
By default, the Sender Matcher of the Inbound VMS filters e-mail messages coming in to the Oracle Beehive SMTP server from an external source. In the default configuration, the Sender Matcher accepts e-mails from all senders (it is set to *@* which matches any e-mail address). As long as the sender is in the format of an e-mail address (contains an @ sign), messages from any sender are accepted.
In Oracle Beekeeper, configuration options for VMSes are found by selecting the E-mail Service, the Configuration tab, and then the SMTP Properties subtab. To edit these properties, click the Manage button.
To specify a whitelist, expand the Outbound VMS section and edit the Sender Matcher settings, as shown in Figure 8-4.
Figure 8-4 Configuring an E-mail Whitelist
You can add or remove as many lines as you like.
You can configure Oracle Beehive so that it acts as a relay server, accepting outbound e-mail messages from internal users, and forwarding them along to another SMTP service (such as Sendmail server, gateway, or an Internet Service Provider) for further processing. In Relay mode, you specify one or more servers to which all outgoing messages should be routed. If you specify more than one server, the first server will be used and additional servers will serve as fallback servers.
You can set up a rule that selects between different servers depending on a recipient pattern.
To set up relay servers, perform the following procedure:
Log in to Oracle Beekeeper, select the E-mail Service, select the Configuration tab, and click Manage
Select the Transport Properties tab
If you have only a single Relay server, you can specify it in the Relay Server field, and leave the Use simple relay mode checkbox checked
If you want to specify multiple servers, deselect the Use simple relay mode checkbox, and then expand the Delivery Routing section
Click the + button next to the Type dropdown box to add additional Relays. Click the + button next to the Recipient Pattern field to add additional patterns to match for a given Relay. Click the + button next to the Relay Host field to specify additional fail-over hosts for a given Relay. If you have multiple Relays, you can arrange the order in which the rules will be processed by promoting or demoting the Relay order with the blue up and down buttons.
Figure 8-5 Configuring E-mail Relay Routing
Note:
In addition to the Relay type, you can also specify a Delivery Technique of type DNS-MX. DNS-MX is intended for the use of a DMZ or Internet-based deployment, in which Oracle Beehive will attempt to look up DNS and direct delivery of messages to the corresponding address directly. This configuration is inappropriate for most deployments of Oracle Beehive.When you have finished making your configuration changes, click Apply to apply them immediately, or Save and close to save a proposed configuration without applying it.
Oracle Beehive allows you to specify a virus engine for use in scanning e-mail messages.
Note:
This procedure describes how to add a virus scanning engine. However, to enable virus scanning, you must also follow the instructions in "Managing Attachment Blocking and Virus Scanning".At any time, you can validate virus scan engine connectivity, using the beectl validate_virus_scan_engine_connectivity
beectl> validate_virus_scan_engine_connectivity [ --hostname <scanengine_hostname>] [ --port <scanengine_port> ]
To add a virus scanning engine to Oracle Beehive, perform the following steps:
Install and configure a virus scanning application. In Oracle Beehive Release 1, only Symantec Scan Engine version 5.1.2 or later is supported
Update Oracle Beehive with the virus scanner's host name and port, using the beectl add_virus_scan_engine
beectl> add_virus_scan_engine --hostname <scanengine_hostname> --port <scanengine_port> --validate_connection <true/false>
Note:
You can use this command to add multiple virus scan engines. Issue the command once for each virus scan engine you want to add.Specify a virus scan policy for Oracle Beehive, by using the beectl modify_virus_scan_policy
beectl> modify_virus_scan_policy --scanpolicy <virusscanpolicy>
The following are valid values for <virusscanpolicy>:
NO_SCAN_OR_REPAIR
SCAN_ONLY
SCAN_AND_REPAIR
When the <virusscanpolicy> is set to NO_SCAN_OR_REPAIR, virus scanning is disabled.
Validate and activate your proposed configuration using the beectl activate_configuration
beectl> activate_configuration
After you have added a virus scanning engine, you can enable virus scanning using Oracle Beekeeper.
You can also enable attachment blocking using Oracle Beekeeper. Attachments can be blocked based on the filename's extension, such as ".zip" or ".exe".
You can enable attachment blocking only, enable virus scanning only, or enable both virus scanning and attachment blocking.
If you have enabled virus scanning, attachment blocking, or both, you can customize the notification sent to the addressee (intended recipient).
Caution:
Before enabling virus scanning, be sure that you have followed the instructions in "Adding a Virus Engine to Oracle Beehive". If you enable virus scanning but do not have a virus scan engine configured, Oracle Beekeeper may prevent delivery of e-mail messages, while it stores them in a queue and waits for a virus scanning engine to respond.This behavior is intended to prevent delivery of unscanned messages in the event an external virus scan engine becomes nonresponsive.
To enable virus scanning:
Log in to Oracle Beekeeper, select the E-mail Service, select the Configuration tab, and click Manage
Select the Transport Properties tab
Expand the Virus Scanning section, and select the Activate virus scanning checkbox
You can configure whether to send a notification to local senders, external senders, and administrators, and you can customize the notification message that will be sent
When you have finished making your configuration changes, click Apply to apply them immediately, or Save and close to save a proposed configuration without applying it
To enable attachment blocking:
Log in to Oracle Beekeeper, select the E-mail Service, select the Configuration tab, and click Manage
Select the Transport Properties tab
Expand the Attachment Blocking section, and select the Activate attachment blocking checkbox
You can enable or disable attachment blocking depending on the origin of the message. Click the plus button next to the Origin field to add additional origin filters.
You can specify one or more attachment types to block. Click the plus button next to the Extension field to add additional file extension types to filter.
You can configure whether to send a notification to local senders and external senders of a blocked attachment, and you can customize the notification message that will be sent.
When you have finished making your configuration changes, click Apply to apply them immediately, or Save and close to save a proposed configuration without applying it
To customize the notification to addressees (intended recipients) of messages with blocked attachments or viruses:
Log in to Oracle Beekeeper, select the E-mail Service, select the Configuration tab, and click Manage
Select the Transport Properties tab
Expand the Virus & Bad Attachment Notification section
Enter a Subject and Notification body for the notification
When you have finished making your configuration changes, click Apply to apply them immediately, or Save and close to save a proposed configuration without applying it
Reviewing and Deleting Virus Scan Results
Infection details (including the virus name, virus ID, and so forth) for entities that have been scanned by the Oracle Beehive virus scanner and found to be infected are stored along with the Entity Identifier (Entity ID, Entity Type, CollabID), the date of scan, status of whether the virus was removed or not, number of attempts made to repair the entity, and component within a container (if the entity was a container or multi-part mime message) that was infected.
You can use the beectl list_virus_scan_results
beectl> list_virus_scan_results [ [ --scandate <scandate> ] | [ --scandate_from <scandate_from> ] [ --scandate_to <scandate_to> ] ] [ --virus_name <virus_name> ] [ --virus_id <virus_id> ] [ --entity_type <entity_type> ] [ --obsolete_only <true/false> ] [ [ --maximum_results <max_results> ] [ --display_columns <display_colummns> ] | [ --count_only <true/false> ] ]
The following options allow you to query for specific sets of results:
--display_columns
Use this option to limit what information should be displayed about each result. Enter a comma-delimited list of values. Valid choices are virus_id, virus_name, component_name, scan_date, repair_attempts, entity_id, entity_type, repaired, aux_data, and collab_id.
--scandate, --scandate_from, and --scandate_to
With these options, you can specify a date/time (--scandate) or a range of dates for the results set. Only the results of scans conducted on the specified dates will be shown. Specify date/times using the format YYYY-MM-DDTHH:MM:SS. For example, 2008-07-10T23:59:59 specifies one second before midnight on July 10, 2008
--virus_name, --virus_id
This option will return only results for the exact specified virus name or ID
--entity_type
This option will return only results for the given type of entity scanned. For e-mail messages, the entity type is emsg
--obsolete_only
This option will return only results where the entity scanned (for example, an e-mail message) has been removed from the system (deleted)
--maximum_results
Use this option to specify a maximum number of results to be returned by the query
--count_only
Use this option to return only a count of the results that match
You can delete stored results. You should periodically delete results to avoid consuming an inordinate amount of space in the Oracle Beehive data store. To delete virus scan results, use the beectl delete_virus_scan_results
beectl> delete_virus_scan_results [ [ --scandate <scandate> ] | [ --scandate_from <scandate_from> ] [ --scandate_to <scandate_to> ] ] [ --virus_name <virus_name> ] [ --virus_id <virus_id> ] [ --entity_type <entity_type> ] [ --obsolete_only <true/false> ]
The following options allow you to specify which results should be deleted:
--scandate, --scandate_from, and --scandate_to
With these options, you can specify a date/time (--scandate) or a range of dates for the results to be deleted. Only the results of scans conducted on the specified dates will be deleted. Specify date/times using the format YYYY-MM-DDTHH:MM:SS. For example, 2008-07-10T23:59:59 specifies one second before midnight on July 10, 2008
--virus_name, --virus_id
This option will delete only results for the exact specified virus name or ID
--entity_type
This option will delete only results for the given type of entity scanned. For e-mail messages, the entity type is emsg
--obsolete_only
This option will delete only results where the entity scanned (for example, an e-mail message) has been removed from the system (deleted)
"Dead Letter" is the notification returned for undeliverable messages. Use the following procedure to set up and enable Dead Letter in Oracle Beehive:
Log in to Oracle Beekeeper, select the E-mail Service, select the Configuration tab, and click Manage
Select the Transport Properties tab
Expand the Dead Letter Notification section
You can configure whether to send a notification to local senders, external senders, and administrators, and you can customize the notification message that will be sent
Note:
By default, local and remote senders, but not administrators, are notified of undeliverable messages. If you deselect all three boxes, this effectively disables dead letter functionality.When you have finished making your configuration changes, click Apply to apply them immediately, or Save and close to save a proposed configuration without applying it
You can define multiple endpoints for an Oracle Beehive SMTP server. An endpoint scheme contains a specification of protocol, a string or wildcard used as a filter, and a port. For example, MX:*:2226.
Supported protocols are MX (unencrypted) and MXS (MX using SSL):
MX: the server will use the BTI layer to request an MX server listen for TCP connections on the specified port
MXS: similar to MX, except that the BTI layer will pre-negotiate an SSL session before any incoming connection requests are presented to the application (SMTP/IMAP) layer
The filter is not currently used; you must use * for this value.
Once you have added additional endpoints, when you configure VMS Routing rules, you can add additional Endpoint Filter Rules which route specific endpoints to an identified VMS. See "Configuring VMS Routing to Relay Messages" for details.
Perform the following steps to modify the default endpoint, and define additional endpoints:
Log in to Oracle Beekeeper, select the E-mail Service, select the Configuration tab, and click Manage
Select the SMTP Properties tab
Expand the Endpoint Configuration section
If the Assume single endpoint checkbox is checked, a single port field is listed, which is the configured SMTP server port. All SMTP traffic must be directed to this port. Uncheck the Assume single endpoint checkbox to configure multiple endpoints
If you want, you can modify the default endpoint name and scheme
Create one or more new endpoints using the following steps:
Click the Add Endpoint button
Enter a name and scheme for the additional endpoint
When you have finished making your configuration changes, click Apply to apply them immediately, or Save and close to save a proposed configuration without applying it
In some cases, you may want to configure Oracle Beehive to accept inbound e-mails sent to addresses within an acceptable domain, but of users whose address is not within Oracle Beehive. For example, if your domain is example.com, you may wish to accept (and subsequently relay) a message for User1@example.com, even though there is no User1 in Oracle Beehive.
By default such "invalid local users" are blocked. To enable acceptance of such addresses:
Log in to Oracle Beekeeper, select the E-mail Service, select the Configuration tab, and click Manage
Select the Transport Properties tab
Click the Advanced link to show advanced properties
Check the Accept invalid local users checkbox, as shown in Figure 8-6
Figure 8-6 Selecting Accept Invalid Local Users Checkbox
When you have finished making your configuration changes, click Apply to apply them immediately, or Save and close to save a proposed configuration without applying it
To configure further relaying of such addresses, follow the instructions in "Setting Up E-mail Relay Routing".
You can use dispatch rules to configure domains (and domain IP ranges) for routing outbound messages to the outbound VMS. Domains not specified will not be routed to the outbound VMS.
Use Oracle Beekeeper to make changes to the SMTP Server's VMS Evaluator, which determines which VMS various messages should be routed to.
To configure outbound Dispatch Rules, perform the following procedure:
Log in to Oracle Beekeeper, select the E-mail Service, select the Configuration tab, and click Manage
Select the SMTP Properties tab
Expand the VMS Routing section
By default, there is one Host Filter Rule, which directs traffic from all hosts to the Outbound VMS. You can edit this default rule
Under Add mapping rule, select Host Filter Rule and click the plus button to add additional host dispatch filters. You can select any VMS to route messages to, based on the originating host(s). You can choose IP addresses or IP address ranges, or specify hosts using their fully-qualified host names. Wildcards are accepted
By default, there is one Endpoint Filter Rule, which directs traffic from all endpoints to the Outbound VMS. You can edit this default rule.
Under Add mapping rule, select Endpoint Filter Rule and click the plus button to add additional endpoint dispatch filters. You only need to do this if you have added additional endpoints. You can select any VMS to route messages to, depending on the originating endpoint
You can promote or demote rules using the up and down buttons, which change the order in which the VMS Evaluator processes the rules. The Catch-All Rule is always last
You can designate any VMS for the Catch-All Rule. Messages which are not matched by any previous rule will be matched by the Catch-All Rule and routed to the designated VMS
When you have finished making your configuration changes, click Apply to apply them immediately, or Save and close to save a proposed configuration without applying it
The Local E-mail Patterns property is a list of domains, subdomains, or other e-mail address patterns. Users which connect to Oracle Beehive using a standards-based e-mail application, such as Eudora or Mozilla Thunderbird, should originate from a domain which you recognize as internal. If you choose not to specify local users using the Local E-mail Patterns, you will need to enter this information each time you configure the Sender Matcher or Recipient Matcher of a VMS to recognize local e-mail addresses.
The local e-mail patterns list can be used by VMSes to serve as an exception to a blocking rule, or as a basis for an accepting rule (whitelist).
By default, there is no preset list of local e-mail patterns. You can add local e-mail patterns using Oracle Beekeeper. To specify one or more local e-mail patterns, perform the following procedure:
Log in to Oracle Beekeeper, select the E-mail Service, select the Configuration tab, and click Manage
Select the General Properties tab, and expand the General Settings section
In the List of valid local e-mail address patterns, click the Add Pattern button to add additional patterns
Click the X button to delete existing patterns
When you have finished making your configuration changes, click Apply to apply them immediately, or Save and close to save a proposed configuration without applying it
When you configure any VMS (such as the Inbound VMS or Outbound VMS), you can check the Match local email patterns checkbox in the Recipient Matcher or Sender Matcher, to include the list of local e-mail patterns in the rule.
You may be installing Oracle Beehive in an environment with some e-mail users using pre-existing e-mail domains. You can maintain a common e-mail domain for all users, allowing new Oracle Beehive users to use the same domain, without creating a conflict between the multiple, coexisting e-mail servers.
Example
If a pre-existing user's e-mail address is user1@example.com, and Oracle Beehive is installed on a server beehive.example.com, then configure the co-existing e-mail system to auto-forward user1's e-mail to user1@beehive.example.com. Then, add an additional e-mail address for user1 in Oracle Beehive as user1@beehive.example.com, and add *@beehive.example.com as a LocalEmailPattern.
Note:
This relies on the co-existing system's e-mail forwards being envelope forwards; e-mails will be forwarded and accepted as user1@beehive.example.com, but the message headers will still be user1@example.com, and visible that way to the Oracle Beehive user.To allow this type of coexistence, perform the following steps:
Log in to Oracle Beekeeper, select the E-mail Service, select the Configuration tab, and click Manage
Select the Transport Properties tab
Click the Advanced link to show advanced properties
Check the Accept invalid local users checkbox, as shown in Figure 8-6, "Selecting Accept Invalid Local Users Checkbox". By checking this box, you will allow all e-mails sent to a local address, even if the user or specific e-mail address does not exist in Oracle Beehive
Select the General Properties tab, and expand the General Settings section
In the List of valid local e-mail address patterns, click the Add Pattern button to add patterns. Add the e-mail domain you want to use with Oracle Beehive
When you have finished making your configuration changes, click Apply to apply them immediately, or Save and close to save a proposed configuration without applying it
On the non-Oracle Beehive e-mail system, configure user accounts of Oracle Beehive users to automatically forward to the Oracle Beehive SMTP Server. For each Oracle Beehive user, add the additional e-mail address
|
 Copyright © 2008, Oracle. All rights reserved. Legal Notices |
|
