Email Response Processor Configuration Files

The Email Response Processor uses a configuration file named ERP.config to specify the database connectivity information. This file is installed during Email Response Processor installation. Refer to your installation documentation for further information about this file.

The Email Response Processor’s functionality is configured in two files: ReplyProcess.script and BounceProcess.script. The configuration files are similar and are divided into two parts:

  • A parameter section, defining global parameters

  • A rules section, describing the way incoming emails should be handled

Additionally, an optional error handling section defines the actions to execute if an error occurs during normal operation.

The parameter section of the configuration files allows for the global configuration of the Email Response Processor (SMTP mail servers and mailboxes). Each parameter is defined in this manner:

name = value [, value...] ;

The following table shows the parameters:




Specifies the log file name. The default value is Reply_Processor.log for the Reply Process and Bounce_Process.log for the Bounce Process. The log is written in a Log subdirectory under each Email Response Processor instance directory.

Note: The log file can grow to be very large. If you want a smaller log file, set the debugMode parameter to off, which will cause the Email Response Processor to log much less information.


Used to configure how many emails to process for each open/close POP3 session. The Email Response Processor will open a mailbox, process emails up to maxMailToGetPerPOPSession, then close the mailbox and move on to the next one. By default this parameter is commented out in the script file and the default value of 10,000 is used.


The name of the POP3 server hosting the mailboxes.


A comma-separated list of mailbox definitions in the form (username, password). The password must be encrypted. The mailboxes should all have the same password—because the encryption is done at installation, this allows you to cut and paste the encrypted password if you add any new mailboxes after installation is complete.

You can use the Password Encryption Utility to encrypt passwords; refer to the documentation on setting up Online Marketing for more information.


A comma-separated list of SMTP servers used to send email (such as auto-replies and forwards). The first reachable server in the list will be used. If the first fails, the second will be used.


The delay in minutes during which the Email Response Processor waits before waking up to begin processing the next batch of email messages. The default is 3.


Limits the number of messages processed per hour to avoid tying up the CPU. The default is 0, meaning unlimited.


If set to on (or true or yes) additional information (for example, database update and contact-not-found information) is written to the log file. The default is true. To turn this parameter off, set it to off (or false or no).

Note: If you set this parameter to on, your log files can grow very large and occupy a large amount of disk space.


Contains the email address you want to appear in the From field of a forwarded or replied email message (for example, If this parameter is not present or if the value is an empty string (““), the source address is extracted from the processed email.


If this parameter is set to true (or on or yes), the system gets the contact from the Sender field of the email if the Contact ID is not available from the magic number.


The complete local host name with domain (for example,


The size of an email message in bytes. Mail messages of sizes larger than this value will be deleted without processing. A logfile is generated.


The following example shows the parameters section of a configuration file with some of the values set.

popServer	= ;
popUsers	= (ps, 12345) ;
smtpServers	= ;
logFile	= Reply_Processor.log ;

The rules section of the configuration file contains a simple script that describes what the Email Response Processor should do with the emails it receives. The script, executed for each message in each of the mailboxes, is a list of actions to be performed in sequence.

You can control which parts of the script are executed for each email using the following structure:

if <condition> then <action> [else <action>] end

The action can be either a single action (such as delete or forward) or a list of action enclosed in curly braces. To provide greater control, you can nest these blocks.

The condition that triggers an action is most commonly the presence of a particular character string in a particular part of the message. For example, if the email contains the string “unsubscribe” then the script might direct the Email Response Processor to forward the email to an address set up to handle unsubscribe requests. You can combine conditions using the AND and OR keywords or negate them with the not keyword.

Note: Only the Reply Process checks conditions on received emails. The Bounce Process assumes that the popUsers parameter contains only mailboxes designated as bounce mailboxes and that these mailboxes contain only bounced email messages. For more information about setting up bounce mailboxes, refer to Using PeopleSoft Online Marketing.


The following example shows the rules section of a Reply Process configuration file. In this example, if the string “Original Message” appears in the message body, the email is forwarded to the email address If the string “unsubscribe” appears in the message body, the email is forwarded to Afterward, the email is deleted from the mailbox (including any emails not containing the specified strings in the body).

if inBody ("Original Message") then
	forward ( ;
else {
		if inBody ("unsubscribe") then {
			forward ( ;

Note: Be aware that if you use multiple mailboxes for processing replies, all the mail is not necessarily processed at the same time. For example, if you have four mailboxes set up to process unsubscribe requests and reply with confirmation notices, some notices might be delivered sooner than others depending on which mailbox received the request.

When an error occurs in the main script, the execution is interrupted, the error is logged, and then the section is executed.

The error handling section of the configuration file is introduced by the onError keyword:

onError <action>

for example:

onError delete


The following section shows the error handling section of a configuration file. In this case, messages generating errors are deleted.

Note: Comments are preceded by “//”.

onError			/ /ensure that the message is deleted