When we send a response and it bounces, what does Oracle B2C Service do with the bounced message? Is there any way to see what has bounced?

Environment:

Bounced incident response emails
Oracle B2C Service

Issue:

We use closed-incident surveys with our Oracle B2C Service site. Sometimes our customers indicate that we never responded to their question. When we look at the history of the incident, we see that we did answer their question and we sent a response.

We would like to know if there is some kind of email delivery problem where we did send a response, but for some reason, it either was not delivered or was bounced. We would like to see how those bounces are processed and what bounced.

Resolution:

By default, the mailboxes in Oracle B2C Service are configured to delete returned messages, such as mailer daemon errors. You can, however, configure your mailbox settings to allow returned messages in the mailbox, which would then update incidents in your Oracle B2C Service application. Allowing these returned messages into your system gives you the opportunity to review the message and attempt to find a root cause for the failure.

You can have rejected messages sent to a different email address. That way, rejected mail can monitored and evaluated without having them create new incidents in your Oracle B2C Service application.

In order to allow returned messages to not be deleted by the system, use the steps below:

1. From the Configuration items, select Site Configuration > Mailboxes.
    
2. Double-click the Service mailbox.
    
3. Click the Incoming Email button on the ribbon.
    
4. Uncheck the Delete Returned Messages box. By disabling this option, returned messages will not be deleted.
    
5. In order to have returned messages sent to a different address, enter the address in the Send Rejected Messages To field. If you leave this field blank, the rejected messages will be sent to the mailbox address and will create a new incident at the application.
    
6. Click Save.
    
7. Edit other mailboxes, if necessary.
    
8. Test for results.

In order to test your change, create a test incident and contact with a fake email address and send a response to it. This should cause a mailer daemon error to bounce back to your techmail box, where it will be brought into the system as a new incident.