Example of a Scenario Where Inbound Email Fails
This is an example of a case where inbound email may fail.
Let's say that your support mailbox is support@mycompanydomain.com and you have set up a forwarding rule. When your employee sends an email to support@mycompanydomain.com, the mail is forwarded to mycompanydomain.extservice@oraclecloud.com. The email address mycompanydomain.extservice@oraclecloud.com is registered as an access point. So, the inbound emails work fine.
However, suppose you upgrade your installation and a password error occurs after the
upgrade. If someone changes the email address in the SVC_INBOUND_EMAIL_ADDRESSES profile
option to mycompanydomain2.extservice@oraclecloud.com
, then your
inbound emails stop working for the following reasons:
-
The updated email address in the SVC_INBOUND_EMAIL_ADDRESSES profile option isn't registered as an access point with the UMS.
-
The email address in the forwarding rule doesn't match the updated email address in the SVC_INBOUND_EMAIL_ADDRESSES profile option.
When the email address in the SVC_INBOUND_EMAIL_ADDRESSES profile option is changed, the following changes are reflected in the Access Point Setup section of the Inbound Email Configuration and Validation page:
-
For the new email address that's added to the SVC_INBOUND_EMAIL_ADDRESSES profile option, a Register button appears.
-
For the old email address in the SVC_INBOUND_EMAIL_ADDRESSES profile option, an Unregister button appears.
It's important that you first correct the email addresses and refresh the Inbound Email Configuration and Validation page. And only after that, you must click Register and Unregister as required.