| Oracle® Enterprise Manager Oracle Collaboration Suite Metric Reference Manual 10g Release 2 (10.2) Part Number B25985-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Enterprise Manager Oracle Collaboration Suite Metric Reference Manual 10g Release 2 (10.2) Part Number B25985-01 |
|
|
PDF · Mobi · ePub |
The SMTP Inbound Server handles incoming SMTP connections and receives messages over those connections. Messages are either delivered locally or placed into queues for further processing.
If the Submit Only SMTP Inbound Server parameter is set to "False", the server receives incoming messages, queries the Oracle directory server to find and authenticate the addresses, rewrites addresses based on the rewriting rules, and applies anti-spam rules. If all the steps are successful, the SMTP Inbound Server accepts the message and inserts it into the corresponding queue based on the destination address.
If the recipient is an outside user, the message is stored in the Relay Queue to wait for further processing. If the recipient is local, the message is stored in the Local Queue. The list of local domains contained in the Local Domains parameter is used to determine if an address is local. The local delivery module picks up the message later, applies the rules, and delivers it to the user's inbox.
To increase throughput, you can prevent messages from being processed immediately by the SMTP Inbound Server by setting the Submit Only parameter to "True". Messages will then be stored into the Submit Queue without any additional processing. The messages will then be processed by the SMTP Outbound Server.
This category graphs various metrics on the receipt and delivery of e-mail messages. Metrics related to delivery are non-zero only if the SMTP Inbound Server has the Submit Only parameter set to "False".
This metric measures the per minute rate at which the SMTP Inbound Server is unable to complete delivery of e-mail messages to the Inboxes of users in local domains. This metric will always equal zero if the SMTP Inbound Server has the Submit Only parameter set to "True". In general, messages are deferred for later processing due to temporary failures that soon correct themselves. Possible reasons for local delivery to fail are:
Folder lock errors (This is the most common reason.)
Database access failures, for example, an Oracle Collaboration Suite Database is down or unreachable
Oracle Internet Directory access failures
Temporay filter processing errors, if filtering is enabled
Temporary rule processing errors
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 53-1 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
2000 |
3000 |
1 |
The message deferral rate is %value% messages/minute |
If the SMTP Inbound Server cannot deliver a message into an Oracle Collaboration Suite Database (mailstore), check to see if the recipient's Inbox is locked. One way to do this is to check SMTP Inbound Server logs for folder lock errors. This situation is generally temporary and does not usually require that you take any action. Also, confirm that SMTP Inbound Server can access the Oracle Collaboration Suite Database and the Oracle directory server. Check for possible filter or scanner failures or server-side rule processing failures.
This metric measures the number of e-mail messages received per minute. Messages can be received both from user clients and from other MTAs.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
Sustained, unusually high rates of incoming messages may be an indicator of a denial-of-service attack or a spam attack. Check to see whether the SMTP Inbound Server is configured as an open relay. Change the logging level of the SMTP Inbound Server to the Notification level. Check the server log files for ESSM-426 messages which describe where connections are coming from, and check for ESSM-427 messages which log the "Sender:" of incoming messages. Use esd_logscan.pl to scan the server log files.
This metric measures the per-minute rate of message delivery to local domain Inboxes. If the Submit Only parameter is set to "True", this metric will always be zero. This is an information metric only.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
This category contains metrics that provide information on network resources used by the SMTP Inbound Server. This includes the number of bytes transfered to and from the SMTP Inbound Server and the number of client connections to this server.
This metric represents a gauge that measures the current number of connections to the SMTP Inbound target that are actively transmitting SMTP traffic.
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 53-2 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
1000 |
1500 |
1 |
The number of active inbound SMTP connections is %value% |
If the number of connections exceeds the threshold, it could be an indication of a SPAM attack or some rogue server/client sending large number of mails. Change the logging level of the SMTP Inbound Server to the Notification level, Refresh the server, and then check the server log files for ESSM-426 messages which describe where the connections are coming from, and check for ESSM-427 messages which log the "Sender:" of incoming messages. Use esd_logscan.pl to scan the server log files.
If you can identify the source sender, host, or IP then take corrective actions to block them. The routing controls can be used for this purpose.
Another possible reason for a high number of connections is that the server is not accepting mails fast enough. This can be caused by a variety of problems.
Insufficent resources on host computers. Check CPU and memory resources on host computers to make sure there is sufficient capacity to handle the workload. Also check for any processes consuming excessive CPU or memory.
Database performance problems or errors. Check the Enterprise Manager pages used to monitor the performance of the database for any warnings or alerts.
Oracle directory server performance problems or errors. Check the Enterprise Manager pages used to monitor the peformance of the Oracle directory server for any warnings or alerts.
If there are no performance problems with the Oracle Collaboration Suite Database or withthe Oracle directory server, and the SMTP Inbound Server is processing at the expected rate, consider increasing the number of processes configured for the SMTP Inbound Server. Also, the throughput of the SMTP Inbound Server can be increased by configuring the Submit Only parameter to "True". It will then do minimal processing on incoming e-mail and leave most of the work to be handled by the SMTP_OUT Server.
This metric represents the number of client connections to the SMTP Inbound Server. The counter is incremented by one as soon as a connection request comes in, and it is decremented when the connection is closed.
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 53-3 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
1000 |
1500 |
1 |
The number of client connections is %value% |
This metric contains information similar to the Current Active SMTP Connections metric. The values of the SMTP and client connections should be relatively close to each other. If the number of Current Client Connections is dramatically higher than the number of Current Active SMTP Connections, this could be an indication that your SMTP Inbound server is under a denial-of-service attack. The Thread Timeout parameter controls how long a connection can remain idle before the connection is closed.
If the number of connections exceeds the threshold, it could be an indication of a SPAM attack or some rogue server/client sending large number of mails. Change the logging level of the SMTP Inbound Server to the Notification level, Refresh the server, and then check the server log files for ESSM-426 messages which describe where the connections are coming from, and check for ESSM-427 messages which log the "Sender:" of incoming messages. Use esd_logscan.pl to scan the server log files. If you can identify the source sender, host, or IP then take corrective actions to block them. The routing controls can be used for this purpose.
Another possible reason for a high number of connections is that the server is not accepting mails fast enough. This can be caused by the following:
Insufficent resources on host computers. Check CPU and memory resources on host computers to make sure there is sufficient capacity to handle the workload. Also check for any processes consuming excessive CPU or memory.
Database performance problems or errors. Check the Enterprise Manager pages used to monitor the performance of the database for any warnings or alerts.
Oracle directory server performance problems or errors. Check the Enterprise Manager pages used to monitor the peformance of the Oracle directory server for any warnings or alerts.
If there are no performance problems with the Oracle Collaboration Suite Database or with the Oracle directory server, and the SMTP Inbound Server is processing at the expected rate, consider increasing the number of processes configured for the SMTP Inbound Server. Also, the throughput of the SMTP Inbound Server can be increased by configuring the Submit Only parameter to "True". It will then do minimal processing on incoming e-mail and leave most of the work to be handled by the SMTP Outbound Server.
This metric measures the number of kilobytes of data received per minute over inbound SMTP connections. Data is received both from user clients and from other MTAs.
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 53-4 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
200000 |
250000 |
1 |
The data reception rate is %value% Kb/minute |
Sustained, unusually high rates of incoming data may be an indicator of a denial-of-service attack or a spam attack. Check to see whether the SMTP Inbound Server is configured as an open relay. Change the logging level of the SMTP Inbound Server to the Notification level, and check the server log files for ESSM-426 messages which describe where connections are coming from. Use esd_logscan.pl to scan the server log files.
This metric represents the number of kilobytes per minute delivered by the SMTP Inbound Server to local domain Inboxes. If the Submit Only parameter is set to True, this metric will always be zero. This is an informational metric only.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
This metric measures the number of inbound SMTP connections accepted per minute. Inbound connections come from both user clients and from other MTAs.
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 53-5 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
1000 |
1500 |
1 |
The SMTP inbound connection rate is %value% connections/minute |
Sustained, unusually high rates of inbound SMTP connections may indicate of a denial-of-service attack or a spam attack. Check to see whether the SMTP Inbound Server is configured as an open relay. Change the logging level of the SMTP Inbound Server to the Notification level, and check the server log files for ESSM-426 messages which describe where the connections are coming from. Use esd_logscan.pl to scan the server log files.
This category contains metrics that provide information about the Up/Down status of the SMTP Inbound Server.
This metric provides information about the Up/Down status of the SMTP Inbound Server and alerts you when the status is down. The SMTP Inbound Server shows a status of Down when all SMTP Inbound processes on the target are down.
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 53-6 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold' | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 5 Minutes |
After Every Sample |
= |
0 |
Not Defined |
1 |
The SMTP Server is down |
You can start the SMTP Inbound Server by selecting the target and clicking theStart button on the Email Application home page. If the SMTP Inbound Server does not start, a probable cause is that the server cannot connect to at least one of the mailstores or it cannot connect to the system's Oracle directory server.
Check that a process on the target host is able to connect to and log into the system's Oracle directory server.
Make sure the Oracle Collaboration Suite Database is up and running and the connect string is correctly and accurately registered in the Oracle directory server.
Check the log files in the OPMN log file directory for errors. Use esd_logscan.pl to scan the log files.
Check the SMTP Inbound Server log files for errors. Use esd_logscan.pl to scan the server log files.
This category graphs various metrics concerning the routing control features of the SMTP Inbound Server. Metrics in this category are applicable only if native spamming is enabled.
The metric measures the per minute rate at which the SMTP Inbound Server detects connection "flooding" from client hosts. Flooding from a host occurs if the number of messages plus the number of connections from a host exceeds a maximum flood count within an allowed interval. Both the flood count and the interval are configurable. When flooding is detected, further connections and/or messages from the host are rejected for the remainder of the current interval and the duration of the next interval.
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 53-7 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
500 |
1000 |
1 |
SMTP routing control flood connection detected: %value% rejected connections/minute |
If the server is experiencing flooding from a host, consider adding this host to the rejected IP address list.
You can determine if the SMTP Inbound Server is experiencing flooding from a host by setting the logging level of the SMTP Inbound Server to the Notification level, refreshing the server, and then checking the server log files for ESSM-502 messages. Use esd_logscan.pl to scan the server log files.
This metric measures the rate per minute of connect request failures due to connection requests for a client associated with a rejected IP address. The detection is based upon configured parameters and flooding of messages or connections from the host. The metric measures client connection rejections due to the following conditions:
Whether the client host's IP address is in the list of rejected IP addresses
Whether the client host's domain, obtained from DNS (Domain Name Service), has an IP address that is associated with a host in the list of rejected host domains. If the client host domain cannot be obtained from DNS due to the DNS check or other failures (temporary or permanent), the metric is not updated even if the host domain is in the list of rejected host domains. However, if the DNS check is enabled, the metric is updated for both temporary and permanent failures from DNS.
Flooding detected from the client's host and, therefore, no further connections can be accepted for a period of time
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 53-8 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
500 |
1000 |
1 |
SMTP routing control client IP address check: %value% rejected messages/minute |
Review the routing control settings to be sure that valid e-mail messages are not being rejected.
If the log level of the SMTP Inbound Server is set to Notification, the server will log ESSM-502 messages when it rejects messages based on the routing control settings.
If the DNS check on the HELO/EHLO domain is enabled, this metric measures the per minute rate of messages rejected because they were sent from a domain that does not exist in the Domain Name Server (DNS) or are due to temporary failures from a DNS query.
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 53-9 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
500 |
1000 |
1 |
SMTP routing control message envelope domain check : %value% rejected messages/minute |
If the value is non-zero, check the logs to see if there is a problem with the Domain Name Service. If the problem cannot be resolved, consider disabling this check. If the domain name indicated in the SMTP_IN command indicates possible spam, consider adding the clients host the the rejected IP address list.
This metric measures the per minute rate of messages rejected because of any of the following problems with the recipient's address:
The maximum number of allowed envelope recipients is reached for this message
The sender and recipient pair is in the configured list of rejected sender-recipient pairs
The recipient is non-local and is in the configured list of rejected recipients
The recipient is non-local and Relay based upon client authentication is enabled, and AUTH command is not given
The recipient is non-local and Relay is disabled.
The recipient is non-local and Relay is enabled, and the domain of the recipient does not match any domain in the configured list of allowed relay domains
The metric is not updated if the mail is determined to be trusted even if one of the above conditions are met.
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 53-10 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
500 |
1000 |
1 |
SMTP routing control message envelope rcpt check : %value% rejected messages/minute |
Review the routing control settings to be sure that valid e-mail messages are not being rejected.
If the log level of the SMTP Inbound Server is set to Notification, the server will log ESSM-502 messages when it rejects messages based on the routing control settings.
This metric measures the per minute rate of messages rejected because of any of the following problems with the sender's address:
The sender is in the list of rejected senders
The sender's domain is in the list of rejected sender domains
Comparing authenticated ID with envelope sender is enabled, the AUTH command is invoked, and the sender does not match the Auth Id
DNS check on sender domain is enabled, and no record exists for the sender domain
Flooding is detected from the host
The metric is not updated if the mail is determined to be trusted even if one of the above conditions is met.
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 53-11 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
500 |
1000 |
1 |
SMTP routing control message envelope sender check: %value% rejected messages/minute |
Review the routing control settings to be sure that valid e-mail messages are not being rejected.
If the log level of the SMTP Inbound Server is set to Notification, the server will log ESSM-502 messages when it rejects messages based on the routing control settings.
This metric determines the rate per minute of DATA command failures due to the presence of rejected headers in the message. A message header is rejected when one of the following conditions occur:
When Comparing Authenticated ID with Sender in the header (based upon the From: and Sender: fields) is enabled and, 1) Auth command is given, and 2) Auth Id does not match the one in the header
Comparing envelope sender with header info is enabled, and the envelope sender does not match that of the header.
The message has an attachment that matches one in the list of rejected attachments
One of the header fields is in the list of rejected header fields
The metric does not get updated if the third or fourth conditions are met and the mail is determined to be "trusted".
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 53-12 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
500 |
1000 |
1 |
SMTP routing control message header check : %value% rejected messages/minute |
Review the routing control settings to be sure that valid email messages are not being rejected.
If the log level of the SMTP Inbound Server is set to Notification, the server will log ESSM-502 messages when it rejects messages based on the routing control settings.
|
 Copyright © 2006, Oracle. All rights reserved. Legal Notices |
|
