Skip to content
CA Service Management - 14.1
Documentation powered by DocOps

Define a Mailbox

Last update December 29, 2017

This topic contains the following information:


CA SDM provides a default mailbox to connect to the mail server. You can configure this default mailbox to change the password, user name, hostname, and so on. You can also create extra mailboxes to suit your organizational needs. Each mailbox can have its own definition, instead of using a single global set of definitions. You can define multiple mailboxes and can use different templates or default values for each mailbox. Multiple definitions allow individual tenants or organization use separate mailboxes with different settings.

Use the Default Mailbox or Create a Mailbox

CA SDM provides an active default mailbox. You can edit the mailbox for incoming mail delivery according to your requirement or create a mailbox that connects to the mail server. Configure the mailbox to set values for host, user, password, and so on.

Follow these steps:

  1. Select Email, Mailboxes from the Administration tab.
    The Mailbox List page opens.
  2. Click Default from the Name column and click Edit to edit a default mailbox or click Create New to create a mailbox.
  3. Complete or update the other fields as appropriate:
    • Check Interval
      Specifies the time after which the mail server is polled for new emails.
    • Active
      Indicates the mailbox status.
    • Email Type
      Specifies the protocol that the mail server uses. CA SDM supports both POP3 and IMAP4. If you select IMAP4, CA SDM polls only the Inbox folder from the mailbox.
    • Hostname
      Specifies the hostname of the email server.
    • Port Override
      Specifies the port number when the default port number is overridden.
    • User Name
      Specifies the user ID on the mail server.
    • Password
      Specifies the password on the mail server.
    • Security Level
      Specifies the SMTP security level.
    • Attachment Repository
      Specifies the repository where the email attachments are stored.
    • Attach Entire Email
      Specifies whether to allow entire email as an attachment.
    • Force Attachment Splitout
      Specifies whether to split all attachments in the email when an entire email is added as an attachment. The email and its attachments are split into separate files and attached to the tickets. Only applicable when the Attach Entire Email option is selected.
    • Allow Anonymous
      Specifies whether tickets can be created from anonymous mails.
    • Save Unknown Emails
      Specifies whether to save the emails that the rules defined in the mailbox did not process. These emails are stored in $NX_ROOT/site/mail_unknown.
    • Use Reply-To Address
      Specifies whether to use the alternate email address for replies.
    • Use TLS
      Specifies whether to use Transport Layer Security support in emails.
    • CA Certificate Path
      Specifies the path where the trusted certificate has been deployed.

      Note: For the advanced availability configuration, ensure that you deploy the trusted certificate on the same location for both background and standby servers. CA SDM supports only Base-64 encoded (PEM) format for CA Certificates.
  4. Click Create New from the Rules tab to create a mailbox rule.
    The Create New Mailbox Rule page opens.

  5. Complete the Mailbox Rule Fields as appropriate and click Save.
  6. Select the Policy tab to define the mailbox policies to protect your organization against certain types of email abuse. Complete the Mailbox Policy Fields as appropriate and click Save
    The changes to the default mailbox are saved and applied or a new mailbox is created. The first poll occurs after one second.

Mailbox Rule Fields

Important! We recommend that you set the associated mailbox to Inactive before you configure a mailbox rule. Else, any messages that are retrieved between the first and the last change are processed with rules in effect.

The table (usp_mailbox_rule) maintains the rules that are used to connect to each mail server account (usp_mailbox). CA SDM provides predefined rules which you can use to modify or create mailbox rules.

Complete the following mailbox rule fields, as appropriate:

  • Sequence
    Specifies the sequence number of the rule. Messages are checked against rules in sequence number order from lowest to highest.
  • Mailbox
    Specifies the mailbox to which this rule belongs.
  • Active
    Sets the rule to active or inactive.
  • Filter
    Specifies what part of the email to search for the filter pattern, for example, Subject contains. For more information, see the Pattern Matching in Mailbox Rules topic.
  • Filter String
    Specifies a regular expression string to match with the email content. For example, [\t\r\n]request[\t\r\n].  The placeholder {{object_id}} lets you specify the artifact value for the Text API to use for associating the message with a specific ticket. For more information, see the Filter String Object Identifier Restrictions and Special Characters in Regular Expressions topics.
  • Ignore Case
    Specifies whether to consider letter case when matching patterns.
  • Action
    Specifies the action to take when the filter criteria matches, for example, Create/Update Object. 

  • Action Object
    Displays the type of ticket object to which message actions apply, for example, Request.
  • Minimum Artifact Type
    Sets the minimum type of artifact checking that you want to allow:
    • NONE
      Specifies no validation of artifacts. This value is the same as not adding the keyword to the input file. Also accepts Text API ticket ID commands.
    • PROTECTED
      Validates a ticket against the hash for confirmation. If confirmation fails, the artifact is considered invalid and the email fails filtering where filtering is looking for an artifact ({{object_id}}).
    • SECURE
      Validates the ticket number from an encrypted data block. If the value is not a valid encrypted ticket number, the artifact is considered invalid and the email fails filtering where filtering is looking for an artifact ({{object_id}}).
    Note: Types that are more secure than what is set are allowed. In other words, if you set the minimum type to PROTECTED, then both PROTECTED and SECURE are allowed, but NONE is not. Also, if PROTECTED or SECURE are selected, Text API ticket ID commands are not accepted. For more information about the artifacts, see the Artifacts Use Considerations topic.
  • Reply
    Specifies a notification method to send an automatic response. For example, Email. If you do not set this option, no response is returned. The response indicates success or failure of the actions performed for the message, and is separate from any notifications. If you are using multiple mailboxes, we recommend you to use the notification method to configure email replies.
  • Reply Subject
    Specifies a subject line for the reply, for example, Service Desk Response.
  • Write to stdlog
    Write email text to the standard log (stdlog) if the filter matches.
  • Log Entry Prefix
    Specifies a prefix to add when writing email text to the standard log entries. Use this option to enable matching log entries to rules.
  • Add Subject Line
    Adds the subject line from the original message to the message body before processing. You can append, prepend, or not add a subject line. The subject line is attached to either the ticket Description or a Log Comment, depending on the actions for the message.
  • Text API Defaults
    Specifies additional default commands for the Text API when the filter matches. Combines with the contents of the [EMAIL_DEFAULTS] section of the text_api.cfg file. The TextAPI Defaults field includes TextAPI keyword commands that are applied to a ticket when it is created from an email that matches a mailbox rule. The commands are not applied when the message affects an existing ticket.
    To specify TextAPI Defaults commands, place each command on a separate line in the TextAPI Defaults field. Format the commands as follows:

    OBJECT.FIELD=value
    
    Note: Do not include a leading percentage symbol (%), which is required only for corresponding commands that are embedded in the body of the email.

    For example, format the commands as follows:

    REQUEST.PRIORITY=3
    PROBLEM.CATEGORY=Facilities
    INCIDENT.GROUP=Plumbing
    
  • Text API Ignore Incoming
    Specifies additional Ignore Details for the Text API when the filter matches. Combines with the contents of the [EMAIL_IGNORE_INCOMING] section of the text_api.cfg file.
    The TextAPI Ignore Incoming field lists TextAPI keyword commands that are not permitted to be used in the text of the incoming email message. Any commands that are listed in this field are ignored when they are found in an incoming email message.
    To specify TextAPI Ignore Incoming commands, do the following steps:
    1. Place each command on a separate line in the TextAPI Ignore Incoming field.
    2. Format the commands as follows:

      OBJECT.FIELD
      
      Note: Do not include a leading percentage symbol (%), which is required only for the corresponding commands that are embedded in the body of the email.

      For example, format the commands as follows:

      CHANGE.ASSIGNEE
      PROBLEM.GROUP
      REQUEST.EFFORT
      
    3. Define all commands used in either field in the [KEYWORDS] section of the text_api.cfg file. This file is located in the “site” subdirectory of the CA SDM installation directory.
  • Details
    Specifies information about the rule.
  • Success Text
    Specifies the plain-text contents of a reply message when the message is processed successfully. For example:

    Thank you for submitting an update to your request. A support technician will contact you within the next 24 hours.
    

    You can also enter a notification phrase, if already created. For example, you can use a notification phrase for email auto-replies.

    Thank you for submitting your request.
    @{notification_phrase[notification phrase code].phrase}
    
  • Success HTML
    Specifies HTML contents of a reply message when the message processes successfully. The following options let you edit and preview HTML text:
    • Edit Success HTML
      Opens the HTML Editor which you can use to format the HTML.
    • Quick View
      Previews the HTML.
    • HTML Source
      Shows the HTML source.

    You can also use a notification phrase, for example,

    Thank you for submitting your request.</p>
    @{notification_phrase[notification phrase code].phrase}</p>
    
  • Failure Text
    Specifies the plain-text contents of a reply message when the message does not process successfully. You can also enter a notification phrase, if already created. For example, you can use the following text:

    Thank you for submitting your request.
    @{notification_phrase[notification phrase code].phrase}
    
  • Failure HTML
    Specifies HTML contents of a reply message when the message does not process successfully.

Mailbox Rule Actions

Mailbox rules let you perform any of the following email actions:

Ignore Email -- Does not process the email and does not reply.
This action is useful for system-level messages such as Out of Office or Mail Delivery errors.

Ignore Email and Reply -- Does not process the email, and replies to the sender. Response emails use the reply success messages and the reply failure messages are ignored.

Update Object -- Uses the filter string to determine the object identifier (for example, %Incident:{{object_id}}% in the email), and sends an update request to the Text API. If the object identifier is not found, the Text API does nothing.
This action typically handles email replies where the object identifier is embedded in the email. If no object identifier is present, the failure response message is typically sent.

Create/Update Object -- Uses the filter string to determine the object identifier (for example, %Incident:{{object_id}}% in the email), and sends an update request to the Text API. If the object identifier is found, the Text API updates a ticket. If the object identifier is not found, the Text API creates a ticket.
This action is the standard behavior of the mail daemon (Mail Eater) in which the email does or does not contain Text API keywords.

Pattern Matching in Mailbox Rules

The Mailbox rules use regular expressions for pattern matching. Consider the following whitespace characters that apply to regular expressions in mailbox rules:

  • \t
    Used for representing a horizontal tab
  • \r
    Used for representing a carriage return character
  • \n
    Used for representing a line feed or new line character

The characters that represent line breaks in text can vary with the operating system, mail server, and mail client. For example:

  • UNIX uses a \n.
  • Microsoft uses \r\n
  • Macintosh uses \r
  • MacOS X uses \n

CA SDM mail processing elements exchange substitute line break characters to identify text elements like message and attached parameters. Use a line or paragraph break for building filters to match \r or\n. Line breaks between two keywords identify a sequence of one or more \r and \n characters.

Line wrapping can result in unexpected line breaks. Line breaks appear in the middle of the text. A space can change to a carriage return or line feed or both. The carriage return or line feed or both can be inserted after a space. Include spaces in the middle of a filter string through the Regular Expression Block:

[\t\n]+(open-bracket, space, backslash, t, backslash, r, backslash, n close-bracket, plus sign). 

Example: Use [ \t\r\n] to Match the exact keyword:

The sample example shows how to match the exact keyword "request" and ignore other possible similar keywords:

requester
requesting
requested
orequestra

To match the exact keyword ''request'', enter the keyword request by one or more white space characters as:

[ \t\r\n]request[ \t\r\n]

The Mail Eater performs a keyword-based search for ''request and ignores other possible keywords like 'requester', requesting.

Filter String Object Identifier Restrictions

Filter strings determine the object identifier (for example, %Incident:{{object_id}}%) in an email. Text that surrounds an object identifier ({{object_id}}) must be unambiguous in both content and length. The text must clearly define the beginning and end of the ticket ID artifact value between the text.

The following restrictions apply to how the Mail Eater interprets the start of the ticket ID artifact value:

  1. The {{object_id}} placeholder must not be the first element in the filter string. At least, one character is required. Generally, a distinctive keyword or a sequence of letters, numbers, and symbols must precede the object ID keyword.
  2. The character immediately preceding the {{object_id}} placeholder must not be a repeatable or optional character having a plus sign (+), an asterisk (*), or a question mark (?). Whitespace characters (space, tab, carriage return, line feed) must not be part of a ticket ID artifact value.
  3. The character immediately preceding the {{object_id}} placeholder must not be a repeatable or optional bracketed-set of characters.

The following restrictions apply to how the Mail Eater interprets the length of the ticket ID artifact value:

  • The {{object_id}} placeholder must not be the last element in the Filter String. One or more characters must follow the {{object_id}} placeholder.
  • The character immediately following the {{object_id}} placeholder must not be a repeatable or optional character with a plus sign (+), an asterisk (*), or a question mark (?). Whitespace characters (space, tab, carriage return, line feed) must not be part of a ticket ID artifact value.
  • The first character after the {{object_id}} placeholder must not be a character.
  • Avoid the following characters immediately before and after the {{object_id}} placeholder:
    • All upper or lower-case letters
    • Numerals
    • The plus sign (+)
    • The slash (/)
    • The comma (,)
    • The period (.), as it can represent any character in this list except for a line break.
    Any of these characters can exist within the ticket ID artifact value. If a bracketed set (several characters between brackets) precedes or follows the {{object_id}} placeholder, the bracketed set must not contain any of these listed characters.

Special Characters in Regular Expressions

Pattern matching for the filters in mailbox rules follows the rules for ASCII Regular Expressions with C-style special characters.

Important! We recommend that you are familiar with Regex syntax to use special characters in regular expressions.

For example, consider the following special characters for Regex patterns that apply to regular expressions in mailbox rules:

  • \t
    The mailbox filter string \t specifies a horizontal tab. This string matches the beginning and end of text (and tabs), and is specific to MailEater.
  • \r
    This string specifies a carriage return (return to the beginning of the current line).
    Note: Do not use \r for searching message subjects or sender addresses.
  • \n
    This string specifies a newline (combination of line feed and carriage return).

    Note: Do not use \n for searching message subjects or sender addresses.

\t, \r, and \n are the special characters that occur most often in regular expressions for mailbox rules.

Example: \t, \r, and \n Use

[ \t]request[ \t]

The filter string performs a keyword search for 'request'. The brackets match any one character from the set, including the space, so [ \t] matches a space or a tab.

[\r\n]+critical[ \t\r\n]

The filter string performs a keyword search for 'critical'. This string searches at the start of a line, the start of the message, or the entire line. The brackets match any one character from the set. The + (plus sign) matches one or more of the previous, so [\r\n]+ matches one or more carriage returns and newlines.

Sample Text for Notification Phrases in a Mailbox Rule

This example shows sample text that you can use to include notification phrases in a mailbox rule. Define separate versions of a notification phrase for plain text and for HTML when the phrase contains any line breaks or other formatting.

Use the following text in Success Text, Success HTML, or both fields on the Update Mailbox Rule page, Reply Success tab:

Success Text

Thank you for submitting your request.
@{notification_phrase[IncidentURL1].phrase}

Success HTML

Thank you for submitting your request.</p>
@{notification_phrase[IncidentURL1H].phrase}</p>

Artifacts Use Considerations

An email artifact refers to something that arises from the mail process, for example, an email address that is included in a forwarded email. The Text API uses artifacts that contain a ticket ID (such as a reference number) for reply support. When the ticket ID is found, an existing Text API keyword (such as %INCIDENT_ID) is set and added to the input for the Text API. The Mail Eater identifies that a reply is associated with a particular ticket by finding the artifact in the message.

The Mailbox rules let you specify the artifact and the value that the Text API uses. For example, you can define a rule for incidents as Incident:{{object_id}}%. When a rule finds Incident:1234, the Text API uses %INCIDENT_ID=1234 (1234 is the ref_num for the Incident). Because the artifact must be unique in an email and easy to find, you can make the artifact more distinctive such as %Incident:{{object_id}}%. A percentage sign (%), whitespace, or some other character that cannot appear in an artifact value must follow {{object_id}}. Uppercase and lowercase letters, numbers, forward slashes, commas, and plus symbols are potentially part of a value. The secure artifacts are Base64-encoded after encryption. If you do not use the Secure artifacts, the characters that follow the artifact must not be contained in the ticket ID suffix, if any, which has been configured for that type of ticket.

When using the filter string of the mailbox rules to identify the ticket ID Artifact, the keyword {{object_id}} represents the position in the filter string where the ticket ID artifact is expected. This keyword is case-sensitive, even if the mailbox rule is not.

Example: Email Artifact Use

The following example shows an ARTIFACT format for use in a mailbox rule for a change request ticket.

Usage: %REQUEST=@{call_req_id.ref_num}%

Example: %REQUEST=1234%

When you construct the filter string of the mailbox rule, consider the following conditions:

  • A clear boundary must exist between the ticket ID artifact and the keywords which precede and follow it. We strongly recommended that you include whitespace text in this boundary text.
  • Do not end the portion of the filter string that precedes the {{object_id}} keyword in a repeatable or optional pattern that can match the beginning of the ticket ID Artifact, and do not end a pattern whose length is ambiguous. For example, the filter string must not contain the request(er|ed|ing)?{{object_id}}, because this construction causes an ambiguity whether a trailing er, ed, or ing is the end of the leading text or part of the prefix of an unprotected ticket ID.
  • The portion of the filter string that follows the {{object_id}} keyword must not begin in a repeatable or optional pattern that may match the end of the ticket ID artifact, must not begin with a pattern whose length is ambiguous, and must contain at least one element of whitespace. For example:
    • The filter string must not contain {{object_id}}[A-Z]?, because the [A-Z]? may match the last character of the ticket ID artifact.
    • The filter string must not end with {{object_id}}Item, because it is possible for Item to appear in the ticket ID artifact, either as the suffix of a ticket ID in a plain-text or protected artifact, or as characters within a secure artifact.
    • {{object_id}} Item is acceptable, because the space cannot be part of a ticket ID artifact, and is not part of a protected or plain ticket ID artifact. However, {{object_id}}[ \t\r\n]+Item (open-bracket, space, backslash, t, backslash, r, backslash, n, close-bracket, plus sign, +Item) is better, because the [ \t\r\n]+ compensates for the mail program inserting a line break after the {{object_id}}.
  • When you construct the filter strings for different mailbox rules, avoid using a filter string that completely includes another mailbox rule filter string, or in which the portion before or after a {{object_id}} keyword completely includes that portion of another mailbox rule filter string. Depending on the order in which these filters are checked, a message match intended for one filter can match with another, with a portion of the ticket ID artifact matching the additional text that distinguishes between the two filter strings.

Example: How to Create a Mailbox Rule That Matches Every Inbound Message

You can create a mailbox rule that matches every inbound message that another mailbox rule does not filter.

To create this type of rule, set the filter as Subject Contains and the filter string as a period and an asterisk (".*").

A period matches any character except the line break.

An asterisk matches zero or more occurrences of the symbol immediately before it.

As a result, this combination matches zero or more characters that are not line breaks.

Example: A "Catch-All" Mailbox Rule

This example demonstrates how you can use a ".*" combination to match every inbound message:

Filter = "Subject contains"
Filter String = ".*"

Example: How to Use the Mailbox Rules TextAPI Defaults and TextAPI Ignore Incoming Settings

The TextAPI Defaults and TextAPI Ignore Incoming fields let you specify default values for incoming mailbox rules, and specify TextAPI commands that should not be accepted in incoming emails. These fields work with the default values that are set in the [EMAIL_DEFAULTS] section and with the forbidden-commands list in the [EMAIL_IGNORE_INCOMING] section of the text_api.cfg file. When a conflict occurs between the definition in a mailbox rule and the definition in the text_api.cfg file, the value set in the mailbox rule applies.

The TextAPI Defaults field includes TextAPI keyword commands that are applied to a ticket when it is created from an email that matches a mailbox rule. The commands are not applied when the message affects an existing ticket.

Follow these steps:

  1. Place each command on a separate line in the TextAPI Defaults field.
  2. Format the commands as follows:

    OBJECT.FIELD=value
    Note: Do not include a leading percentage symbol (%), used only for corresponding comma embedded in the body of the email.

    For example, format the commands as follows:

    REQUEST.PRIORITY=3
    PROBLEM.CATEGORY=Facilities
    INCIDENT.GROUP=Plumbing

The TextAPI Ignore Incoming field lists TextAPI keyword commands that are not permitted to be used in the text of the incoming email message. Any commands that are listed in this field are ignored when they are found in an incoming email message.

To specify TextAPI Ignore Incoming commands, follow these steps:

  1. Place each command on a separate line in the TextAPI Ignore Incoming field.
  2. Format the commands as follows:

    OBJECT.FIELD
    Note: Do not include a leading percentage symbol (%), used only for the corresponding commands embedded in the body of the email.

    For example, format the commands as follows:

    CHANGE.ASSIGNEE
    PROBLEM.GROUP
    REQUEST.EFFORT
  3. Define all commands used in either field in the [KEYWORDS] section of the text_api.cfg file. This file is located in the “site” subdirectory of the CA SDM installation directory.

Mailbox Policy Fields

Email Address/Hour
Specifies the maximum number of emails per email address per hour. You can specify the following values:

  • -1 -- No limit (default)
  • 0 -- No emails allowed.
  • 1 – Maximum number of emails allowed.

Log Violation
Logs the violation to the standard log. You can specify the following values:

  • Do not log
  • First violation only (default)
  • All violations
Note: The First violation only option keeps a list of email addresses associated with messages that violate mailbox policies and uses the list for the log to avoid duplicate log entries. The list is cleared when the Mail Eater daemon is restarted. However, if you change the setting from First violation only to one of the other options and back, the list of email addresses which were logged under this setting is not cleared. If a mailbox logs numerous violations while using this setting, we recommend that you restart the Mail Eater daemon periodically to clear the list, or use the Do not log option.

Inclusion List
Specifies email addresses or domains that are allowed to process emails -- only emails matching the list are allowed. You can specify multiple addresses or domains by delimiting them with a comma, semicolon, space character, or line break. An entry of an asterisk (‘*’) by itself is the “World Domain,” and matches all domains that are not in the Exclusion List.

Exclusion List

Specifies email addresses or domains that are not allowed to process emails. You can specify multiple addresses or domains by delimiting them with a comma, semicolon, space, or line break.

Note: Addresses in the Exclusion List override any values in the Inclusion List. Addresses in the Inclusion List override domains in the Exclusion List, and can provide specific exemptions for specific senders in an otherwise-banned domain. Domains in the Exclusion List override the World Domain in the Inclusion List. The World Domain is not valid in the Exclusion List.

Multiple Mailboxes

CA SDM can process and manage multiple mailboxes. Each mailbox can have its own definition, instead of using a single global set of definitions. You can define multiple mailboxes and use different templates or default values for each mailbox. Multiple definitions let individual tenants use separate mailboxes, or let an individual tenant or organization use different mailboxes, and have different behaviors for each mailbox. You can set up multiple mailboxes by using the Administration interface. Each mailbox uses the following tables:

  • usp_mailbox -- Defines the mailbox.
  • usp_mailbox_rule -- Specifies a set of rules for each mailbox.
    Because mailbox rules supply Text API defaults, you can establish email interfaces with other software and parameters (such as category, assignee, and so on) that are configured specifically for the interface.
Note: IMAP servers support multiple mailboxes for a single account, but alternate mailboxes are not supported; only the default inbox is supported.

How Multiple Mailboxes Use Rules

The Mail Eater (pdm_maileater_nxd) component on the primary server uses mailbox connections and rules to read and process messages from one or more accounts on one or more mail servers. The Mail Eater processes mailboxes serially (only one mailbox is processed at a time), and processes rules in sequence number order.

Multiple mailboxes use rules as follows:

  1. Upon primary server startup, the Mail Eater reads the following tables:
    • usp_mailbox
      Represents a connection to a mail server.
    • usp_mailbox_rules
      Represents the rules that apply to the connection (usp_mailbox).
    • Contact_Method
      Represents the Contact Methods used for automatic replies.
    • Document_Repository
      Represents the Document Repositories for storing attachments.
    The Mail Eater automatically detects changes to the objects in any of these tables, including the addition of additional objects. If a change is made to usp_mailbox or usp_mailbox_rule, the polling interval for the affected mailbox is rescheduled to one second after the change is applied.
  2. At the interval defined by each mailbox, the Mail Eater retrieves each email in the inbox for the associated account, and processes the email as:
    1. Checks the email address for policy violations. When the Mail Eater finds a violation, processing stops, and the standard log is affected according to the mailbox definition.
    2. Compares the email to each rule (mailbox_rule) that belongs to that mailbox.
    3. If a matching rule is found, the Mail Eater submits the message to the Text API for posting, and replies to the user as appropriate based on the specified action for the rule.
      For reply emails, the filter string identifies the object and uses the Text API for processing. After processing is complete, the response goes either to the Reply to or the From address.
    4. When a matching rule is located, no other rules are checked, and the Mail Eater processes the next email in the inbox.
    5. If no matching rule is found, the message is discarded.
  3. After the Mail Eater processes all emails for an inbox, the processed and discarded messages are purged from the mail server, and the next processing interval is scheduled.
Was this helpful?

Please log in to post comments.

  1. Peter Schmidt
    2016-04-29 10:49

    Where to find information what else to do for POP3 and TLS configuration. What are the concepts. Link in this chapter to definition of concepts would help. Also in 'How to configure the Email Replies'